RE: [asap] Factory in ASAP

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

Title: RE: [asap] Factory in ASAP

The factory concept is the central concept to this whole approach.  Of course, there are an infinite variety of ways that one might approach a particular problem.  This particular approach uses a small number of generic "operations" on a large number of "resources".  The meaning of the operation depends on the address of the resource.  This is the "Resource Oriented" approach.  The other approach is an "Operation Oriented" approach.

One should not be concerned about the multiplicity of the factories.  The existance of a factory does not mean that it takes up resources on the host machine.  The factory address can have data values encoded into it.  I can, if I wish, claim that I have 300 Million factories, one for each person in the USA, by making the factory address have a SSN as a parameter (or any other disambiguating value) in the address.  I don't have to make 300 million records ahead of time.  There is, then, no reason to try to reduce the number of factories, nor is there any basis to equate a minimal number of factories to a minimal feature set.

The WWW functions on this principle of a few operations on a large number of addresses.  For example, instead of using the web, you could define an operation to retrieve the basic page, then an operation to retrieve each graphic on the page, and another operation to retrieve the style sheet for the page, etc.  Some people would claim that this is a "good" way to design the system because getting the style sheet you use an operation specifically for getting the style sheet, and what you get back from this operation is always a style sheet.  Hence, it is strongly typed.  Instead, the web merely makes the page, the graphics, and the style sheet have different addresses.  The same GET operation can be used to get each one.  Plus, I can remain confident that if the future brings a new data type that can be embedded in a page, the same GET operation can retrieve that data equally well.  Some people will complain that to display a page you need to make a number of GET operations instead of one.  True.  Those same people might argue that a single XYZ operation would be "simpler".  This is NOT true, because the specific information about the XYZ function must be specified some way in order to get the basic linking accomplished.  One problem, among many, is that servers and browsers need to be upgraded simultaneously in order to get new capabilities.  Simultaneous upgrade does not happen in the real internet world.

Back to ASAP: lets consider a real example.  A car dealer has two asynchronous web services: one that people can use to make an appointment at the garage to get their car repaired, and the other to order a particular accessory for a car.  The reason I pick these examples is because they are things that have a "duration" -- they persist over time.  There should be no disagreement that for a customer to arrange for a repair appointment some data (expressed as XML) needs to be sent from the customer to the car dealer, and that for ordering a accessory a different set of data needs to be sent.  This discussion then is really just over how to talk about how these two pieces of data are different.  Some approaches will make the "operation name" be different between the two blocks of data.  The ASAP approach makes the "address" be different.

For this scenario, using an "Operation Oriented" approach, we could define operations for CreateCarRepairAppointment, and CreateAccessoryOrder.  We would also need to define operations for CheckCarRepairAppointmentStatus, CancelCarRepairAppointment, ChangeCarRepairAppointment, CheckAccessoryOrderStatus, CancelAccessoryOrder, and ChangeAccessoryOrder.  The instance is automagically created behind the scenes, the correlation is encoded somewhere in the data passed. 

Using the "Resource Oriented" approach, we say there is an address for "CarRepairAppointment" and a different address for the "AccessoryOrder".  Specifically, these are the addresses of the factory.  Knowing these addresses, we can call the generic CreateInstance operation.  We get an instance address which has the correlation information encoded into it.  We then can call the generic Cancel (actually Terminate), Check (actually Get), and Change (actually Set) on the instance.

As you can see there is a one to one mapping between these two approaches.  The same number of actual messages is passed, the same amount of data must be stored.

The reason for taking the "Resource Oriented" approach becomes more clear when you carefully consider what must be done in order to link two systems together.  There are systems that are designed to be able to start remote asynchronous processes.  They already know about the basic operations: Create, Get, Set, and Terminate.  In order to link such a system to the remote service, you must give it the information to link.  Using the resource oriented approach, you only need to give it the address of the Factory resource.  On the other hand, using the "Operation Oriented" approach, you must first tell that system which operation is the create operation.  You have to program this somehow.  You must tell it which operation is to be used to cancel the remote service.  Etc. 

Once you buy into the basic idea that actual operation is a combination of an address and a generic operation, there are some very cool things that can be accomplished very easily:  Imagine that company G build (through any means) a system that automatically call the AccessoryOrder operations.  Company G is a trusted partner who brings a lot of business, so the car dealer implements a "Pre Approved Accessory Order" that handles the order in an expedited manner.  Simply by changing the address of the factory, all the associated operations are changed congruently, and the system interacts with the expedited process.

For this discussion, I used a NamingConvention:  CreateXXX, CheckXXXStatus, ChangeXXX, and CancelXXX.  This might be an alternative way to get the same benefit.  No such naming convention exists.  The naming convention approach gets really nasty when you want to encode something like a SSN into the address.  You would have 1,200,000,000 operations.  We can easily communicate addresses of a factory, but communicating the names of the correct 4 operations from a field of 1.2 billion is somehow less comfortable.  Of course you could hide this by having 300M virtual WSDL files (generating on demand of course so it does not take any space) but the linking of operations is normally considered a design time activity.  Most systems to call remote processes are not really designed to take a WSDL file at run time, search out the operation necessary according to a naming convention, and then call that operation.  It is messy if you want this kind of flexibility.  On the other hand, the "Resource Oriented" approach is designed for exactly this kind of flexibility.

In summary, please think carefully about the "DYNAMICS" of linking systems at run time as is necessary in a real life internet environment where change is constant, and the systems you are linking to are not under your control.

-Keith

-----Original Message-----
From: Michael Shenfield [mailto:mshenfield@rim.net]
Sent: Wednesday, November 05, 2003 1:47 PM
To: Mayilraj Krishnan; Jeffrey Ricker
Cc: ASAP
Subject: RE: [asap] Factory in ASAP

I already expressed my concerns about "Factory" concept. In all existing Web Services platforms that I am aware of the "Factory" is invisible for the WS developer and non of her/his concern at the time of development and deployment. I think we should step back and define a minimal scope of ASAP (as agreed at the last two conference calls). I doubt "factory" should make it there.

-----Original Message-----
From: Mayilraj Krishnan [mailto:mkrishna@cisco.com]
Sent: November 5, 2003 3:32 PM
To: Jeffrey Ricker; ASAP
Subject: [asap] Factory in ASAP

So far I have been thinking we need just only one factory for ASAP
implementation or
the implementation of services could be conveniently placed under one
logical ASAP factory.
I have two web services one is check inventory, shipping. Why do I need to
create
two ASAP factory? I think the ASAP pattern  is generic enough, it can just
have one factory.
[In terms of WSDL 1.2 we could map this to one ASAP (soap/transport
protocol) binding and one feature)]
Is that a right assumption?

Thanks
Mayilraj
At 11:35 AM 11/4/2003 -0500, Jeffrey Ricker wrote:
>I have attached files for describing the current draft of ASAP in WSDL.
>These are rough draft documents that have not been proofed.
>
>The asap.xsd describes the payloads
>The asap.wsdl is the basis for all ASAP services
>
>The concept here is to treat ASAP as a binding. The message structures
>are all the same, the programmer only has to define the ContextData and
>the ResultsData elements.
>
>The checkInventory.wsdl and productLevel.xsd files provide an example of
>this ASAP-as-a-binding approach.
>
>Ricker
>
>
>
>
>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.

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.

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.