Mark Rosenberg, Rich Thompson, Carsten Leue, Steve Pruett (for Jeff Broberg), Gino Filicetti, Mike Freedman, Rex Brooks, Alan Kropp
Rich mentioned that a charter is required for this committee to be an official OASIS subcommittee. Alan will circulate a draft charter before next Tuesday’s telecon.
The group is now working off the WSIA requirements list forwarded by Charlie earlier. Since many of these were outlined at a high level in last week’s call, we didn’t walk through them again.
As many of the requirements in the embedded case have to do with lifecycle, this will become a (if not the) main area of concern for the joint interface.
Alan outlined four basic lifecycle states that an embedded service should support (capitalized terms are.
The Consumer does not yet “know” about the Producer or producer’s services.
The Consumer has knowledge about the service(s) a producer offers. There was some discomfort with the terms “bind” or “bound”, which are overloaded.
The service is either in the process of, or is available to respond to end-user requests.
The service has been deactivated, i.e. unable to respond to end-user requests. It is still “known” in the Consumer context. Either the Producer or the Consumer could be the responsible party.
Carsten raised the point that from WSRP perspective, this does not capture the level of detail necessary to support, for example, the template state.
Alan, Rich, et al: attempting to describe a lifecycle that accounts for simplest embedded use case (a Consumer directly integrates a service from its access point, no configuration, no negotiation of credentials, persistence models, etc.). This should be the base for more complex specializations, including WSRP and the more advanced WSIA use cases.
The above states are really placeholders for a variety of Consumer-Producer-End User activities. Any of them could be further decomposed into multiple optional “sub” states. The idea is to settle on these high level definitions first, and then drill down into greater detail for illustrative purposes.
Mike brought up the concept of portlet container on the Producer side, which could be considered an abstraction or “nuance” that we would want to overlay the simple lifecycle concept with when we drill into greater detail for the portlet case, in particular. How does the Producer - Container (Portlets) - Consumer lifecycle map to the simple lifecycle? Does the container mask some of the state transitions of the contained portlets from the Consumer’s view?
WS-Security discussion in WSRP is interesting, in that this a meta-specification for handling some of the security standards being tracked in the embedded case.
Rex raised a concern as to markup fragments specification. Is XPath the consensus emerging from WSRP? Gino mentioned that the discussion has centered more on XHTML anyway, and so XPath seems like a natural choice as the fragment spec.