RE: [asap] Factory in ASAP

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:]
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:]
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