OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

asap message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [asap] questions/concerns on initial working draft doc (and scope)


Title: 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.  Perhaps more important is the ability to change your mind and cancel it.  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. 

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.

The concept of "fire and forget" (uncorrelated messages) 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).

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?  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).  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
kswenson@fsw.fujitsu.com
(408) 456-7667

-----Original Message-----
From: Michael Shenfield [mailto:mshenfield@rim.net]
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
mshenfield@rim.net
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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]