Title: RE: [asap] questions/concerns on initial working draft doc (and scope)
Keith,
My comments/answers
are embedded in the orig. message. I suggested at the last conference call that
we define the scope of ASAP to clarify what this spec is going to be about. It
looks like we have different views on what it should cover.
Thanks,
Michael
Shenfield
Advanced Research
Group
RIM
905-629-4RIM x4347
____________________
This information is transmitted on a "WITHOUT PREJUDICE" basis. It is
intended only for the person or entity to which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon, this
information by persons or entities other than the intended recipient is
prohibited. If you received this in error, please contact the sender and delete
the material from any computer.
-----Original Message-----
From: Keith Swenson
[mailto:]
Sent: October 7, 2003 1:37
PM
To: Michael Shenfield; ASAP (E-mail)
Subject: RE:
[asap] questions/concerns on initial working draft doc (and
scope)
The whole point about ASAP is to set up a 'contract' to have
something done and to be able to check on its progress. [Michael
Shenfield] Re: "be able to check on its progress": Then
the name is misleading. The spec should either be limited
to dealing with async Web Services that support monitoring (I
see it as a small fraction) or to make monitoring optional. From the
wireless standpoint perspective monitoring is a waste of valuable resources,
for the "wired" client it could be useful but requires much more complex
implementation of a Web Service. As already pointed out, the scalability will
take a major hit as Web Service instance cannot be stateless
anymore.
Perhaps more important is the ability to
change your mind and cancel it. [Michael Shenfield] Again, it's up to the group,
but I don't think of it as a solid requirement. These are all
things that need a "correlation" id of some sort. What ASAP oes it
provide a simple way to request something to be done and receive a correlation
id that can be used to check onthe progress.
There are many use cases that fit this model, but there are
also many that do not. A "stateless session bean" is a pattern that ASAP
is not designed to support. Instead, ASAP is designed for the "stateful
session bean" where you have a unique instance with an ID, and subsequent
requests go back to that same instance. This session bean is endowed
with a goal, and it is expected to last until that goal is accomplished, and
then a little while after that (see the timeout setting). The goal could
be "search four house listings for 3 months" or something abstract like
that. [Michael Shenfield] The general agreement in a Web Services
J2EE world is that Web Services should only be exposed by servlets or
STATELESS session beans - there're tons of references on the topic. I am
not aware of any implementations of Java Web Services running as stateful
session beans (reasons: scalability, thread safety, management/sharing issues,
etc.)
For many implementations of ASAP, the factory will be like a
stateless session bean in that it is a web service that simply "exists" and
the starting and stopping of it is invisible to the outside world. The
"service instances" then have a lifecycle that can be externally
monitored.[Michael Shenfield] I don't have any problems with a
COMesque "CreateInstanceRq", I've used it for years in COM, as well as
Home interfaces' "ejbCreate" in EJB. I just don't see Web Services following
the same pattern, being involved in many Web Services activities I haven't
seen many that mandate user managed instance creation. The other reasons are
as per previous comments.
The concept of "fire and forget" (uncorrelated messages)[Michael
Shenfield] "fire and forget" mode is a user experience term. The
message request and response(s) share same correlation
ID.
is probably not what ASAP is designed to support. This
would be a single call that later returns a result (or multiple
results). This seems like it can be handled sufficiently with (reliable)
asynchronous messaging. In this case you do not need a correlation id,
because there is no other communications with the instance. As you point
out, these do not need monitoring or other support. Lets discuss
this.
As for the concept of "multiple async responses", this is
quite definitely what ASAP is designed for. There is no reason that ASAP
is restricted to a single response at the end. Once the correlation key
is set up, the services on both sides can make further requests to each
other. The simplest way to implement this is every new result causes a
change notification event back to the observer. The event might (or
might not) carry the new data. If the event does not carry the data, the
observer can do a "GetProperties" in order to fetch the changed data.
The former implementation is most likely to work with a generic ASAP
implementation, but people are alowed to extend the ASAP protocol to include
special methods, e.g. "NewSearchResult". In this case the ASAP sets up
the basic instance which represents the agreement between the client and
realtor, and then the services can inspect the interfaces supported, and if
they both understand this extended command, they use it.
Use of ASAP in the above example would allow the client to
modify the type of house they are looking for (after receiving a bunch of
uninteresting results) or terminate the search (in case they find their dream
house).[Michael
Shenfield] see comment #2
Terminology is always a big problem. We used to call
them "interfaces" and now we call the "port types". I think that our
usage of "method" should be "operation" now, right? [Michael
Shenfield] No, method in your definition means "message". Operation
is defined as a set of Requset, Response, and
Notification messages
If you see things like
this that obvisouly deviate from the SOAP norm, please bring these up.
Our goal is to be consistent. "Context data" & "result data" on the
other hand is a concept unique to ASAP for which there is no other term
(unless I have missed something). [Michael Shenfield] Web Service operations are
defined using Request and Response (if any) messages. I think "Request data"
and "Response data" if you want to define parts (or group of parts) will be
more consistent.
These are parts of messages, but the key is that these structures
persist in the service instance, and can be queried and (in some cases
modified) by later operations.
BTW: We are designing Wf-XML as an extension of ASAP, and in
that the Factories themselves can be created and started. This maps into
the BPM ability to define and start new business processes. ASAP is
extended to add the new methods for the 'factory lifecycle'.
-Keith Swenson
(408) 456-7667
-----Original Message-----
From:
Michael Shenfield [mailto:]
Sent: Tuesday, October 07, 2003 9:45 AM
To: ASAP (E-mail)
Subject: [asap]
questions/concerns on initial working draft doc (and
scope)
Hi all,
At the last conference call we
had a discussion on taking the initial working draft to the general public. I
suggested 'no' based on my initial impression from scanning through the
document 2 weeks ago. Finally, past weekend I was able to review the document
in detail. Here's the list of questions and/or concerns that I would like to
post here for your review:
- Factory "resource".
I am not sure
about the concept of "factory" and passing observerURI as a part of
CreateInstanceRq. Let's take Java Web Services as an example. When a Web
Service deployed as a servlet the hosting Web Server container plays the role
of the "factory" but this is "invisible" for the caller. The caller posts to
the WS endpoint URI an HTTP request that contains the SOAP message to be
invoked. Lifecycle management of the servlet (as a WS instance) is not covered
by invocation protocol and therefore "creation" of the WS instance is non of
the caller's concern. Similar model stands for the Web Services deployed as
stateless session beans, the EJB container hides the creation process. For all
async Web Services deployed at RIM (to support application initiated push to a
wireless device) we have an "observer" URI (or rather requestor endpoint)
passed as a part of the Web Service message. The requestor URI could also be
submitted at registration (optionally with a correlationID), so that all
following correlated and uncorrelated notifications could be posted to the
requestor endpoint. This opens the stage for the next question:
- Multiple async responses for a single request or
uncorrelated notification messages.
One of the
possible deployments for async Web Services is when a single request causes a
number of responses. As an example, one of our demo Web Services "Realtor"
uses this model to send listings to a real estate agent registering a new
client. The model is obviously asynchronous as we don't want our real estate
clients wait (and pay for the airtime) till the request is processed. The
"client registration" message is a request that carries the client search
information, requestor endpoint URI and generated correlator ID to be used for
responses. The server is doing the search in MLS and asynchronously sends
found listings each in a separate SOAP message (here we have multiple
responses for a single req). Moreover, when a new listing is posted to MLS the
server is searching for interested clients and sends the listing to their
agents as a notification (correlated notification model). Additionally, the
Web Service is capable of sending uncorrelated notifications. We implement the
following model: when real estate agent is logging in, the Realtor Web Service
gets endpoint URI of the service proxy (linked with the device) and when a new
information for the agent is available in the server (e.g. viewing
appointment), the Web Service sends uncorrelated notification to the endpoint
URI. In my opinion both models (multiple async responses and uncorrelated
notification) should be included in the scope of ASAP
- Monitoring support.
In the document
there is a lot of discussion on monitoring the execution process and changing
the state/properties during execution. I am not sure if this should be
mandatory for compliance, one can perfectly deploy the async Web Service
without support for monitoring or state change (see example above). Moreover,
as an implementer I am not clear on how to implement this monitoring and state
altering model in a scalable Web Service - in my opinion it contradicts basic
scalability considerations of J2EE or .NET deployment. I think that
ChangeState, GetProperties, SetProperties, and StateChange msgs should be
changed to optional. As for Subscribe, Unsubscribe, and Completed, I am
looking forward to the discussion on how it should be defined in the ASAP
context.
Introducing monitoring of the execution is identical to
polling for the completion/result and kills async efficiency. I understand the
async paradigm as the model where requestor "calls and forgets". The
implementation (and ASAP spec) should guarantee that the requestor gets the
results (or notified on completion) when ready. Am I missing something
here?
- Introduction Section. Language and terminology.
It looks like the verbage of section 1 intentionally deviates
from the standard Web Services terminology and definitions. Is there a reason
for this? Why should we call SOAP messages as "methods", Request data as
"Context data", Response Data as "Results data", etc. Again, I might be
mistaken here but my impression was that ASAP is strictly about Web
Services?
Sorry to send this 20 mins prior to the conference call, but
as I didn't see posted agenda we can as well discuss these points.
Cheers,
Michael Shenfield
Advanced Research
Group
RIM
905-629-4RIM x4347
____________________
This information
is transmitted on a "WITHOUT PREJUDICE" basis. It is intended only for the
person or entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you received this
in error, please contact the sender and delete the material from any
computer.
To unsubscribe from this mailing list (and be removed from the
roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/asap/members/leave_workgroup.php.
