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.
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.
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.
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.
The goal is a demonstration in the first week of June.
The 'order' is placed by creating the process instance. 20 seconds later, the process completes. The total is calculated automatically, and the anticipated and actual ship dates are set to time values that occurred during the ten seconds of the process.
In order to successfully complete scenario level 1, it is required that a Completed message be sent back to the observer, and that it contains the result data.
During each of the 4 phases, the Status variable is filled in with a suitable value. The point of this is to allow the real time monitoring of the process. As the user requests process state in realtime, the proper status is returned. OF course, at the end the completed message is sent. The status will be able to be retrieved by polling for at least 60 seconds after the process completes.
All three scenarions are service side scenario. We then need some client side engines that can integrate with the server side. THis involves some process definintion capabilities.