Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "ALF/Vocabularies/Event Declaration Schema"

< ALF
(Event Declaration)
 
(14 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
__TOC__
 
__TOC__
 +
 +
[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]
 
== Event Declaration ==
 
== Event Declaration ==
  
 
There are a number of goals we wish to achieve.
 
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
+
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.
 
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.
+
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 are some experimental schemas and WSDL that illustrate how a tool might declare its ALF events.
+
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 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 1st round simplification base schema/wsdl (version 001). This is described elsewhere and not relavent to this discussion see ALFEventBase_001.xsd and ALFEventManager_001.wsdl in the Architecture section [[http://wiki.eclipse.org/index.php/ALF/ALF_Schemas]]
+
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)[[http://wiki.eclipse.org/index.php/ALF/ALF_Schemas]]
 
   
 
   
The following two files are for a fictitious tool that needs to declare events  
+
The following file is for a fictitious tool that needs to declare events  
 
   
 
   
MyALFEvents_001.xsd
+
MyALFEvents.wsdl
MyALFEvents_001.wsdl
+
 
   
 
   
The xsd is derived from the ALFEventBase_001.xsd and defines derived restricted typesThese 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 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.
 
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.
 
 
   
 
   
 +
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.
 +
 
   
 
   
Problems with the WSDL - goal #1
+
Solutions to meeting goal #2 - enumerating valid event definitions for inclusion in an Event-Action Map
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 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.   
+
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.
+
  
== Schema ==
+
For this reason it is 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
MyALFEvents_001.xsd
+
 
<pre>
+
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.''
 +
 
 +
<code><pre>
 
<?xml version="1.0" encoding="UTF-8"?>
 
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:evt="http://www.eclipse.org/alf/XMLSchema/Events.xsd" xmlns="http://www.eclipse.org/alf/XMLSchema/Events.xsd" targetNamespace="http://www.eclipse.org/alf/XMLSchema/Events.xsd" elementFormDefault="qualified" attributeFormDefault="unqualified">
+
<wsdl:definitions
<xs:include schemaLocation="ALFEventBase_001.xsd"/>
+
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
<xs:annotation>
+
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
<xs:documentation>
+
xmlns:xs="http://www.w3.org/2001/XMLSchema"  
WARNING: PRELIMINARY VERSION DO NOT USE
+
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    </xs:documentation>
+
name="MyALFEvents"
</xs:annotation>
+
targetNamespace="http://www.eclipse.org/alf/schema/EventBase/1"
<xs:annotation>
+
xmlns:tns="http://www.eclipse.org/alf/schema/EventBase/1"  
<xs:documentation>
+
xmlns:evt="http://www.eclipse.org/alf/schema/EventBase/1"
Copyright Notice
+
xmlns:ext="http://www.example.org/MyEventExtensions"  
The material in this document is Copyright (c) Serena Software, Inc. and others, 2005
+
xmlns:evc="http://www.eclipse.org/ALF/ExampleVocabulary"
Terms and Conditions:
+
>
The Eclipse Foundation makes available all content in this document ("Content").
+
   
Unless otherwise indicated below, the Content is provided to you under the terms
+
  <wsdl:documentation>
and conditions of the Eclipse Public License Version 1.0 ("EPL").
+
WARNING: PRELIMINARY VERSION SUBJECT TO CHANGE
A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html.
+
 
For purposes of the EPL, "Program" will mean the Content.
+
      Copyright Notice
If you did not receive this Content directly from the Eclipse Foundation, the
+
      The material in this document is Copyright (c) Serena Software, Inc. and others, 2005, 2006, 2007
Content is being redistributed by another party ("Redistributor") and different
+
      Terms and Conditions:
terms and conditions may apply to your use of any object code in the Content.
+
      The Eclipse Foundation makes available all content in this document ("Content").
Check the Redistributor's license that was provided with the Content.
+
      Unless otherwise indicated below, the Content is provided to you under the terms
If you did not receive any such license, contact the Redistributor.
+
      and conditions of the Eclipse Public License Version 1.0 ("EPL").
Unless otherwise indicated below, the terms and conditions of the EPL still apply to the Content.
+
      A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html.
    </xs:documentation>
+
      For purposes of the EPL, "Program" will mean the Content.
</xs:annotation>
+
      If you did not receive this Content directly from the Eclipse Foundation, the
<!-- Begin BasicEventTypes -->
+
      Content is being redistributed by another party ("Redistributor") and different
<!-- These event declarations restrict the possible values for EventType, Object and Source.
+
      terms and conditions may apply to your use of any object code in the Content.
There are various options for declaring these derivied types depending on the valid combinations of EventType
+
      Check the Redistributor's license that was provided with the Content.
and Object values.
+
      If you did not receive any such license, contact the Redistributor.
If any EventType value can be combined with any Object value then all possible values can be declared in a single
+
      Unless otherwise indicated below, the terms and conditions of the EPL still apply to the Content.
type.
+
  </wsdl:documentation>
If only one or some EventType values can be combined with one or some Object value the separate types must be declared for the valid combinations
+
   
Parts of Source is generally constant for any particular product. -->
+
  <!-- ALF EventManager WSDL -->
<!-- MyBasicEvent1Type is restricted to an event with the value "My Product Event Type A", and an object with the type value, "My Product Object Type A" -->
+
<wsdl:import location="ALFEventManager_1.wsdl"
<xs:complexType name="MyEventBase1Type">
+
namespace="http://www.eclipse.org/alf/schema/EventBase/1">
 +
</wsdl:import>
 +
 
 +
<wsdl:types>
 +
 
 +
<!-- The various schemas are defined below.
 +
Generally, it is prefered to import these schemas
 +
This example is defines them in-line for simplicity.  
 +
-->
 +
 
 +
<!-- Example Vocabulary Extension
 +
This schema is a simple example of a Vocabulary extension.
 +
Generally, extension schemas such as this would be imported.
 +
This example is defined in-line for simplicity.  
 +
-->
 +
<xsd:schema xmlns="http://www.eclipse.org/ALF/ExampleVocabulary"  
 +
elementFormDefault="qualified"
 +
targetNamespace="http://www.eclipse.org/ALF/ExampleVocabulary">
 +
 
 +
<xs:complexType name="ExampleVocabularyExtension">
 
<xs:annotation>
 
<xs:annotation>
 
<xs:documentation>
 
<xs:documentation>
      </xs:documentation>
+
Vocabulary Event Extension
 +
</xs:documentation>
 
</xs:annotation>
 
</xs:annotation>
<xs:complexContent>
+
<xs:sequence>
<xs:restriction base="EventBaseType">
+
<xs:element name="ExampleVocabularyData" type="xs:string"/>
<xs:sequence>
+
</xs:sequence>
<xs:element name="EventID" type="EventIDType"/>
+
<xs:anyAttribute/>
<xs:element name="Timestamp" type="TimestampType"/>
+
<xs:element name="EventType" type="MyEventType1Type"/>
+
<xs:element name="Object" type="MyObjectData1Type"/>
+
<xs:element name="Source" type="MySourceType"/>
+
<xs:element name="PredecedingEvent" type="EventIDType" nillable="true"/>
+
<xs:element name="ApplicationName" type="ApplicationNameType" nillable="true"/>
+
<xs:element name="Environment" type="EnvironmentType" nillable="true"/>
+
<xs:element name="User" type="UserType"/>
+
</xs:sequence>
+
<xs:attribute name="alfEventVersion" type="xs:string" use="required"/>
+
</xs:restriction>
+
</xs:complexContent>
+
 
</xs:complexType>
 
</xs:complexType>
<!-- MyBasicEvent2Type is restricted to an event with the event value "My Product Event Type B".
+
 
It may contain object with type values of, "My Product Object Type B" or "My Product Object Type C"-->
+
</xsd:schema>
<xs:complexType name="MyEventBase2Type">
+
 
 +
<!-- Example Custom Extension
 +
This schema is an simple example of a Tool specific custom extension.
 +
Generally, extension schemas such as this would be imported.
 +
This example is defined in-line for simplicity.
 +
-->
 +
<xsd:schema xmlns="http://www.example.org/MyEventExtensions"  
 +
elementFormDefault="qualified"
 +
targetNamespace="http://www.example.org/MyEventExtensions">
 +
 
 +
<xs:complexType name="MyCustomExtension">
 
<xs:annotation>
 
<xs:annotation>
 
<xs:documentation>
 
<xs:documentation>
      </xs:documentation>
+
Custom Extension
 +
</xs:documentation>
 
</xs:annotation>
 
</xs:annotation>
<xs:complexContent>
+
<xs:sequence>
<xs:restriction base="EventBaseType">
+
<xs:element name="MyData" type="xs:string"/>
<xs:sequence>
+
</xs:sequence>
<xs:element name="EventID" type="EventIDType"/>
+
<xs:anyAttribute/>
<xs:element name="Timestamp" type="TimestampType"/>
+
<xs:element name="EventType" type="MyEventType2Type"/>
+
<xs:element name="Object" type="MyObjectData2Type"/>
+
<xs:element name="Source" type="MySourceType"/>
+
<xs:element name="PredecedingEvent" type="EventIDType" nillable="true"/>
+
<xs:element name="ApplicationName" type="ApplicationNameType" nillable="true"/>
+
<xs:element name="Environment" type="EnvironmentType" nillable="true"/>
+
<xs:element name="User" type="UserType"/>
+
</xs:sequence>
+
<xs:attribute name="alfEventVersion" type="xs:string" use="required"/>
+
</xs:restriction>
+
</xs:complexContent>
+
 
</xs:complexType>
 
</xs:complexType>
<!-- MyBasicEvent3Type is restricted to an event with the event value "My Product Event Type C".
+
 
It may contain object with type values of, "My Product Object Type B", "My Product Object Type C" or "My Product Object Type D"-->
+
</xsd:schema>
<xs:complexType name="MyEventBase3Type">
+
 
 +
<!-- The Tool's ALF Events.
 +
This schema shows some examples of how to declare ALF events by deriving schema types
 +
from the base ALF Event Schema
 +
Generally, it is prefered to import the schema.
 +
This example is defined in-line for simplicity.
 +
 
 +
-->
 +
<xsd:schema xmlns="http://www.eclipse.org/alf/schema/EventBase/1"  
 +
elementFormDefault="qualified"
 +
targetNamespace="http://www.eclipse.org/alf/schema/EventBase/1">
 +
 +
<xsd:include schemaLocation="ALFEventBase_1.xsd"/>
 +
 +
<xs:import namespace="http://www.eclipse.org/ALF/ExampleVocabulary" />
 +
<xs:import namespace="http://www.example.org/MyEventExtensions" />
 +
 +
<!-- Derived Basic Event -->
 +
<!-- This event declaration restrict the possible values for
 +
EventType, Object and Source by declaring derived types for those elements.
 +
See MyEventType1Type, MyObjectType1Type and MySourceType.
 +
There are various options for declaring these derived types depending on
 +
the valid combinations of EventType and Object values
 +
If any EventType value can be combined with any Object value then all possible
 +
values can be declared in a single type.
 +
If only one or some EventType values can be combined with one or some
 +
Object value the separate types can be declared for the valid combinations
 +
The Source is generally constant for any particular product. -->
 +
<!-- This example, MyBasicEvent1Type, is restricted to an event with the value
 +
"My Product Event Type A", and an object with the type value,
 +
"My Product Object Type A" -->
 +
<xs:complexType name="MyEventBase1Type">
 
<xs:annotation>
 
<xs:annotation>
 
<xs:documentation>
 
<xs:documentation>
Line 139: Line 189:
 
<xs:restriction base="EventBaseType">
 
<xs:restriction base="EventBaseType">
 
<xs:sequence>
 
<xs:sequence>
<xs:element name="EventID" type="EventIDType"/>
+
<xs:element name="EventId" type="EventIdType"/>
 
<xs:element name="Timestamp" type="TimestampType"/>
 
<xs:element name="Timestamp" type="TimestampType"/>
<xs:element name="EventType" type="MyEventType3Type"/>
+
<xs:element name="EventType" type="MyEventType1Type"/>
<xs:element name="Object" type="MyObjectData3Type"/>
+
<xs:element name="ObjectType" type="MyObjectType1Type"/>
 +
<xs:element name="ObjectId" type="ObjectIdType"/>
 
<xs:element name="Source" type="MySourceType"/>
 
<xs:element name="Source" type="MySourceType"/>
<xs:element name="PredecedingEvent" type="EventIDType" nillable="true"/>
+
<xs:element name="User" type="CredentialsType"/>
<xs:element name="ApplicationName" type="ApplicationNameType" nillable="true"/>
+
<xs:element name="EventControl" type="EmBaseType"/>
<xs:element name="Environment" type="EnvironmentType" nillable="true"/>
+
<xs:element minOccurs="0" name="BaseExtension"  
<xs:element name="User" type="UserType"/>
+
type="BaseExtensionType"/>
 
</xs:sequence>
 
</xs:sequence>
<xs:attribute name="alfEventVersion" type="xs:string" use="required"/>
+
<xs:anyAttribute/>
 
</xs:restriction>
 
</xs:restriction>
 
</xs:complexContent>
 
</xs:complexContent>
 
</xs:complexType>
 
</xs:complexType>
<!-- In order to restrict the EventType, Object and Source values we need to declare custom restricted types.
+
Depending how the allowed values for EventType, Object and Source combine we can declare either one type
+
<!-- Derived subtypes -->
that restricts to all possible values or a number of single value types or some combination -->
+
<!-- In order to restrict the EventType, ObjectType and Source we need to  
<!-- These EventType variants each have a single possible value -->
+
declare one or more custom restricted types.
 +
Depending how the allowed values for EventType, Object and Source combine  
 +
we can declare either one type for each element
 +
that restricts to all possible values, a number of single value types or  
 +
some combination  
 +
-->
 +
 
 +
<!-- Derived EventTypeType -->
 +
<!-- This example restricts to a single possible value -->
 
<xs:simpleType name="MyEventType1Type">
 
<xs:simpleType name="MyEventType1Type">
 
<xs:restriction base="EventTypeType">
 
<xs:restriction base="EventTypeType">
Line 162: Line 221:
 
</xs:restriction>
 
</xs:restriction>
 
</xs:simpleType>
 
</xs:simpleType>
<xs:simpleType name="MyEventType2Type">
+
<xs:restriction base="EventTypeType">
+
<!-- Derived ObjectTypeType -->
<xs:enumeration value="My Product Event Type B"/>
+
<!-- This example restricts to a single possible value -->
</xs:restriction>
+
</xs:simpleType>
+
<xs:simpleType name="MyEventType3Type">
+
<xs:restriction base="EventTypeType">
+
<xs:enumeration value="My Product Event Type C"/>
+
</xs:restriction>
+
</xs:simpleType>
+
<!-- =============  Object that triggered the event  ============= -->
+
<!-- MyObjectData1Type is restricted to one possible value -->
+
<!--The ObjectData type derivations illustrate how to combine a number of possible values that may be used interchangeably.
+
This can be useful shorthand to compact the event definitions by grouping set of values into a single definition.
+
The values in a set may overlap with other sets of the same type but care must be taken to ensure ambiguous or duplicate defintions results.
+
-->
+
<xs:complexType name="MyObjectData1Type">
+
<xs:annotation>
+
<xs:documentation>
+
      </xs:documentation>
+
</xs:annotation>
+
<xs:complexContent>
+
<xs:restriction base="ObjectDataType">
+
<xs:sequence>
+
<xs:element name="ObjectType" type="MyObjectType1Type"/>
+
<xs:element name="ObjectId" type="ObjectIdType"/>
+
</xs:sequence>
+
</xs:restriction>
+
</xs:complexContent>
+
</xs:complexType>
+
 
<xs:simpleType name="MyObjectType1Type">
 
<xs:simpleType name="MyObjectType1Type">
<xs:annotation>
 
<xs:documentation>
 
      </xs:documentation>
 
</xs:annotation>
 
 
<xs:restriction base="ObjectTypeType">
 
<xs:restriction base="ObjectTypeType">
<xs:enumeration value="My Product Object Type A"/>
+
<xs:enumeration value="MyObjectType1Name"/>
 
</xs:restriction>
 
</xs:restriction>
 
</xs:simpleType>
 
</xs:simpleType>
<!-- MyObjectData2Type is restricted to two possible values -->
+
<xs:complexType name="MyObjectData2Type">
+
<!-- Derived SourceType -->
<xs:annotation>
+
<!-- The SourceType has its own sub-types, ProductType and ProductVersionType,
<xs:documentation>
+
which must also be derived.
      </xs:documentation>
+
Typically a Product will only have a single value whereas ProductVersion may
</xs:annotation>
+
have multiple.
<xs:complexContent>
+
ProductVersion may combine with other derived types to allow version specific
<xs:restriction base="ObjectDataType">
+
events to be declared
<xs:sequence>
+
-->
<xs:element name="ObjectType" type="MyObjectType2Type"/>
+
<xs:element name="ObjectId" type="ObjectIdType"/>
+
</xs:sequence>
+
</xs:restriction>
+
</xs:complexContent>
+
</xs:complexType>
+
<xs:simpleType name="MyObjectType2Type">
+
<xs:annotation>
+
<xs:documentation>
+
      </xs:documentation>
+
</xs:annotation>
+
<xs:restriction base="ObjectTypeType">
+
<xs:enumeration value="My Product Object Type B"/>
+
<xs:enumeration value="My Product Object Type C"/>
+
</xs:restriction>
+
</xs:simpleType>
+
<!-- MyObjectData3Type is restricted to three possible values -->
+
<xs:complexType name="MyObjectData3Type">
+
<xs:annotation>
+
<xs:documentation>
+
      </xs:documentation>
+
</xs:annotation>
+
<xs:complexContent>
+
<xs:restriction base="ObjectDataType">
+
<xs:sequence>
+
<xs:element name="ObjectType" type="MyObjectType3Type"/>
+
<xs:element name="ObjectId" type="ObjectIdType"/>
+
</xs:sequence>
+
</xs:restriction>
+
</xs:complexContent>
+
</xs:complexType>
+
<xs:simpleType name="MyObjectType3Type">
+
<xs:annotation>
+
<xs:documentation>
+
      </xs:documentation>
+
</xs:annotation>
+
<xs:restriction base="ObjectTypeType">
+
<xs:enumeration value="My Product Object Type B"/>
+
<xs:enumeration value="My Product Object Type C"/>
+
<xs:enumeration value="My Product Object Type D"/>
+
</xs:restriction>
+
</xs:simpleType>
+
<!-- =============  The source (i.e, tool or product) that emitted the event  ============= -->
+
<!-- The values for Product and ProductVersion are constant for all events from a particular product installation -
+
ProductInstance and ProductCallbackURI are determined at install time an will not have declared restricted values -->
+
 
<xs:complexType name="MySourceType">
 
<xs:complexType name="MySourceType">
 
<xs:complexContent>
 
<xs:complexContent>
Line 260: Line 243:
 
<xs:sequence>
 
<xs:sequence>
 
<xs:element name="Product" type="MyProductType"/>
 
<xs:element name="Product" type="MyProductType"/>
<xs:element name="ProductVersion" type="MyProductVersionType"/>
+
<xs:element name="ProductVersion"  
<xs:element name="ProductInstance" type="ProductInstanceType"/>
+
type="MyProductVersionType"/>
<xs:element name="ProductCallbackURI" type="ProductCallbackURIType" nillable="true" minOccurs="0"/>
+
<xs:element name="ProductInstance"  
 +
type="ProductInstanceType"/>
 +
<xs:element name="ProductCallbackURI"  
 +
type="ProductCallbackURIType"  
 +
nillable="true" minOccurs="0"/>
 
</xs:sequence>
 
</xs:sequence>
 
</xs:restriction>
 
</xs:restriction>
 
</xs:complexContent>
 
</xs:complexContent>
 
</xs:complexType>
 
</xs:complexType>
 +
 +
<!-- Derived ProductType -->
 +
<!-- This example restricts to a single value -->
 
<xs:simpleType name="MyProductType">
 
<xs:simpleType name="MyProductType">
 
<xs:restriction base="ProductType">
 
<xs:restriction base="ProductType">
Line 272: Line 262:
 
</xs:restriction>
 
</xs:restriction>
 
</xs:simpleType>
 
</xs:simpleType>
 +
 +
<!-- Derived ProductVersionType -->
 +
<!-- This example restricts to a single value -->
 
<xs:simpleType name="MyProductVersionType">
 
<xs:simpleType name="MyProductVersionType">
 
<xs:restriction base="ProductVersionType">
 
<xs:restriction base="ProductVersionType">
<xs:enumeration value="My Product Version"/>
+
<xs:enumeration value="3.0"/>
 
</xs:restriction>
 
</xs:restriction>
 
</xs:simpleType>
 
</xs:simpleType>
<!-- Each event type or object type could be associated with different event detail data.
+
We need to declare the possible EventDetail types-->
+
<!-- Derived ALFEventType -->
<xs:complexType name="MyEventDetail1Type">
+
<!-- The actual event message is always an ALFEvent type
<xs:complexContent>
+
The derived type just restricts the possible values and declares
<xs:restriction base="EventDetailType">
+
what will be found in the extension areas.
<xs:sequence>
+
A tool that defines a CustomExtension data may define different content
<xs:any/>
+
for the each event-object combination if it needs to.
</xs:sequence>
+
For Vocabulary events the content of the Vocabulary extension is defined by
</xs:restriction>
+
the vocabulary schema which a tool must follow.
</xs:complexContent>
+
Vocabulary schemas provide for some extensibility and a tool may declare is
 +
own specializations for that.
 +
The same techniques are used but the extendable types are specialized to the
 +
particular vocabulary
 +
-->
 +
<xs:complexType name="MyALFEventType">
 +
<xs:sequence>
 +
<xs:element name="Base" type="MyEventBase1Type"/>
 +
<xs:element minOccurs="0" name="Detail"
 +
type="evc:ExampleVocabularyExtension"/>
 +
<xs:element minOccurs="0" name="Extension"
 +
type="ext:MyCustomExtension"/>
 +
<xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other"
 +
processContents="lax"/>
 +
</xs:sequence>
 +
<xs:attribute default="1.0" name="version" type="ALFSchemaVersionType"/>
 
</xs:complexType>
 
</xs:complexType>
<xs:complexType name="MyEventDetail2Type">
 
<xs:complexContent>
 
<xs:restriction base="EventDetailType">
 
<xs:sequence>
 
<xs:any/>
 
</xs:sequence>
 
</xs:restriction>
 
</xs:complexContent>
 
</xs:complexType>
 
<xs:complexType name="MyEventDetail3Type">
 
<xs:complexContent>
 
<xs:restriction base="EventDetailType">
 
<xs:sequence>
 
<xs:element name="MyEventDetailDate1" type="xs:string"/>
 
</xs:sequence>
 
</xs:restriction>
 
</xs:complexContent>
 
</xs:complexType>
 
<xs:complexType name="MyEventDetail4Type">
 
<xs:complexContent>
 
<xs:restriction base="EventExtensionType">
 
<xs:sequence>
 
<xs:choice>
 
<xs:element name="MyEventDetail1" type="MyEventDetail1Type"/>
 
<xs:element name="MyEventDetail2" type="MyEventDetail2Type"/>
 
<xs:element name="MyEventDetail3" type="MyEventDetail3Type"/>
 
</xs:choice>
 
</xs:sequence>
 
<xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/>
 
</xs:restriction>
 
</xs:complexContent>
 
</xs:complexType>
 
<!-- Each event type or object type could be associated with different ToolExtension data.
 
We need to declare the possible ToolExtension types-->
 
<xs:complexType name="MyEventExtension1Type">
 
<xs:complexContent>
 
<xs:restriction base="EventExtensionType">
 
<xs:sequence>
 
<xs:any/>
 
</xs:sequence>
 
<xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/>
 
</xs:restriction>
 
</xs:complexContent>
 
</xs:complexType>
 
<xs:complexType name="MyEventExtension2Type">
 
<xs:complexContent>
 
<xs:restriction base="EventExtensionType">
 
<xs:sequence>
 
<xs:any/>
 
</xs:sequence>
 
<xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/>
 
</xs:restriction>
 
</xs:complexContent>
 
</xs:complexType>
 
<!-- End BasicEventTypes -->
 
<!--  BEGIN ALFEvent -->
 
<!-- We declare all the possible event structures -->
 
<!-- MyALFEvent1Type is restricted to an event with the value "My Product Event Type A", and an object with the type value, "My Product Object Type A".
 
The event comes with MyEventDetails1Types event details and MyToolExtensionData1Type tool extension data. -->
 
<xs:complexType name="MyALFEvent1Type">
 
<xs:complexContent>
 
<xs:restriction base="ALFEventType">
 
<xs:sequence>
 
<xs:element name="Base" type="MyEventBase1Type"/>
 
<xs:element name="Detail" type="MyEventDetail1Type"/>
 
<xs:element name="Extension" type="MyEventExtension1Type"/>
 
</xs:sequence>
 
<xs:attribute name="version" type="xs:string" use="required"/>
 
</xs:restriction>
 
</xs:complexContent>
 
</xs:complexType>
 
<!-- MyALFEvent2Type is restricted to an event with the value "My Product Event Type B". 
 
It may contain object with type values of, "My Product Object Type A" or "My Product Object Type B".
 
The event comes with MyEventDetails2Types event details and MyToolExtensionData2Type tool extension data. -->
 
<xs:complexType name="MyALFEvent2Type">
 
<xs:complexContent>
 
<xs:restriction base="ALFEventType">
 
<xs:sequence>
 
<xs:element name="Base" type="MyEventBase2Type"/>
 
<xs:element name="Detail" type="MyEventDetail2Type"/>
 
<xs:element name="Extension" type="MyEventExtension2Type"/>
 
</xs:sequence>
 
<xs:attribute name="version" type="xs:string" use="required"/>
 
</xs:restriction>
 
</xs:complexContent>
 
</xs:complexType>
 
<!-- MyALFEvent3Type iis restricted to an event with the event value "My Product Event Type C". 
 
It may contain object with type values of, "My Product Object Type B",  "My Product Object Type C" or "My Product Object Type D"
 
The event comes with MyEventDetails2Types event details and MyToolExtensionData2Type tool extension data. -->
 
<xs:complexType name="MyALFEvent3Type">
 
<xs:complexContent>
 
<xs:restriction base="ALFEventType">
 
<xs:sequence>
 
<xs:element name="Base" type="MyEventBase3Type"/>
 
<xs:element name="Detail" type="MyEventDetail2Type"/>
 
<xs:element name="Extension" type="MyEventExtension2Type"/>
 
</xs:sequence>
 
<xs:attribute name="version" type="xs:string" use="required"/>
 
</xs:restriction>
 
</xs:complexContent>
 
</xs:complexType>
 
<xs:complexType name="MyALFEvent3ResponseType">
 
<xs:complexContent>
 
<xs:restriction base="ALFEventResponseType">
 
<xs:sequence>
 
<xs:element name="Base" type="EventBaseType"/>
 
</xs:sequence>
 
</xs:restriction>
 
</xs:complexContent>
 
</xs:complexType>
 
<!-- My Event 1 -->
 
<xs:element name="MyEventNotice1" type="MyALFEvent1Type"/>
 
<!-- My Event 2 -->
 
<xs:element name="MyEventNotice2" type="MyALFEvent2Type"/>
 
<!-- My EventWithReply 3 -->
 
<xs:element name="MyEventNotice3" type="MyALFEvent3Type"/>
 
<xs:element name="MyEventNotice3Response" type="MyALFEvent3ResponseType"/>
 
</xs:schema>
 
  
</pre>
+
  </xsd:schema>
 +
</wsdl:types>
  
== WSDL ==
+
<!-- Customized  EventNoice Message -->
MyALFEvents_001.wsdl
+
<!-- Note that the WSDL message is defined with a type.
 +
A type is used to be complient with WS-I RPC-Literal style.
 +
The type used must be derived by restriction from the base ALFEventType.
 +
In other words the type is actually an ALFEventType but its definition is more explicit.
 +
There should be a derived EventNotice Message defined for each derived ALFEventType declared.
 +
-->
 +
<wsdl:message name="MyEventNotice">
 +
<wsdl:documentation>Derived EventNotice message</wsdl:documentation>
 +
<wsdl:part name="EventNotice" type="evt:MyALFEventType"/>
 +
</wsdl:message>
  
<pre>
+
<!-- Customized  EventNoiceWithReply Message -->
<?xml version="1.0" encoding="UTF-8"?>
+
<!-- EventNoticeWithReply is a placeholder for a future feature.
<wsdl:definitions name="MyALFEnabledProduct"
+
The input message has the same characteristics as the EventNotice input message -->
  targetNamespace="http://www.eclipse.org/alf/XMLSchema/Events.wsdl"
+
<wsdl:message name="MyEventNoticeWithReply">
    xmlns:tns="http://www.eclipse.org/alf/XMLSchema/Events.wsdl"
+
<wsdl:part name="EventNoticeWithReply" type="evt:MyALFEventType" />
  xmlns:evt="http://www.eclipse.org/alf/XMLSchema/Events.xsd"
+
</wsdl:message>
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
+
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
+
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
+
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
+
    >
+
  <wsdl:documentation>
+
WARNING: PRELIMINARY VERSION DO NOT USE
+
 
+
  Derived from ALFEventManager WSDL
+
      Copyright Notice
+
      The material in this document is Copyright (c) Serena Software, Inc. and others, 2005, 2006
+
      Terms and Conditions:
+
      The Eclipse Foundation makes available all content in this document ("Content").
+
      Unless otherwise indicated below, the Content is provided to you under the terms
+
      and conditions of the Eclipse Public License Version 1.0 ("EPL").
+
      A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html.
+
      For purposes of the EPL, "Program" will mean the Content.
+
      If you did not receive this Content directly from the Eclipse Foundation, the
+
      Content is being redistributed by another party ("Redistributor") and different
+
      terms and conditions may apply to your use of any object code in the Content.
+
      Check the Redistributor's license that was provided with the Content.
+
      If you did not receive any such license, contact the Redistributor.
+
      Unless otherwise indicated below, the terms and conditions of the EPL still apply to the Content.
+
  </wsdl:documentation>
+
   
+
<!-- My ALF Enabled Product Event WSDL -->
+
<wsdl:types>
+
<xs:schema elementFormDefault="qualified" targetNamespace="http://www.eclipse.org/alf/XMLSchema/Events.xsd"
+
  xmlns:evt="http://www.eclipse.org/alf/XMLSchema/Events.xsd"
+
  xmlns="http://www.eclipse.org/alf/XMLSchema/Events.xsd">
+
<xs:include schemaLocation="MyALFEvents_001.xsd" />
+
+
</xs:schema>
+
</wsdl:types>
+
+
<!-- These Message definitions are the base messages for ALF events.
+
The "EventNotice" has the base event types so therefore it is valid for any derived event type to appear in this message
+
-->
+
<wsdl:message name="EventNotice">
+
<wsdl:part name="parameters" element="evt:EventNotice" />
+
</wsdl:message>
+
+
<wsdl:message name="EventNoticeResponse">
+
<wsdl:part name="parameters" element="evt:EventNoticeResponse" />
+
</wsdl:message>
+
+
<wsdl:message name="EventNoticeWithReply">
+
<wsdl:part name="parameters" element="evt:EventNoticeWithReply" />
+
</wsdl:message>
+
  
<wsdl:message name="EventNoticeWithReplyResponse">
+
<!-- Customized  EventNoiceWithReplyResponse Message -->
<wsdl:part name="parameters" element="evt:EventNoticeWithReplyResponse" />
+
<!-- EventNoticeWithReply is a placeholder for a future feature.  
</wsdl:message>
+
The response message may be specialized for the particular event using the same  
+
derived type techniques -->
<!-- These Messages definitions allow the creation of PortTypes that are specific to the derived Events -->
+
<wsdl:message name="MyEventNoticeWithReplyResponse">
<!-- Note that these messages don't conform to the Document Literal Wrapped convention
+
<wsdl:part name="EventNoticeWithReplyResponse"  
since these are really overloads and the element name "EventNotice" has the base type
+
type="evt:ALFEventWithReplyResponseType" />
and so is not useful for specifying the derived types. Consequently the Message element name
+
</wsdl:message>
cannot be the same as the opereration name for these derived types.
+
This is probably not important for ALF.
+
-->
+
<wsdl:message name="MyEventNotice1">
+
<wsdl:part name="parameters" element="evt:MyEventNotice1" />
+
</wsdl:message>
+
+
<wsdl:message name="MyEventNotice2">
+
<wsdl:part name="parameters" element="evt:MyEventNotice2" />
+
</wsdl:message>
+
+
<wsdl:message name="MyEventNotice3">
+
<wsdl:part name="parameters" element="evt:MyEventNotice3" />
+
</wsdl:message>
+
  
<wsdl:message name="MyEventNoticeResponse3">
+
<!-- Customized ALEEventManager PortType -->
<wsdl:part name="parameters" element="evt:MyEventNoticeResponse3" />
+
<!-- This is shown for completness. Currently it is not required to declare a
</wsdl:message>
+
derived ALFEventManager port. -->
 +
<wsdl:portType name="MyALFEventManager">
 +
<wsdl:operation name="EventNotice">
 +
<wsdl:input message="tns:MyEventNotice"/>
 +
<wsdl:output message="tns:EventNoticeResponse"/>
 +
</wsdl:operation>
 +
<wsdl:operation name="EventNoticeWithReply">
 +
<wsdl:input message="tns:MyEventNoticeWithReply"/>
 +
<wsdl:output message="tns:MyEventNoticeWithReplyResponse"/>
 +
</wsdl:operation>
 +
</wsdl:portType>
  
<!-- This is the base Event port defintion for the event manager -->
+
<!-- Customized ALFServiceFlow PortType -->
<wsdl:portType name="ALFEventManager">
+
<!-- This portType is used to define service flows that understand the  
<wsdl:operation name="EventNotice">
+
specific event or set of events.
<wsdl:input message="tns:EventNotice"/>
+
There should be a derived ALFServiceFlow portType defined for each derived
<wsdl:output message="tns:EventNoticeResponse"/>
+
EventNotice message declared. 
</wsdl:operation>
+
-->
<wsdl:operation name="EventNoticeWithReply">
+
<wsdl:portType name="MyALFServiceFlow">
<wsdl:input message="tns:EventNotice"/>
+
<wsdl:documentation>Derived ServiceFlow port</wsdl:documentation>
<wsdl:output message="tns:EventNoticeWithRepyResponse"/>
+
<wsdl:operation name="EventNotice">
</wsdl:operation>
+
<wsdl:input message="tns:MyEventNotice"/>
</wsdl:portType>
+
</wsdl:operation>
+
</wsdl:portType>
<!-- This is the base Event port defintion for any ServiceFlow-->
+
 
<wsdl:portType name="ALFServiceFlow">
+
<!-- Customized ServiceFlowWithReply PortType -->
<wsdl:operation name="EventNotice">
+
<!-- EventNoticeWithReply is a placeholder for a future feature.
<wsdl:input message="tns:EventNotice"/>
+
This portType is used to define service flows with reply that understand the  
</wsdl:operation>
+
specific event or set of events.
</wsdl:portType>
+
There should be a derived ALFServiceFlow portType defined for each derived
+
EventNotice message declared. 
<!-- This is the base Event port defintion for any ServiceFlow with reply-->
+
-->
<wsdl:portType name="ALFServiceFlowWithReply">
+
<wsdl:portType name="MyALFServiceFlowWithReply">
<wsdl:operation name="EventNotice">
+
<wsdl:operation name="EventNotice">
<wsdl:input message="tns:EventNotice"/>
+
<wsdl:input message="tns:MyEventNotice"/>
<wsdl:output message="tns:EventNoticeResponse"/>
+
<wsdl:output message="tns:MyEventNoticeWithReplyResponse"/>
</wsdl:operation>
+
</wsdl:operation>
</wsdl:portType>
+
</wsdl:portType>
+
 
<!-- This is the base Event port defintion for a ServiceFlow specifically designed to use the MyEventNotice1 type-->
+
<!-- Customized MyALFEventManagerSOAP Binding -->
<wsdl:portType name="ALFServiceFlowEventNotice1">
+
<!-- This is shown for completness. Currently it is not required to define a
<wsdl:operation name="EventNotice">
+
customized ALFEventManager Binding.
<wsdl:input message="tns:MyEventNotice1"/>
+
Note that the binding style is rpc and the body uses literal encoding
</wsdl:operation>
+
-->
</wsdl:portType>
+
<wsdl:binding name="MyALFEventManagerSOAP" type="tns:MyALFEventManager">
+
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
<!-- This is the base Event port defintion for a ServiceFlow specifically designed to use the MyEventNotice2 type-->
+
<wsdl:operation name="EventNotice">
<wsdl:portType name="ALFServiceFlowEventNotice2">
+
<soap:operation soapAction=""/>
<wsdl:operation name="EventNotice">
+
<wsdl:input>
<wsdl:input message="tns:MyEventNotice2"/>
+
<soap:body use="literal"
</wsdl:operation>
+
namespace="http://www.eclipse.org/alf/schema/EventBase/1"/>
</wsdl:portType>
+
</wsdl:input>
+
<wsdl:output>
<!-- This is the base Event port defintion for a ServiceFlow specifically designed to use the MyEventNotice3 type-->
+
<soap:body use="literal"
<wsdl:portType name="ALFServiceFlowWithReplyEventNotice3">
+
namespace="http://www.eclipse.org/alf/schema/EventBase/1"/>
<wsdl:operation name="EventNotice">
+
</wsdl:output>
<wsdl:input message="tns:MyEventNotice3"/>
+
</wsdl:operation>
<wsdl:output message="tns:MyEventNoticeResponse3"/>
+
<wsdl:operation name="EventNoticeWithReply">
</wsdl:operation>
+
<soap:operation soapAction=""/>
</wsdl:portType>
+
<wsdl:input>
+
<soap:body use="literal"
<!-- These are the base Event and Service Flow bindings -->
+
namespace="http://www.eclipse.org/alf/schema/EventBase/1"/>
<!-- They are orginally declared in the  ALFEventManager WSDL and repeated here for clarity -->
+
</wsdl:input>
<!-- This is the base EventManager binding -->
+
<wsdl:output>
<wsdl:binding name="ALFEventManagerSOAP" type="tns:ALFEventManager">
+
<soap:body use="literal"  
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
+
namespace="http://www.eclipse.org/alf/schema/EventBase/1"/>
<wsdl:operation name="EventNotice">
+
</wsdl:output>
<soap:operation soapAction="EventNotice"/>
+
</wsdl:operation>
 +
</wsdl:binding>
 +
 
 +
<!-- Customized MyALFServiceFlowWithReplySOAP Binding -->
 +
<!-- This is shown for completness. ServiceFlowWithReply is a future feature
 +
Note that the binding style is rpc and the body uses literal encoding -->
 +
<wsdl:binding name="MyALFServiceFlowWithReplySOAP" type="tns:MyALFServiceFlowWithReply">
 +
<wsdl:documentation>Derived ServiceFlowWithReply binding</wsdl:documentation>
 +
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
 +
<wsdl:operation name="EventNotice">
 +
<soap:operation soapAction=""/>
 
<wsdl:input>
 
<wsdl:input>
<soap:body use="literal"/>
+
<soap:body use="literal"
 +
namespace="http://www.eclipse.org/alf/schema/EventBase/1"/>
 
</wsdl:input>
 
</wsdl:input>
 
<wsdl:output>
 
<wsdl:output>
<soap:body use="literal"/>
+
<soap:body use="literal"
 +
namespace="http://www.eclipse.org/alf/schema/EventBase/1"/>
 
</wsdl:output>
 
</wsdl:output>
</wsdl:operation>
+
</wsdl:operation>
<wsdl:operation name="EventNoticeWithReply">
+
</wsdl:binding>
<soap:operation soapAction="EventNoticeWithReply"/>
+
 
<wsdl:input>
+
<!-- Customized ALFServiceFlowSOAP Binding -->
<soap:body use="literal"/>
+
<!-- This declaration provides the template for a binding compatible with the base ALFEvent
</wsdl:input>
+
but using the derived types
<wsdl:output>
+
Note that the binding style is rpc and the body uses literal encoding
<soap:body use="literal"/>
+
-->
</wsdl:output>
+
<wsdl:binding name="MyALFServiceFlowSOAP" type="tns:MyALFServiceFlow">
</wsdl:operation>
+
<wsdl:documentation>Derived ServiceFlow binding</wsdl:documentation>
</wsdl:binding>
+
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
+
<!-- This is the base ServiceFlow binding -->
+
<wsdl:binding name="ALFServiceFlowSOAP" type="tns:ALFServiceFlow">
+
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
+
 
<wsdl:operation name="EventNotice">
 
<wsdl:operation name="EventNotice">
<soap:operation soapAction="EventNotice"/>
+
<soap:operation soapAction=""/>
<wsdl:input>
+
<wsdl:input>
<soap:body use="literal"/>
+
<soap:body use="literal"  
</wsdl:input>
+
namespace="http://www.eclipse.org/alf/schema/EventBase/1"/>
</wsdl:operation>
+
</wsdl:input>
</wsdl:binding>
+
</wsdl:operation>
+
</wsdl:binding>
<!-- This is the base ServiceFlowWithResonse binding -->
+
 
<wsdl:binding name="ALFServiceFlowWithResponseSOAP" type="tns:ALFServiceFlowWithReply">
+
<!-- Customized ALFEventManager Service Example -->
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
+
<!-- This is shown for completness. ServiceFlowWithReply is a future feature
<wsdl:operation name="EventNotice">
+
Currently it is not required to define an example customized
<soap:operation soapAction="EventNotice"/>
+
ALFEventManager Service.  
<wsdl:input>
+
-->
<soap:body use="literal"/>
+
<wsdl:service name="MyALFEventManager">
</wsdl:input>
+
<wsdl:documentation>Example Derived EventManager service
<wsdl:output>
+
</wsdl:documentation>
<soap:body use="literal"/>
+
<wsdl:port binding="tns:MyALFEventManagerSOAP" name="MyALFEventManagerSOAP">
</wsdl:output>
+
<soap:address
</wsdl:operation>
+
location="http://localhost:8080/ALFEventManager/services/ALFEventManagerSOAP"/>
</wsdl:binding>
+
</wsdl:port>
+
</wsdl:service>
<!-- These are the Event and Service Flow bindings for specific events-->
+
 
<wsdl:binding name="ALFServiceFlow1SOAP" type="tns:ALFServiceFlowEventNotice1">
+
<!-- Customized ALFServiceFlow Service Example -->
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
+
<!--  This declaration provides the template service compatible with
<wsdl:operation name="EventNotice">
+
the base ALFEvent
<soap:operation soapAction="EventNotice"/>
+
but using the derived types. It is not intended to declare an actual
<wsdl:input>
+
service but to define a template
<soap:body use="literal"/>
+
that can be imported by a web service toos to create a web service
</wsdl:input>
+
interface that expects the custom data
</wsdl:operation>
+
as defined by the various supporting custom defintions. Since this
</wsdl:binding>
+
service definition uses a types defined
+
by restricted derivation, a base service flow may also be used to
<wsdl:binding name="ALFServiceFlow2SOAP" type="tns:ALFServiceFlowEventNotice2">
+
handle the corresponding event.
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
+
This allows a tools events be handled three differnt ways -
<wsdl:operation name="EventNotice">
+
a base event
<soap:operation soapAction="EventNotice"/>
+
a vocabualry event should it support one or
<wsdl:input>
+
a custom event
<soap:body use="literal"/>
+
-->
</wsdl:input>
+
<wsdl:service name="MyALFServiceFlow">
</wsdl:operation>
+
<wsdl:documentation>Example Derived ServiceFlow service</wsdl:documentation>
</wsdl:binding>
+
<wsdl:port binding="tns:MyALFServiceFlowSOAP" name="MyALFServiceFlowSOAP">
+
<soap:address  
<wsdl:binding name="ALFServiceFlowWithReply3SOAP" type="tns:ALFServiceFlowWithReplyEventNotice3">
+
location="http://localhost:8080/ALFServiceFlowEngine/services/MyALFServiceFlowSOAP"/>
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
+
</wsdl:port>
<wsdl:operation name="EventNotice">
+
</wsdl:service>
<soap:operation soapAction="EventNotice"/>
+
<wsdl:input>
+
<soap:body use="literal"/>
+
</wsdl:input>
+
<wsdl:output>
+
<soap:body use="literal"/>
+
</wsdl:output>
+
</wsdl:operation>
+
</wsdl:binding>
+
+
<!-- Example service declarations -->
+
<wsdl:service name="ALFEventManager">
+
<wsdl:port binding="tns:ALFEventManagerSOAP" name="ALFEventManagerSOAP">
+
<soap:address location="http://localhost:8080/alfeventmgr/services/ALFEventManager"/>
+
</wsdl:port>
+
</wsdl:service>
+
  
<wsdl:service name="ALFServiceFlow1">
 
<wsdl:port binding="tns:ALFServiceFlow1SOAP" name="ALFServiceFlow1SOAP">
 
<soap:address location="http://localhost:8080/BPELengine/services/ALFServiceFlow1"/>
 
</wsdl:port>
 
</wsdl:service>
 
 
<wsdl:service name="ALFServiceFlow2">
 
<wsdl:port binding="tns:ALFServiceFlow2SOAP" name="ALFServiceFlow2SOAP">
 
<soap:address location="http://localhost:8080/BPELengine/services/ALFServiceFlow2"/>
 
</wsdl:port>
 
</wsdl:service>
 
 
<wsdl:service name="ALFServiceFlowWithReply3">
 
<wsdl:port binding="tns:ALFServiceFlowWithReply3SOAP" name="ALFServiceFlowWithReply3SOAP">
 
<soap:address location="http://localhost:8080/BPELengine/services/ALFServiceFlowWithReply3"/>
 
</wsdl:port>
 
</wsdl:service>
 
 
</wsdl:definitions>
 
</wsdl:definitions>
  
</pre>
+
</pre></code>

Latest revision as of 23:48, 26 June 2007

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 is 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.

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions 
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
name="MyALFEvents" 
targetNamespace="http://www.eclipse.org/alf/schema/EventBase/1"
xmlns:tns="http://www.eclipse.org/alf/schema/EventBase/1" 
xmlns:evt="http://www.eclipse.org/alf/schema/EventBase/1"
xmlns:ext="http://www.example.org/MyEventExtensions" 
xmlns:evc="http://www.eclipse.org/ALF/ExampleVocabulary"
>
    
  <wsdl:documentation>
	WARNING: PRELIMINARY VERSION SUBJECT TO CHANGE
  
      Copyright Notice
      The material in this document is Copyright (c) Serena Software, Inc. and others, 2005, 2006, 2007
      Terms and Conditions:
      The Eclipse Foundation makes available all content in this document ("Content").
      Unless otherwise indicated below, the Content is provided to you under the terms
      and conditions of the Eclipse Public License Version 1.0 ("EPL").
      A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html.
      For purposes of the EPL, "Program" will mean the Content.
      If you did not receive this Content directly from the Eclipse Foundation, the
      Content is being redistributed by another party ("Redistributor") and different
      terms and conditions may apply to your use of any object code in the Content.
      Check the Redistributor's license that was provided with the Content.
      If you did not receive any such license, contact the Redistributor.
      Unless otherwise indicated below, the terms and conditions of the EPL still apply to the Content.
  </wsdl:documentation>
    
  <!-- ALF EventManager WSDL -->  
<wsdl:import location="ALFEventManager_1.wsdl" 
	namespace="http://www.eclipse.org/alf/schema/EventBase/1">
</wsdl:import>
  
<wsdl:types>

	<!-- The various schemas are defined below.
	Generally, it is prefered to import these schemas
	This example is defines them in-line for simplicity. 
	-->

	<!-- Example Vocabulary Extension
	This schema is a simple example of a Vocabulary extension.
	Generally, extension schemas such as this would be imported.
	This example is defined in-line for simplicity. 
	-->
	<xsd:schema xmlns="http://www.eclipse.org/ALF/ExampleVocabulary" 
	elementFormDefault="qualified" 
	targetNamespace="http://www.eclipse.org/ALF/ExampleVocabulary">

	<xs:complexType name="ExampleVocabularyExtension">
		<xs:annotation>
			<xs:documentation>
				Vocabulary Event Extension
			</xs:documentation>
		</xs:annotation>
		<xs:sequence>
			<xs:element name="ExampleVocabularyData" type="xs:string"/>
		</xs:sequence>
		<xs:anyAttribute/>
	</xs:complexType>

	</xsd:schema>

	<!-- Example Custom Extension
	This schema is an simple example of a Tool specific custom extension.
	Generally, extension schemas such as this would be imported.
	This example is defined in-line for simplicity. 
	-->
	<xsd:schema xmlns="http://www.example.org/MyEventExtensions" 
	elementFormDefault="qualified" 
	targetNamespace="http://www.example.org/MyEventExtensions">

	<xs:complexType name="MyCustomExtension">
		<xs:annotation>
			<xs:documentation>
				Custom Extension
			</xs:documentation>
		</xs:annotation>
		<xs:sequence>
			<xs:element name="MyData" type="xs:string"/>
		</xs:sequence>
		<xs:anyAttribute/>
	</xs:complexType>

	</xsd:schema>

	<!-- The Tool's ALF Events.
	This schema shows some examples of how to declare ALF events by deriving schema types
	from the base ALF Event Schema
	Generally, it is prefered to import the schema.
	This example is defined in-line for simplicity. 

	-->
	<xsd:schema xmlns="http://www.eclipse.org/alf/schema/EventBase/1" 
	elementFormDefault="qualified" 
	targetNamespace="http://www.eclipse.org/alf/schema/EventBase/1">
	
	<xsd:include schemaLocation="ALFEventBase_1.xsd"/>
		
	<xs:import namespace="http://www.eclipse.org/ALF/ExampleVocabulary" />
	<xs:import namespace="http://www.example.org/MyEventExtensions" />
		
	<!-- Derived Basic Event -->
	<!-- This event declaration restrict the possible values for 
	EventType, Object and Source by declaring derived types for those elements.
	See MyEventType1Type, MyObjectType1Type and MySourceType.
	There are various options for declaring these derived types depending on 
	the valid combinations of EventType and Object values
	If any EventType value can be combined with any Object value then all possible 
	values can be declared in a single type.
	If only one or some EventType values can be combined with one or some 
	Object value the separate types can be declared for the valid combinations
	The Source is generally constant for any particular product. -->
	<!-- This example, MyBasicEvent1Type, is restricted to an event with the value 
	"My Product Event Type A", and an object with the type value, 
	"My Product Object Type A" -->
	<xs:complexType name="MyEventBase1Type">
		<xs:annotation>
			<xs:documentation>
      </xs:documentation>
		</xs:annotation>
		<xs:complexContent>
			<xs:restriction base="EventBaseType">
				<xs:sequence>
					<xs:element name="EventId" type="EventIdType"/>
					<xs:element name="Timestamp" type="TimestampType"/>
					<xs:element name="EventType" type="MyEventType1Type"/>
					<xs:element name="ObjectType" type="MyObjectType1Type"/>
					<xs:element name="ObjectId" type="ObjectIdType"/>
					<xs:element name="Source" type="MySourceType"/>
					<xs:element name="User" type="CredentialsType"/>
					<xs:element name="EventControl" type="EmBaseType"/>
					<xs:element minOccurs="0" name="BaseExtension" 
						type="BaseExtensionType"/>
				</xs:sequence>
				<xs:anyAttribute/>
			</xs:restriction>
		</xs:complexContent>
	</xs:complexType>
	
	<!-- Derived subtypes -->
	<!-- In order to restrict the EventType, ObjectType and Source we need to 
	declare one or more custom restricted types.
	Depending how the allowed values for EventType, Object and Source combine 
	we can declare either one type for each element
	that restricts to all possible values, a number of single value types or 
	some combination 
	-->

	<!-- Derived EventTypeType -->
	<!-- This example restricts to a single possible value -->
	<xs:simpleType name="MyEventType1Type">
		<xs:restriction base="EventTypeType">
			<xs:enumeration value="My Product Event Type A"/>
		</xs:restriction>
	</xs:simpleType>
	
	<!-- Derived ObjectTypeType -->
	<!-- This example restricts to a single possible value -->
	<xs:simpleType name="MyObjectType1Type">
		<xs:restriction base="ObjectTypeType">
			<xs:enumeration value="MyObjectType1Name"/>
		</xs:restriction>
	</xs:simpleType>
	
	<!-- Derived SourceType -->
	<!-- The SourceType has its own sub-types, ProductType and ProductVersionType, 
	which must also be derived. 
	Typically a Product will only have a single value whereas ProductVersion may 
	have multiple.
	ProductVersion may combine with other derived types to allow version specific 
	events to be declared
	-->
	<xs:complexType name="MySourceType">
		<xs:complexContent>
			<xs:restriction base="SourceType">
				<xs:sequence>
					<xs:element name="Product" type="MyProductType"/>
					<xs:element name="ProductVersion" 
						type="MyProductVersionType"/>
					<xs:element name="ProductInstance" 
						type="ProductInstanceType"/>
					<xs:element name="ProductCallbackURI" 
						type="ProductCallbackURIType" 
						nillable="true" minOccurs="0"/>
				</xs:sequence>
			</xs:restriction>
		</xs:complexContent>
	</xs:complexType>
	
	<!-- Derived ProductType -->
	<!-- This example restricts to a single value -->
	<xs:simpleType name="MyProductType">
		<xs:restriction base="ProductType">
			<xs:enumeration value="My Product Name"/>
		</xs:restriction>
	</xs:simpleType>
	
	<!-- Derived ProductVersionType -->
	<!-- This example restricts to a single value -->
	<xs:simpleType name="MyProductVersionType">
		<xs:restriction base="ProductVersionType">
			<xs:enumeration value="3.0"/>
		</xs:restriction>
	</xs:simpleType>
	
	<!-- Derived ALFEventType -->
	<!-- The actual event message is always an ALFEvent type.  
	The derived type just restricts the possible values and declares 
	what will be found in the extension areas.
	A tool that defines a CustomExtension data may define different content 
	for the each event-object combination if it needs to.
	For Vocabulary events the content of the Vocabulary extension is defined by 
	the vocabulary schema which a tool must follow.
	Vocabulary schemas provide for some extensibility and a tool may declare is 
	own specializations for that.
	The same techniques are used but the extendable types are specialized to the 
	particular vocabulary
	-->
	<xs:complexType name="MyALFEventType">
		<xs:sequence>
			<xs:element name="Base" type="MyEventBase1Type"/>
			<xs:element minOccurs="0" name="Detail" 
				type="evc:ExampleVocabularyExtension"/>
			<xs:element minOccurs="0" name="Extension" 
				type="ext:MyCustomExtension"/>
			<xs:any maxOccurs="unbounded" minOccurs="0" namespace="##other" 
				processContents="lax"/>
		</xs:sequence>
		<xs:attribute default="1.0" name="version" type="ALFSchemaVersionType"/>
	</xs:complexType>

   </xsd:schema>
</wsdl:types>

<!-- Customized  EventNoice Message -->
<!-- Note that the WSDL message is defined with a type.
A type is used to be complient with WS-I RPC-Literal style.
The type used must be derived by restriction from the base ALFEventType.
In other words the type is actually an ALFEventType but its definition is more explicit.
There should be a derived EventNotice Message defined for each derived ALFEventType declared.
 -->
<wsdl:message name="MyEventNotice">
	<wsdl:documentation>Derived EventNotice message</wsdl:documentation>
	<wsdl:part name="EventNotice" type="evt:MyALFEventType"/>
</wsdl:message>

<!-- Customized  EventNoiceWithReply Message -->
<!-- EventNoticeWithReply is a placeholder for a future feature.
The input message has the same characteristics as the EventNotice input message -->
<wsdl:message name="MyEventNoticeWithReply">
	<wsdl:part name="EventNoticeWithReply" type="evt:MyALFEventType" />
</wsdl:message>

<!-- Customized  EventNoiceWithReplyResponse Message -->
<!-- EventNoticeWithReply is a placeholder for a future feature. 
The response message may be specialized for the particular event using the same 
derived type techniques -->
<wsdl:message name="MyEventNoticeWithReplyResponse">
	<wsdl:part name="EventNoticeWithReplyResponse" 
		type="evt:ALFEventWithReplyResponseType" />
</wsdl:message>

<!-- Customized ALEEventManager PortType -->
<!-- This is shown for completness. Currently it is not required to declare a 
derived ALFEventManager port. -->
<wsdl:portType name="MyALFEventManager">
	<wsdl:operation name="EventNotice">
		<wsdl:input message="tns:MyEventNotice"/>
		<wsdl:output message="tns:EventNoticeResponse"/>
	</wsdl:operation>
	<wsdl:operation name="EventNoticeWithReply">
		<wsdl:input message="tns:MyEventNoticeWithReply"/>
		<wsdl:output message="tns:MyEventNoticeWithReplyResponse"/>
	</wsdl:operation>
</wsdl:portType>

<!-- Customized ALFServiceFlow PortType -->
<!-- This portType is used to define service flows that understand the 
specific event or set of events.
There should be a derived ALFServiceFlow portType defined for each derived 
EventNotice message declared.  
-->
<wsdl:portType name="MyALFServiceFlow">
	<wsdl:documentation>Derived ServiceFlow port</wsdl:documentation>
	<wsdl:operation name="EventNotice">
		<wsdl:input message="tns:MyEventNotice"/>
	</wsdl:operation>
</wsdl:portType>

<!-- Customized ServiceFlowWithReply PortType -->
<!-- EventNoticeWithReply is a placeholder for a future feature. 
This portType is used to define service flows with reply that understand the 
specific event or set of events.
There should be a derived ALFServiceFlow portType defined for each derived 
EventNotice message declared.  
-->
<wsdl:portType name="MyALFServiceFlowWithReply">
	<wsdl:operation name="EventNotice">
		<wsdl:input message="tns:MyEventNotice"/>
		<wsdl:output message="tns:MyEventNoticeWithReplyResponse"/>
	</wsdl:operation>
</wsdl:portType>

<!-- Customized MyALFEventManagerSOAP Binding -->
<!-- This is shown for completness. Currently it is not required to define a 
customized ALFEventManager Binding. 
Note that the binding style is rpc and the body uses literal encoding 
-->
<wsdl:binding name="MyALFEventManagerSOAP" type="tns:MyALFEventManager">
	<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
	<wsdl:operation name="EventNotice">
	<soap:operation soapAction=""/>
		<wsdl:input>
			<soap:body use="literal" 
				namespace="http://www.eclipse.org/alf/schema/EventBase/1"/>
		</wsdl:input>
		<wsdl:output>
			<soap:body use="literal" 
				namespace="http://www.eclipse.org/alf/schema/EventBase/1"/>
		</wsdl:output>
	</wsdl:operation>
	<wsdl:operation name="EventNoticeWithReply">
	<soap:operation soapAction=""/>
		<wsdl:input>
			<soap:body use="literal" 
				namespace="http://www.eclipse.org/alf/schema/EventBase/1"/>
		</wsdl:input>
		<wsdl:output>
			<soap:body use="literal" 
				namespace="http://www.eclipse.org/alf/schema/EventBase/1"/>
		</wsdl:output>
	</wsdl:operation>
</wsdl:binding>

<!-- Customized MyALFServiceFlowWithReplySOAP Binding -->
<!-- This is shown for completness. ServiceFlowWithReply is a future feature 
Note that the binding style is rpc and the body uses literal encoding -->
<wsdl:binding name="MyALFServiceFlowWithReplySOAP" type="tns:MyALFServiceFlowWithReply">
	<wsdl:documentation>Derived ServiceFlowWithReply binding</wsdl:documentation>
	<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
	<wsdl:operation name="EventNotice">
		<soap:operation soapAction=""/>
			<wsdl:input>
				<soap:body use="literal" 
					namespace="http://www.eclipse.org/alf/schema/EventBase/1"/>
			</wsdl:input>
			<wsdl:output>
				<soap:body use="literal" 
					namespace="http://www.eclipse.org/alf/schema/EventBase/1"/>
			</wsdl:output>
	</wsdl:operation>
</wsdl:binding>

<!-- Customized ALFServiceFlowSOAP Binding -->
<!--  This declaration provides the template for a binding compatible with the base ALFEvent 
but using the derived types
Note that the binding style is rpc and the body uses literal encoding 
-->
<wsdl:binding name="MyALFServiceFlowSOAP" type="tns:MyALFServiceFlow">
	<wsdl:documentation>Derived ServiceFlow binding</wsdl:documentation>
	<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/>
		<wsdl:operation name="EventNotice">
		<soap:operation soapAction=""/>
		<wsdl:input>
			<soap:body use="literal" 
			namespace="http://www.eclipse.org/alf/schema/EventBase/1"/>
		</wsdl:input>
	</wsdl:operation>
</wsdl:binding>

<!-- Customized ALFEventManager Service Example -->
<!-- This is shown for completness. ServiceFlowWithReply is a future feature 
Currently it is not required to define an example customized 
ALFEventManager Service. 
-->
<wsdl:service name="MyALFEventManager">
	<wsdl:documentation>Example Derived EventManager service
	</wsdl:documentation>
	<wsdl:port binding="tns:MyALFEventManagerSOAP" name="MyALFEventManagerSOAP">
		<soap:address 
location="http://localhost:8080/ALFEventManager/services/ALFEventManagerSOAP"/>
	</wsdl:port>
</wsdl:service>

<!-- Customized ALFServiceFlow Service Example -->
<!--  This declaration provides the template service compatible with 
the base ALFEvent
but using the derived types. It is not intended to declare an actual 
service but to define a template 
that can be imported by a web service toos to create a web service 
interface that expects the custom data 
as defined by the various supporting custom defintions.  Since this 
service definition uses a types defined 
by restricted derivation, a base service flow may also be used to 
handle the corresponding event.  
This allows a tools events be handled three differnt ways - 
	a base event
	a vocabualry event should it support one or 
	a custom event
 -->
<wsdl:service name="MyALFServiceFlow">
	<wsdl:documentation>Example Derived ServiceFlow service</wsdl:documentation>
	<wsdl:port binding="tns:MyALFServiceFlowSOAP" name="MyALFServiceFlowSOAP">
		<soap:address 
location="http://localhost:8080/ALFServiceFlowEngine/services/MyALFServiceFlowSOAP"/>
	</wsdl:port>
</wsdl:service>

</wsdl:definitions>

Back to the top