I am not 100%
happy with the result since this requires rather more schema slinging than I
feel is ideal. There are also some possible runtime problems with the
WSDL.
Problems with the
WSDL - goal #1
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. The
unfortunate consequence of this that the message "element" of the event message
must be named for the derived event. Since the event operation must still
be EventNotice we must break the WSDL "Document Literal Wrapped"
convention of the operation and the message element having the same
name.
The
runtime consequences of this depend on what the tool acutally does when it sends
its event message to the EventManager.
It could treat its
declarations as simply "for information" descriptions and not be bound to the
message name. Consequently, at runtime the tool, will always send the
ALFEvent message as defined by the ALFEventManager_001.xsd. That is the
message will contain a single element called "EventNotice". The content of
the message will vary and will be one of the variants described be the tool schema.
Alternatively, it
could use its event message definitions literally and send then with the tool
defined element name. The operation must always be EventNotice (or
EventNoticeWithReply) but the messages would essentially be event dependant
since there root element name would change.
Which of these two
possibilities we choose probably shouldn't matter to the EventManager so
long as it knows to always search below the root element when finding the fields
it uses to dispatch on. However, the root element name may matter to the
BPEL flow definition. If a flow is designed to expect a particular message
it will probably be the case that it has to have the correct name for its root
element. This probably means that the literal message definition technique
is required. This may have the undesirable effect of forcing a service flow to
be product specific when it doesn't otherwise need to be. This issue remains to be resolved. Probably need to do some
experiments.
Problems with the
valid combinations - goal #2
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 declartion of just the valid combinations - eventA and objectA, eventA and objectB etc. The problem is that these combinations
are not easily distilled from the schema. It is probably necessary to walk
the tree of event type definitions as XML and accumulate the values that are
possible for any particular element. Then you would need to discover
which values of another element make valid combinations. The
information is there but it is not easy to derive.
Problems with
enumerating the events - goal #3
While it is probably
easy enough to enumerate port types in the WSDL and find those that contain EventNotice (or EventNoticeWithReply) operations there may be difficulties if
the events combinations are not fully and individually declared. This
can only be determined by walking the schema. Consequently we should probably recommend that a tool not use a combined declaration for EventBase
combinations but should explicitly declare the valid combinations as separate
types. A problem is there is probably no way to enforce
that.
Tim Buss
Serena Inc.
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
Attachment:
ALFEventBase_001.xsd
Description: ALFEventBase_001.xsd
Attachment:
ALFEventManager_001.wsdl
Description: ALFEventManager_001.wsdl
Attachment:
MyALFEvents_001.xsd
Description: MyALFEvents_001.xsd
Attachment:
ALFEventManager_001.wsdl
Description: ALFEventManager_001.wsdl