Title: RE: [asap] questions/concerns on initial working draft doc (and scope)
Keith,
I went back to EJB spec to validate my point on stateless (vs. stateful)
session beans. The following is from an EJB 2.1 final draft (section 1.2. What
is New in EJB 2.1):
"We have
added support for web services. We have added the ability for a
stateless session bean to implement a web service endpoint. We have added support to
allow all enterprise beans to utilize external web
services."
In the current J2EE/Java world
only servlets and STATELESS session beans could implement a Web Service
endpoint. Neither can support the protocol described in a current working draft
(actually it's not true, one can come up with a model when the state is
shared by servlet instances using a ServletContext object. It could be a sneaky
way to implement monitoring but very inefficient and non scalable
one)
Cheers,
MS
-----Original Message-----
From: Michael Shenfield
Sent: October 7, 2003 2:42 PM
To: Keith Swenson; ASAP
(E-mail)
Subject: 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.
