RE: [asap] conference call today 10:00 am pacific

Wf-XML Demo

Goals

Provide a public forum to demonstrate what the protocol is in order to explain to the public.
Provide promotion opportunity for companies implementing the protocol.
Provide a deadline to force the completion of unfinished work.

At the October 2003 meeting of working group 4 it was decided that a demonstration of the Wf-XML 2.0 and the ASAP protocol would be a good way to encourage implementations. Because Wf-XML is an exchange protocol that works between two or more vendors, there is little impetud for a vendor to implement until enough other vendors also implement. The 'critical mass' threshold is a big impediment to adoption. Wf-XML is not difficult to implement, there is just little reason to implement it from the vendor point of view.

Several people in attendance had contects into government agencies who are always concerned about implementing standards. Governments are proactive in this respect because they do not want to appear to be wasteful of public funds, and the best way to assure reuse is adoption of standards. Also, governments are a big customer of integration technology. We felt, that if enough geovernment representatives committed to being "observers" of a demonstration, then more vendors might implement the protocol in order to be in the limelight of such a demonstration.

Industry analysts take an interest in the development of industry standards. Again, participation of analysts as "observers" would be even more encouragement for vendors to show off their wares.

Pitfalls to avoid

Clearly the success of such a demonstration is dependent upon careful planning. The word must be distributed widely so that everyone has a chance to participate. Vendors who find out about the demo too late will tend to actively downplay the demonstration vbecause they did not get a chance to participate. Of course, vendors are not going to be interested until they hear about who the observers are going to be, so these must be set up well in advance.

Deliverables

WfXML Demo Plan: (Keith Swenson) The purpose of the plan document is to communicate accurately and completely the key milestones and deliverables. While we have plenty of time, each milestone must be achieved in a timely manner to assure success. This must read and approved by the key people: Layna Fisher, Jon Pyke, Mike Gilger, Michael zur Muehlin, Mike Marin, (SAP), Jeffrey Ricker, Moshe Silverstein.

Observer Brochure: The purpose of the observer brochure is to explain the purpose of the demonstration to a person who might be intersted in serving as an observer. The benefits of serving as an observer: (observer is recognised as a VIP in the industry, special access to implementers of demo code, participation in celebration event if there is any, and of course they are helping promote standards development). The responsibilities: (no official responsibilities: time commitment is zero). The permissions: observer must permit us to list them as an observer by name & organization (no adresses included in listing). Our commitment to them: proper use of name list exlusively for this event, and to communicate progress of the demonstration to them in a timely manner.

Participant Brochure: (???) purpose: to explain exactly what is required of a participant. It will list the important milestones (demo day, pre-qualify test about 2 weeks earlier, intent registration date about 2 months earlier). It will refer to the scenario spec. It must list the observers that have been identified so far (this will be important to persuade them to participate.) The responsibilities: (implementation or course, they must send a representative to the event to describe in person the implementation details.

Scenario Definition: (Jeffrey Ricker) purpose: to describe in detail the scenario that must be implemented. There should be several levels to the schenarion; level 1 should be a simple start and receive completed message designed to allow as many participants as possible be involved. The scenarios must be bidirectional -- both client and server -- so that any implementer can be hooked up with any other implementer and the interaction demonstrated. Jeffrey Ricker has volunteered to write up a scenario that he has been using as an example in the past.

Implementer's Cookbook: (Keith Swenson) purpose: to describe how to implement the protocol in a non-formal way, giving hints at how to approach the most important parts of the spec without getting bogged down in the details of all the possibilities. This is already written and included as a chapter of the WfMC Workflow Handbook for 2003.

Test Tool Spec: (???) It will be very helpful if some simple test tools could be developed to help in the development. Should include (1) a simple Java JSP implementation that implements a basic asynchronous service ... a 'delayed answerback' service that responds with a completed message some number of seconds after starting, (2) an introspection page that accesses a service and displays the important parameters, (3) an interactive invocation utility that displays a simple form for all the variables and allows you to start a service. This latter one must have an observer address so that it can receive the complete message, and somehow display a list of completed messages that it has received. These tools should be developed in an open source way so that all the implementers can make use of them for testing their own implementations.

Key Roles

Standard Development: We must have a specification of suitable quality to publish. People are on board already to do this, and this is clearly a very key role for the success of this effort.

Observer Relations: We need several people to actively find observers. Primarily we are interested in people in government and industry analysts. Secondarily academic observers are also desired (but vendors don't view universities as an important source of revenue). Secondarily key people from industry that might be important customers of this protocol are also desired. Offers to help in this capacity have been received from Hideshiga Hasegawa in Japan, and David Hollingsworth in England.

Participant Releations: Essentially support to the implementers to provide timely answers to technical questions about the spec. Active members of working group 4 should be involved in this. Another aspect of this job is to find ways to distribute the participant brocure widely to all possible participants so that we can be sure that no one is left out due to not knowing about the event. Several

Demo Judge: People who commit to inspect the demo implementation and verify that the protocol is correctly implemented. Judging may be done from any location (they do not need to attend the final event in person) Observers may if they wish participate as Judge. Say we have 6 implementors, the judging activity will mainly be to pair up combinations from these 6 and show that they interoperate. Completeness would suggest that all N*(N-1) combinations be implemented.

Score Keeper: One person to collect the comments and results from the Judges and present them in a suitable manner on the web and also in a final document. Coordinates the work of the judges to avoid unnecessary overlap.

Test Developer: People to help implement the open source test tools.

Mechanics

The actual demonstration can be done on the internet. Each vendor will host their implementation on a machine with a public IP address. WfMC will host a small test program which is web based. It will allow internet visitors to enter the URL of a vendor process to be tested. Then a form will appear where the user can enter the variables of the process to be started. Once started, the status of the process can be monitored until it is completed. The test program will have a web address from which it can receive the Completed message, and will report this to the user.

The advantage of running the test on the internet is that we will not need to set up any special equipment in any particular location. Vendors can participate without renting space at a show. The WfMC does not take a risk on having to rent a room to set up and test the equipment, and more importantly each vendor has all the experts on site in case there are problems. Finally, the demonstration can be a permanent one, allowing new vendors to be added at any time, and existing implementation to be tested over many months.

Several levels of integration will be outlined. The first level should be trivial to implement, to allow for as many participants as possible. There should be a second and third level to allow more complete implementations to show off their capabilities.

Schedule

The goal is a demonstration in the first week of June.

asap message