RE: [asap] Factory in ASAP

[Keith Swenson <KSwenson@fsw.fujitsu.com>]

Title: RE: [asap] Factory in ASAP

That should be relatively easy:

• The CreateInstance operation returns a structure that has the instance address (key) in it.  If the instance URL is not returned, then there is no support for monitoring or controlling the instance that was created.
• Similarly, the CreateInstance operation accepts an observer address (key) in it, and if that observer key is missing, there is no notification of completion (unless an observer is registered later).
• Even if an instance key is returned, the instance does not need to allow:
• changing (updating) some or any of the instance attributes.  If a client attempts to update any attribute that is not allowed to be updated, then the entire update operation fails, and an error is returned.  It reasonable for an asynchronous server to never allow update, and to always return this error.
• checking of status.  It can return an error stating that status can not be checked.  (Although it would seem that any server that returned an instance key it would certainly at least allow checking of status).
• registering new observers: an error can be returned for this operation. Some services may require that the observer key be sent in the original request.
• unregistering observers: if register returns an error, then unregister may also return an error.
• terminating: an error can result from any attempt to terminate the service instance.  In most processes there comes a point after which the order can not be cancelled, for example after an order is already shipping.  You must instead receive the shipment, and make a new process to send it back.

I think this allows you to start an asynchronous service with an observer key that will receive multiple responses.  For example the real-estate agent home search example that sends back a result everytime a new home is listed that meets the criteria.

 

Further Reflections - the case for fixed operation names

 

Often, we have been asked the question: "why do I need to give the operation a particular name, and why must there be an instance key?  I should be able to name the operation anything I want.  The instance key is just a correlation key.  I should be able to make any field in the message be the correlation key.  For example, I have a field named 'PO Number' that that can be the correlation value; or I should even be able to make the correlation be a combination of values, such as 'Telephone Number' and 'First Name'."

 

What drives us to this approach is that we need to be able to link systems together easily.  Consider an analogy: the Java Servlet class.  I order to make it easy to add programming functionality easily into a web environment, the Servlet interface was invented.  You implement a class to this interface.  Most important is a single method "service" which accepts two parameters: ServletRequest and ServletResponse.  Using the servlet interface, you can easily make a Java program that generates a page however you want it: a list of hot stocks, a discussion forum, a check-in/check-out document management system, whatever.

 

The cool thing about implementing a class with this interface is that the only thing that must be done is to let the Servlet engine know the name of the class, and the address to map it to.  (In some cases it can make a mapping automatically by the class name, and you only need to let it know the class name.)  Knowing the class name, it can make an instance of the class, and call "service" on it.

 

One might argue: "Wait a minute, I am writing an On-Line Go Program, so I should be able to use an operation like 'MakeMove' instead of 'service'".  You might even argue that you have written many Go programs in the past, and never had to use a method named 'service'.  True enough.  But to make it easy for the web server, you take whatever functionality you want called, and bundle it up into method called 'service' so that the Servlet engine knows what method to call.  We can conceive of a system that allows the Servlet engine to call any method, of course.  But if we do that, we need to (a) tell the engine the name of the class, (b) tell it the name of the method, (c) tell it about each paramter and what to send there (this is the hard part).  The Servlet engine has a Servlet Request class and a Servlet Response class, but in this alternative approach it needs to be told how to draw information out of those structure, and reoragnize it into the structures required for the 'make move' operation.  It just is not worth externalizing this information.  Instead, we internalize how to get the move information from the ServletRequest class.  We ask the Servlet designer to offer a plain vanilla interface that any servlet engine can call.  The only setup is specifying the name of the class.  Simple, and very effective.

 

This is essentially what we are doing with ASAP.  I can make a web service "PurchaseItem" which has 5 parameters to it, but then I have to teach the calling program the meaning of the 5 parameters.  Every company might do these parameters differently.

 

Imagine I have a local purchase order system where I enter things I want to purchase, then the local system figures out that the things I am purchasing can be split into three groups and each group ordered from a different store.  (e.g. an office supply store, a computer store, a phone company)  An order will be submitted to each of the three, and they will take the order through their process.  It is certainly possible to let each of the three stores define their own Web Service operation for submitting an order.  EAch of them would have their own different parameters to the operation.  Then, on of them will have a correlation ID called "Order Num", the next will have "CondactId", and the last uses a combination of "Account Number" and "Sequence Id". 

 

I am a programmer, so I know that I can write a system that can make a call to any Web Service, and transform my internal information in any way necessary, and then I can store any structure that returns, so it is possible to make this work.  (Fujitsu's i-Flow system dow this.)  BUT, look at all the trouble I have to go to.  Every external system that calls the office supply system needs to be told that "OrderNum" is the important value that must be stored and then used again for futher requests.  Think how much easier it is to set up a standard that all correlation information is collected into a single field called "InstanceKey" which is a URL.  Now the office supply company may make that URL look something like this: "xxx/yyy/zzz.jsp?OrderNum=12345".  The calling system does not need to know anything about the structure of this, just simply to return the value back.  The phone company can structure their instance key as "xxx/yyy/zzz.jsp?AccountNo=12345&SequenceId=678".  Now, the calling program simply needs to save the InstanceKey for each of the stores, and hand the same one back.  It does not need to know how that key was constructed.

 

The important aspect is that the calling system knows that it needs an id to return on subsequent requests.  That is all it needs to know.  The details of how to find and track instances is kept internal to the system being called.  We are asking these system to implement a service according to a fixed interface defined by the standard.  By implementing this interface, it become very easy to link together systems.

 

Keeping the details on how instances are found internal to the remote service is important not only because it simplifies the life of the caller, but also because it allows for flexibility over time.  The phone company may decide later to track orders by 9 digit zip code and time/date of first contact.  At any point in time, it can make that change by generating new service instances with the new instance key format.  There may be hundreds or thousands of client set up to be able to call this service at the telephone company, but they do not need to change a thing.  They still receive an instance key, and they return it back, without having to know anything about how the phone company stores their information.

 

-Keith

-----Original Message-----
From: Michael Shenfield [mailto:mshenfield@rim.net]
Sent: Friday, November 07, 2003 12:55 PM
To: Keith Swenson
Cc: ASAP; David RR Webber; Mayilraj Krishnan; Jeffrey Ricker
Subject: RE: [asap] Factory in ASAP

Thanks for good words. I understand your position but would like to clarify mine. "Wireless friendly" == asynchronous, but...it's not an asynchronous web service as per your view. There is nothing in the "asynchronous" concept that requires control and monitoring, asynchronous only means that response is not synchronized with the request. There are many issues (see my email from Oct.8) that I see essential for asynchronous WS specification. Again, I am not against support for control and monitoring - these are quite useful features - but one should be able to deploy a simple asynchronous Web Service that just sends correlated notification(s) to service requestor when the operation is completed. No factories, control, or monitoring - just a simple request-notification model. There's a number of ways to implement such model but we need to have a standard one. BTW, I like the header approach :)

I am sure there are other people in the group who misread (or underestimated) the charter statement on control and monitoring and joined under assumption that they will be contributing to the "general" asynchronous WS specification. Nevertheless, I don't want to hijack the agenda and direction of this committee driving it against the charter. My recommendation to the group is to identify optional and required features for ASAP compliance - this will drive an adoption of the spec.

Cheers,

 

Mike

-----Original Message-----
From: Keith Swenson [mailto:KSwenson@fsw.fujitsu.com]
Sent: November 7, 2003 1:57 PM
To: 'David RR Webber'; Michael Shenfield; Keith Swenson; Mayilraj Krishnan; Jeffrey Ricker
Cc: ASAP
Subject: RE: [asap] Factory in ASAP

But what is the charter if it is not the definition of the group?  The purpose of the charter is to define what is and is not suitable for discussion in this forum.  If we don't adher to the charter, then we risk losing focus, and risk failing to produce anything at all. The people that signed up for the group did so on a basis of what the charter said.

 

It is understandable that someone may have joined the group without understanding completely the charter.  To me, the essense of what distinguishes an asynchronous service from other is the ability to monitor and control it. It is not simply a normal service that takes a long time. It is a service that might take long enough that you might change your mind and cancel it.  Without the ability to monitor and cancel, we are not solving the problem defined by the charter.  I am open to discussion on this, but to me it is pretty clear.

 

Michael is not interested in this.  He instead is interested in services that are wireless friendly.  This is an interesting and important topic, but this is not the "Wireless Friendly Service Protocol" technical comittee.  I deeply regret discouraging his input, because he has provided the best input so far in the group, and he clearly is knowledgeable in his field.  But in order to fair to everyone who has signed up for this group, I feel I must try to keep the discussion focussed on the subject defined by the charter.

 

If someone wants to change the charter, then please take that discussion into a subcommittee and off the main list.  Then propose the new charter to the group and put it to the vote.  Until that time, I want to focus on the problem defined by the current charter.

 

-Keith