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

I think you are suggesting to take a look at ASAP as Grid Services (Open
Grid Service Specification)

in which the hosting environments can implement (Async) services in any
language (implementation specific

such as J2EE or .NET). Then it becomes not portable of course.

But from the client perspective no change in design or code because 
of the hosting environment changes.

More I look at the draft, we should leverage lot of work that has been
done in the Grid Forum for

terminology. (I think we established the liaison relationship with Grid
Forum in the first meeting).

Thanks

Mayilraj

At 10:37 AM 10/7/2003 -0700, Keith Swenson wrote:

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 

 

(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.