[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[alf-dev] RE: Declaring ALF events
|
correction
I have posted the content of this email to the alf
wiki
Tim Buss,
Serena
From: Tim Buss
Sent: Wednesday,
September 06, 2006 9:45 AM
To: 'ALF Developer Mailing
List'
Subject: Declaring ALF events
For discussion in the Various ALF vocabulary
groups.
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
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.
Attached are some
experimental schemas and WSDL 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
first two files are the base schema/wsdl supplied by ALF updated with the
latest round of simplification (and with a few gratuitous name changes that I
felt necessary - this being our last opportunity to do such things.
This will be described elsewhere and not relavent to this
discussion)
ALFEventBase_001.xsd
ALFEventManager_001.wsdl
These two files are
for a fictitious tool that needs to declare events
MyALFEvents_001.xsd
MyALFEvents_001.wsdl
The xsd is derived
from the ALFEventBase_001.xsd and defines derived restricted types. These
restricted type also declare the specific Detail and Extension data that
accompanies the particular event. A few variant have been defined to illustrate how restrictions can be combined to create a more compact
schema when particular values are valid to use interchangeably (eg any one
of these object types can come with this event). I think that this
combination is actually a bad idea for reasons discussed
below.
The WSDL uses
the derived types to redeclare the ALFEventManager WSDL in terms of the
more restrictive and details tool specific types.
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.
