← Prev in month
← Prev in thread
Next in thread →
Next in month →
RE: (correction) [asap] questions/concerns on initial working draft doc (and scope)
Title: RE: [asap] questions/concerns on initial working draft doc (and scope)
The formatting got
corrupted. Should read:
...
IMHO, there's
a need for standard protocol
that:
- defines how the originatorURI (compliant with
WS-Addressing) is going to be passed to the async WS,
- defines correlator
ID and its use (misc. issues incl. ID format, passing as a part of
the header vs. as a part of the message, correlation scope,
etc.)
...
-----Original Message-----
From: Michael Shenfield
Sent: October 8, 2003 10:54 AM
To: 'Keith Swenson'; ASAP
(E-mail)
Subject: RE: [asap] questions/concerns on initial working
draft doc (and scope)
Keith,
I enumerated your
paragraphs in order to separate my answers:
Re
#1: It's not about terminology. I am concerned about monitoring and
state/properties update support being principal requirements for
ASAP compliance, as it requires stateful implementations.
Re
#2: Agree. I re-read your definition and "method" should be renamed
to "operation".
Re
#3: Yes, I do. That's the reason I joined this TC
:-)
IMHO, there's a
need for standard protocol
-
defines how the
originatorURI (compliant with WS-Addressing) is going to be passed to the
async WS,
- defines
correlator ID and its use (misc. issues incl. ID format, passing as
a part of the header vs. as a part of the message, correlation scope,
etc.)
- defines
"standard" notification message(s) (to be defined in originator-published
WSDL) and generic extensible format for "results" part of
notification
- deals with
uncorrelated notification and request with multiple responses (here it's more
about correlation scope)
- and optionally
(these require stateful implementation):
-- defines
monitoring support
-- defines service
lifecycle management (i.e. instantiation, state/props change, termination,
post-completion results query, etc.)
-- "completed"
notification without attached results (both as a WS message, and a non-WS
HTTP Req with predefined header)
--
...
I don't think it's
possible to solve these problems with a basic SOAP, but I will consult my WS
development team for a feedback.
Re
#4: Why persistent? Is it a requirement? Your definition of "context
data" here extends one in the document:
Context
data: The XML data sent to initiate the
service.
Results
data: The XML data created by the
successful completion of the service.
...
When reading the
document, I concluded that it's about "Request data" and "Response data" as
per WS terminology. If the group chooses to keep these
terms/concepts, I suggest changing the definitions to avoid
confusion.
Re
#5: It's defined by the logic supported in WS implementation. In our
Realtor WS demo the notification is turned off when the client is declared
inactive (e.g. purchased the property).
Re
#6,7,8: All these are implementation specific. Same as
#5.
Keith,
all,
My suggestion is
that we seek input from everyone in the group on their view of the
scope/direction for the ASAP. The ideal solution would be for each one to
come up with the list of items they would like to see included in the spec and
post them to the list. Next we can rank them and work on defining the scope
according to the rank/priority.
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 7:35
PM
To: Michael Shenfield; Keith Swenson
Cc: ASAP
(E-mail)
Subject: RE: [asap] questions/concerns on initial working
draft doc (and scope)
Let me try to refocus this discussion.
ASAP does not specify how you implement the web
service. If you wish to use J2EE, you may use whatever
technique. I thought that describing in terms of stateful/stateless
would help in understanding the concepts, and to distinguish the various
meanings of the word 'asynchronous'. I didn't mean to imply that
this was the actual implementation. ASAP does not proscribe how this
is implemented in the J2EE world, and so I don't want to discuss this
here.
I still think "method" in the spec refers to an
operation, because it consists of a request message and a response
message. The messages are described, in places, as
parameters. Please point out in the document where it means something
else than this. I propose that we change "method" to "operation" in
the document in order to conform with SOAP
terminology.
Let me ask you a question: do you believe that a special protocol
is needed for an operation that can not be monitored? For example, a
service that you send a message to, and a while later you get a response
from. No possiblity to change you mind. No possiblity to
monitor status. Can't you do this is basic SOAP protocol?
Let's discuss if you think differently, but I am going to assume that this
is covered by basic SOAP.
The "context data" is persistent data that exists in the service
instance. It can be sent as part of a reqeust (e.g. SetProperties),
or as part of a response (e.g. GetProperties). Furthermore, there
are messages that contain the schema of this context data as part of a
response from the factory object.
We really should discuss usage scenarios. You touched upon
the realestate example, one of my favorites. You describe the
service as being a recurring query for houses that meet a specific
criteria. The context data includes the query, as well as the result
set. (You might implement this any number of ways, but for now lets
imagine that we choose this one.) The client would make a simple
SOAP request to start this service, giving both the initial query, as well
as the address to send responses to. Everytime the result set
changes, a notification is sent to the client. It would be really
unpleasant if there was no way for the client to turn this off. When
you started the service, you had no idea how long you would be
searching. You in fact might put the serach end data as a context
variable. Later, you can change that end date by using
"SetProperties" thereby extending the duration of the search service, or
ending it early. You can also cancel the service by using the
"ChangeState" to the closed state (which is the terminal
state).
The client of this service need only know the name of the context
variable that holds the query (e.g. "query"), and the name of the context
variable that holds the results (e.g. "listings"). Probably, the
service instance would not allow the client to set the value of
"listings". Attempts to set this would result in an error.
Some services can not allow changing of context variables at any time, so
attempts to set any of them would cause an error. In this sense, the
operation "SetProperties" is optional. It is not really optional,
but can be implemented to simply return an error.
If you don't have a client that can receive notifications, then you
also can simply pick up the latest value of "listings" at any point in
time. In this case you would not register an observer address.
Also, you would never receive a completed message.
Finally, others interested in the same listings (the same query)
could register to receive notifications of when the listings change.
Note: you are not registering to a specific query, because the query could
be change. Instead you are registering to a specific instance of the
service.
Now, can we start over with the questions because I am having a hard
time deraveling them from the discussion below.
-Keith
-----Original Message-----
From: Michael Shenfield
[mailto:]
Sent: Tuesday, October 07, 2003
12:26 PM
To: Keith Swenson
Cc: ASAP
(E-mail)
Subject: 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.
← Prev in month
← Prev in thread
Next in thread →
Next in month →