OASIS Web Services Component Model (WSCM) TC

OASIS Web Services for Interactive Applications
Technical Committee

1 March 2002
teleconference 12:00-1:00pm EST
Minutes

Attendance

Agenda

1. Roll call
2. Approval of previous minutes
3. Update on Glossary
4. Discussion of Categories of Use Case (below)
5. Review of Example Use Cases: Aggregated and Integrated
6. As time allows, brief presentations on scenarios distributed since the last call: Insurance Enrollment, Contact Mgmt, AllMaps mapping, Portlet

Categories of Use Cases:

The working set of use case categories is as follows:

Aggregated: Pass-through tiling of independent Producer components, no data initialization or return of results, no synchronization across multiple components.

Included scenarios: Portal (WSRP level of function)

Integrated: Consumer enabled for programmatic initialization of Producer data and UI properties, defined schema for input and return values, still no synchronization across components.

Included scenarios: Smart buyer, Mortgage calculator, Beauty Boutique, Universal bank, Healthcare enrollment engine, Employee contact search, Syndication of traveler's checks (data fed from EuroVacations to FI producer)

Orchestrated: Interleaved experience between Producer and Consumer with both synchronization across multiple components and flow composition.

Included scenarios: Financial charting, Product configurator, Multimedia sports portal, Travelers check / Debit card, Mortgage calculator

Composed: Aggregated, Integrated, or Orchestrated collection of services are in turn republished as first-class web service.

Included scenarios: Any multi-tier scenario, e.g. HealthNow Insurance Enrollment

Meeting

Minutes approved.

Previous Action: Charlie to follow up (on Sasha's list), there may be one we haven't covered.
Resolution: Think we're all set on scenarios now.

Previous Action: Peter - volunteered to post that information to the mail list.
Resolution: Info was given to Dan to incorporate into the scenario.

Previous Action: Eilon to post Mapquest scenario.
Resolution: done.

Previous Action: Charlie - to send out chart of communications, variabilities.
Resolution: Not done, but in light of Use Case consolidation we'll see at end of today whether it will be useful at this stage.

There's been an informal subcommittee active in determining that Use Case subset [ Dan, Graeme, Alan, Eilon, Gil, Rex, Ravi, Rich, Kevin, Aditi, Monica, Charlie ]. Others are welcome to join, there will be another telecon next week for further refinement.

All feedback to date has been incorporated.
action: all - please take a look at the list of words to be deleted. If there are no objections they'll be removed by the time of the next conference call.

Royston has volunteered the resources of HP Labs in Palo Alto for the next meeting.
action: Graeme - pass list of all prospective attendees along to Royston to give out directions.

As we go through this exercise need to get a feel for what we think is the right level of detail in order to get to the next level (of requirements) from them.

(PDF sent out earlier in the week).

Aggregated

No interaction between service and container / portal. This maps to WSRP. The emphasis is more on the producer side.

Q: Will be interesting to see if that mapping is how WSRP see themselves?
A: True, and they might expand their box somewhat. Maybe expand into customization, address user admin, etc.

Customized

Changing the look and feel through what we called "adaptation points" before. eg, might want to change the menu bar.

• Will be a question as to how much is exposed by the producer, as opposed to prior setting of properties, calling methods etc before the main service is invoked and the producer generates the output.

Integrated

Data is exchanged at a fine grained level, this is a "call-return" model. It's separate because many scenarios fall into this category.

By "integrating into a new web app" we probably mean access to the webapp in a call-return model. Clients need a handle to the producer and some knowledge of data formats. So the focus should be "access" and "specification".

Q: So - the event comes from downstream, needs to be delegated to a producer and we want to observe it and maybe modify it, so need to understand data formats for that reason?
A: This is not really that - here the consumer is only presenting, but needs understanding of the methods available on the producer and the data structures to be sent/returned.

Q: The difference between a "web service" and a "web app"? Is this web app a web service?
A: No, in this case the consumer is pulling in web services and presenting their results, it's not a web service itself. The web app described is a conventional no-service implementation producing output for devices. This case is not multiple actors either. Just single producer and consumer.

Q: Is the consumer looking at the data?
A: Yes, but at the end of the invocation - the producer is invoked, the service runs without interruption and the consumer gets the results for display.

• We might have another Use Case that details "snooping" of the data - we'll hold that thought for now.

So for this Integrated case we just need 2 basic methods on the producer - "start" and "finish".
(Actually just "start"?).

Coordinated

This is in-page "wiring", multiple components talking to each other. Eg, stock quote and Expedia examples lend themselves to this. Eg, the graph and symbol / history coming from different producers and WSIA application coordinates the views.

Previous Use Cases did not have multiple producers. This Case implies coordinating interactions of multiple producers.

Another difference is that there may be a requirement in here for a finer degree of communication of state between the consumer and the producers in order to do this.

Orchestrated

Coordinated is "side-by-side". Orchestrated is a time-based flow and process flow. Eg, bank plugging in their own payment page to allow payment by account debit rather than credit card.

There is a potential for describing (and leveraging) flow at both the consumer and producer levels here, so this Use Case also sheds light on consumer and producer flows.

The Integrated case implies clean points of invocation of producer. In the orchestrated case the lines become less clear. In this Orchestrated case we take over steps in the flow. So if the producer had the notion of a flow of steps (eg installation wizard) we're talking about how to intercede into that flow.

Q: Who does the orchestration?
A: We think it's the consumer in both the Orchestrated and Coordinated cases. But there's nothing to restrict the producer from altering his output flow based on who the consumer is (and the consumer might modify that!). Also the consumer needs to give feedback to the producer (via initial parms, setup methods, events, etc). So there are flows on both sides and we need to consider the interaction/interplay of the flow changes at each end of the conversation.

Republish

Use all of the above and republish as a new service.

Aggregation could be republished just by re-routing interactions to individual producers, exposing them as a collection of separate services, or to the other extreme of publishing as an integrated "new look" service.

Q: Is there any change in what is republished?
A: Taking the wizard example of consumer adding an additional step, then yes - to the outside world it just looks like one application, a 4 step wizard.

We should be describing flows at a high level. Should detail the sequence of steps taken by the producer and consumer and the interactions between them. Not determining how, just what. We want to do this on the Customized Use Case. Ths sub group will go into detail on the Customized Use Case first.