ALF/Vocabularies/Event Declaration Schema

ALF Wiki Home

Event Declaration

There are a number of goals we wish to achieve.

1. A tool needs to define the Details and Extensions that come with particular event types such that we can design a service flow to access the Detail and Extension data in the event but that same event can also be handled by a ServiceFlwo that only understands the Base Event (or if applicable only the vocabulary defined event)

2. We need to be able to enumerate the possible events as explict combinations for inclusion in the event dispatch map.

3. A design tool may wish to enumerate the possible events to allow a user to pick one to design to. For most BPEL tools this probably means picking a WSDL PortType but for other tools a Service defintion may be required.

Attached is an example WSDL with embedded schemas that illustrate how a tool might declare its ALF events.

The basic technique used here is to define schema "restriction base" derived types that allows you to tighten the value range or other restrictions on certain elements in a complex type. In this way we can declare a type that is an ALFEventType but that only allows an event type of "ThingCreated" and an object type of either "Thing1" or "Thing2" for example.

The following sample is derived from ALFEventBase_1.xsd and ALFEventManager_1.wsdl. These are described elsewhere (see ALFEventBase_1.xsd and ALFEventManager_1.wsdl in the Architecture section)[[1]]

The following file is for a fictitious tool that needs to declare events

MyALFEvents.wsdl

The new types are restricted derivations from types defined in ALFEventBase_1.xsd . The restricted type also declares the specific (Vocabulary) Detail and Custom Extension data that accompanies the particular event.

The WSDL uses the derived types to redeclare the ALFEventManager WSDL in terms of the more restrictive and details tool specific types.

Solutions to meeting goal #1 - defining specific events that can be handled as base events In schema it is not possible to declare an element as having a type that is a union of complex types. "Choice" comes close but it introduces an <element> and is really a choice of elements that may have different types. Consequently, it is not possible to simply re-declare the base event messages and port type using a union type.

A solution is to declare new messages and ports, one set for each event. This is problematic if the recommended WS-I compliant Document Literal style is used. This defines the WSDL message in terms of an element. To use the derived type we would need to use a new element to define the message since a particular top level element can only have one type. The unfortunate consequence of this that the new message would have a different root element than a base event message. Consequently, at runtime, the message couldn't be handled generically as a base event but would require a service flow define specifically for it. This is a serious drawback.

Two possible solutions are:

1. use WS-I compliant RPC literal or

2. have the Event Manager understand the type of the event and fix up the message at runtime.

RPC-Literal seems to provide the lightest weight solution of these two. It defines the WSDL messages in terms of types. Thus our new messages can be defined using the restricted derived types and consequently a custom message looks just alike a base message at runtime. The main issue with RPC-Literal is how widely it is supported since it it not generally the preferred option.

Having the Event Manager understand the type requires more complex configuration of the event-action map so it is not preferred but may be considered as a back up solution should the need arise.

Solutions to meeting goal #2 - enumerating valid event definitions for inclusion in an Event-Action Map The technique of defining the set of possibilities via type restrictions is powerful and allows considerable flexibility as far as how valid combinations can be expressed. We can go from full permutation - any event type can have any object type to full declaration of just the valid combinations - eventA and objectA, eventA and objectB etc. A potential problem is that these combinations are not easily distilled from the schema.

For this reason it may be preferred to explicitly declare separate services, portTypes etc in the WSDL for the various valid combinations. Then it is only necessary to pick the particular service you required and read its event and object combination. Failing this all combinations of event Type and object Type must be considered valid

Solutions to meeting - goal #3 - enumerating valid event definitions for the purposes of creating a service flow specific to that event Tools should be able to enumerate service or portType declarations. It is unclear how easy it would be to check that the types used by the event definition are, in fact, derived by restriction from the base event schema but it is theoretically possible. Again, the more explicit the Event declaration is about valid combinations the easier it is to construct an valid service flow.

WSDL/Schema

MyALFEvents.wsdl This example shows a simple derived event definition with both a Vocabulary extension and a Custom extension. The XSD schemas and the WSDL are combined into a single file for simplicity although it is generally more flexible to separate them.

Note that a real vocabulary schema would define its own set of derived event types. A a tool supporting a vocabulary must derive its event schema from that vocabulary schema adding its customizations and exclusive events. To use a tool with not customization it should be possible to use the vocabulary schema as to define the the corresponding service flows. How well this works will depend on how well the tool implements the base vocabulary events

Note: A potential problem with vocabulary schemas is that the object and event values could clash. The problem may arise when an existing tool that has defined is own events and objects now wants to support a vocabulary. We may solve this by pre-pending a namespace to these values.