SEs as containers

Julien,

Service engines come in all sorts of flavours. One possible service engine type is an EJB container. A simpler one to reason about is an XSLT transformation engine, used to convert XML documents from one schema to another.

By itself, an XSLT service engine is of little use when it is freshly installed. It doesn't "know" how to do any transformations. (In WSDL terms, it doesn't have any services to offer to consumers yet.) By deploying an XSLT style sheet to the engine, the engine is configured to offer one transformation service. By deploying another style sheet, the engine offers a second service, and so on. We speak of the XSLT service engine as a "container" of style sheets. Each style sheet it contains turns into a service offered to other components. Style sheets can be removed (undeployed), thus removing a particular service.

This idea of containment is generalized in JBI; any component can (but does not have to) be a container. This allows the user to flexibly configure which services are offered (and consumed) by components by use of deployment (at run time), rather than reconstruction (and reinstallation) of the component.

As stated above, components don't have to be containers. (Support of the ServiceUnitManager SPI is optional). A component can have hard-coded logic for both services it offers and services it consumes (if applicable). An example of such a service engine is an application adapter, which exposes a particular application as a service. The functions provided by the application are presumably fixed, and will not change unless the application itself is altered. This would be a good candidate for "hard coding" the services used and provided by the SE.

I hope this is of help,

-Ron

RonTen-Hovea at 2007-7-15 18:10:52 >