https://wiki.eclipse.org/api.php?action=feedcontributions&user=Alf+tbuss.yahoo.com&feedformat=atomEclipsepedia - User contributions [en]2024-03-28T07:50:49ZUser contributionsMediaWiki 1.26.4https://wiki.eclipse.org/index.php?title=ALF/Vocabularies/Event_Declaration_Schema&diff=13482ALF/Vocabularies/Event Declaration Schema2006-10-10T18:33:11Z<p>Alf tbuss.yahoo.com: /* WSDL */</p>
<hr />
<div>__TOC__<br />
[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
== Event Declaration ==<br />
<br />
There are a number of goals we wish to achieve.<br />
<br />
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<br />
<br />
2. We need to be able to enumerate the possible events as explict combinations for inclusion in the event dispatch map.<br />
<br />
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.<br />
<br />
Attached are some experimental schemas and WSDL that illustrate how a tool might declare its ALF events.<br />
<br />
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.<br />
<br />
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]]<br />
<br />
The following two files are for a fictitious tool that needs to declare events <br />
<br />
MyALFEvents_001.xsd<br />
MyALFEvents_001.wsdl<br />
<br />
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.<br />
<br />
The WSDL uses the derived types to redeclare the ALFEventManager WSDL in terms of the more restrictive and details tool specific types.<br />
<br />
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.<br />
<br />
<br />
Problems with the WSDL - goal #1<br />
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.<br />
<br />
The runtime consequences of this depend on what the tool acutally does when it sends its event message to the EventManager.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Problems with the valid combinations - goal #2<br />
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.<br />
<br />
Problems with enumerating the events - goal #3<br />
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.<br />
<br />
== Schema ==<br />
MyALFEvents_001.xsd<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<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"><br />
<xs:include schemaLocation="ALFEventBase_001.xsd"/><br />
<xs:annotation><br />
<xs:documentation><br />
WARNING: PRELIMINARY VERSION DO NOT USE<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:annotation><br />
<xs:documentation><br />
Copyright Notice<br />
The material in this document is Copyright (c) Serena Software, Inc. and others, 2005<br />
Terms and Conditions:<br />
The Eclipse Foundation makes available all content in this document ("Content").<br />
Unless otherwise indicated below, the Content is provided to you under the terms<br />
and conditions of the Eclipse Public License Version 1.0 ("EPL").<br />
A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html.<br />
For purposes of the EPL, "Program" will mean the Content.<br />
If you did not receive this Content directly from the Eclipse Foundation, the<br />
Content is being redistributed by another party ("Redistributor") and different<br />
terms and conditions may apply to your use of any object code in the Content.<br />
Check the Redistributor's license that was provided with the Content.<br />
If you did not receive any such license, contact the Redistributor.<br />
Unless otherwise indicated below, the terms and conditions of the EPL still apply to the Content.<br />
</xs:documentation><br />
</xs:annotation><br />
<!-- Begin BasicEventTypes --><br />
<!-- These event declarations restrict the possible values for EventType, Object and Source.<br />
There are various options for declaring these derivied types depending on the valid combinations of EventType<br />
and Object values.<br />
If any EventType value can be combined with any Object value then all possible values can be declared in a single<br />
type.<br />
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<br />
Parts of Source is generally constant for any particular product. --><br />
<!-- 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" --><br />
<xs:complexType name="MyEventBase1Type"><br />
<xs:annotation><br />
<xs:documentation><br />
</xs:documentation><br />
</xs:annotation><br />
<xs:complexContent><br />
<xs:restriction base="EventBaseType"><br />
<xs:sequence><br />
<xs:element name="EventID" type="EventIDType"/><br />
<xs:element name="Timestamp" type="TimestampType"/><br />
<xs:element name="EventType" type="MyEventType1Type"/><br />
<xs:element name="Object" type="MyObjectData1Type"/><br />
<xs:element name="Source" type="MySourceType"/><br />
<xs:element name="PredecedingEvent" type="EventIDType" nillable="true"/><br />
<xs:element name="ApplicationName" type="ApplicationNameType" nillable="true"/><br />
<xs:element name="Environment" type="EnvironmentType" nillable="true"/><br />
<xs:element name="User" type="UserType"/><br />
</xs:sequence><br />
<xs:attribute name="alfEventVersion" type="xs:string" use="required"/><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<!-- MyBasicEvent2Type is restricted to an event with the event value "My Product Event Type B". <br />
It may contain object with type values of, "My Product Object Type B" or "My Product Object Type C"--><br />
<xs:complexType name="MyEventBase2Type"><br />
<xs:annotation><br />
<xs:documentation><br />
</xs:documentation><br />
</xs:annotation><br />
<xs:complexContent><br />
<xs:restriction base="EventBaseType"><br />
<xs:sequence><br />
<xs:element name="EventID" type="EventIDType"/><br />
<xs:element name="Timestamp" type="TimestampType"/><br />
<xs:element name="EventType" type="MyEventType2Type"/><br />
<xs:element name="Object" type="MyObjectData2Type"/><br />
<xs:element name="Source" type="MySourceType"/><br />
<xs:element name="PredecedingEvent" type="EventIDType" nillable="true"/><br />
<xs:element name="ApplicationName" type="ApplicationNameType" nillable="true"/><br />
<xs:element name="Environment" type="EnvironmentType" nillable="true"/><br />
<xs:element name="User" type="UserType"/><br />
</xs:sequence><br />
<xs:attribute name="alfEventVersion" type="xs:string" use="required"/><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<!-- MyBasicEvent3Type is restricted to an event with the event value "My Product Event Type C". <br />
It may contain object with type values of, "My Product Object Type B", "My Product Object Type C" or "My Product Object Type D"--><br />
<xs:complexType name="MyEventBase3Type"><br />
<xs:annotation><br />
<xs:documentation><br />
</xs:documentation><br />
</xs:annotation><br />
<xs:complexContent><br />
<xs:restriction base="EventBaseType"><br />
<xs:sequence><br />
<xs:element name="EventID" type="EventIDType"/><br />
<xs:element name="Timestamp" type="TimestampType"/><br />
<xs:element name="EventType" type="MyEventType3Type"/><br />
<xs:element name="Object" type="MyObjectData3Type"/><br />
<xs:element name="Source" type="MySourceType"/><br />
<xs:element name="PredecedingEvent" type="EventIDType" nillable="true"/><br />
<xs:element name="ApplicationName" type="ApplicationNameType" nillable="true"/><br />
<xs:element name="Environment" type="EnvironmentType" nillable="true"/><br />
<xs:element name="User" type="UserType"/><br />
</xs:sequence><br />
<xs:attribute name="alfEventVersion" type="xs:string" use="required"/><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<!-- In order to restrict the EventType, Object and Source values we need to declare custom restricted types.<br />
Depending how the allowed values for EventType, Object and Source combine we can declare either one type<br />
that restricts to all possible values or a number of single value types or some combination --><br />
<!-- These EventType variants each have a single possible value --><br />
<xs:simpleType name="MyEventType1Type"><br />
<xs:restriction base="EventTypeType"><br />
<xs:enumeration value="My Product Event Type A"/><br />
</xs:restriction><br />
</xs:simpleType><br />
<xs:simpleType name="MyEventType2Type"><br />
<xs:restriction base="EventTypeType"><br />
<xs:enumeration value="My Product Event Type B"/><br />
</xs:restriction><br />
</xs:simpleType><br />
<xs:simpleType name="MyEventType3Type"><br />
<xs:restriction base="EventTypeType"><br />
<xs:enumeration value="My Product Event Type C"/><br />
</xs:restriction><br />
</xs:simpleType><br />
<!-- ============= Object that triggered the event ============= --><br />
<!-- MyObjectData1Type is restricted to one possible value --><br />
<!--The ObjectData type derivations illustrate how to combine a number of possible values that may be used interchangeably.<br />
This can be useful shorthand to compact the event definitions by grouping set of values into a single definition.<br />
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.<br />
--><br />
<xs:complexType name="MyObjectData1Type"><br />
<xs:annotation><br />
<xs:documentation><br />
</xs:documentation><br />
</xs:annotation><br />
<xs:complexContent><br />
<xs:restriction base="ObjectDataType"><br />
<xs:sequence><br />
<xs:element name="ObjectType" type="MyObjectType1Type"/><br />
<xs:element name="ObjectId" type="ObjectIdType"/><br />
</xs:sequence><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<xs:simpleType name="MyObjectType1Type"><br />
<xs:annotation><br />
<xs:documentation><br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="ObjectTypeType"><br />
<xs:enumeration value="My Product Object Type A"/><br />
</xs:restriction><br />
</xs:simpleType><br />
<!-- MyObjectData2Type is restricted to two possible values --><br />
<xs:complexType name="MyObjectData2Type"><br />
<xs:annotation><br />
<xs:documentation><br />
</xs:documentation><br />
</xs:annotation><br />
<xs:complexContent><br />
<xs:restriction base="ObjectDataType"><br />
<xs:sequence><br />
<xs:element name="ObjectType" type="MyObjectType2Type"/><br />
<xs:element name="ObjectId" type="ObjectIdType"/><br />
</xs:sequence><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<xs:simpleType name="MyObjectType2Type"><br />
<xs:annotation><br />
<xs:documentation><br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="ObjectTypeType"><br />
<xs:enumeration value="My Product Object Type B"/><br />
<xs:enumeration value="My Product Object Type C"/><br />
</xs:restriction><br />
</xs:simpleType><br />
<!-- MyObjectData3Type is restricted to three possible values --><br />
<xs:complexType name="MyObjectData3Type"><br />
<xs:annotation><br />
<xs:documentation><br />
</xs:documentation><br />
</xs:annotation><br />
<xs:complexContent><br />
<xs:restriction base="ObjectDataType"><br />
<xs:sequence><br />
<xs:element name="ObjectType" type="MyObjectType3Type"/><br />
<xs:element name="ObjectId" type="ObjectIdType"/><br />
</xs:sequence><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<xs:simpleType name="MyObjectType3Type"><br />
<xs:annotation><br />
<xs:documentation><br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="ObjectTypeType"><br />
<xs:enumeration value="My Product Object Type B"/><br />
<xs:enumeration value="My Product Object Type C"/><br />
<xs:enumeration value="My Product Object Type D"/><br />
</xs:restriction><br />
</xs:simpleType><br />
<!-- ============= The source (i.e, tool or product) that emitted the event ============= --><br />
<!-- The values for Product and ProductVersion are constant for all events from a particular product installation -<br />
ProductInstance and ProductCallbackURI are determined at install time an will not have declared restricted values --><br />
<xs:complexType name="MySourceType"><br />
<xs:complexContent><br />
<xs:restriction base="SourceType"><br />
<xs:sequence><br />
<xs:element name="Product" type="MyProductType"/><br />
<xs:element name="ProductVersion" type="MyProductVersionType"/><br />
<xs:element name="ProductInstance" type="ProductInstanceType"/><br />
<xs:element name="ProductCallbackURI" type="ProductCallbackURIType" nillable="true" minOccurs="0"/><br />
</xs:sequence><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<xs:simpleType name="MyProductType"><br />
<xs:restriction base="ProductType"><br />
<xs:enumeration value="My Product Name"/><br />
</xs:restriction><br />
</xs:simpleType><br />
<xs:simpleType name="MyProductVersionType"><br />
<xs:restriction base="ProductVersionType"><br />
<xs:enumeration value="My Product Version"/><br />
</xs:restriction><br />
</xs:simpleType><br />
<!-- Each event type or object type could be associated with different event detail data.<br />
We need to declare the possible EventDetail types--><br />
<xs:complexType name="MyEventDetail1Type"><br />
<xs:complexContent><br />
<xs:restriction base="EventDetailType"><br />
<xs:sequence><br />
<xs:any/><br />
</xs:sequence><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<xs:complexType name="MyEventDetail2Type"><br />
<xs:complexContent><br />
<xs:restriction base="EventDetailType"><br />
<xs:sequence><br />
<xs:any/><br />
</xs:sequence><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<xs:complexType name="MyEventDetail3Type"><br />
<xs:complexContent><br />
<xs:restriction base="EventDetailType"><br />
<xs:sequence><br />
<xs:element name="MyEventDetailDate1" type="xs:string"/><br />
</xs:sequence><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<xs:complexType name="MyEventDetail4Type"><br />
<xs:complexContent><br />
<xs:restriction base="EventExtensionType"><br />
<xs:sequence><br />
<xs:choice><br />
<xs:element name="MyEventDetail1" type="MyEventDetail1Type"/><br />
<xs:element name="MyEventDetail2" type="MyEventDetail2Type"/><br />
<xs:element name="MyEventDetail3" type="MyEventDetail3Type"/><br />
</xs:choice><br />
</xs:sequence><br />
<xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<!-- Each event type or object type could be associated with different ToolExtension data.<br />
We need to declare the possible ToolExtension types--><br />
<xs:complexType name="MyEventExtension1Type"><br />
<xs:complexContent><br />
<xs:restriction base="EventExtensionType"><br />
<xs:sequence><br />
<xs:any/><br />
</xs:sequence><br />
<xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<xs:complexType name="MyEventExtension2Type"><br />
<xs:complexContent><br />
<xs:restriction base="EventExtensionType"><br />
<xs:sequence><br />
<xs:any/><br />
</xs:sequence><br />
<xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<!-- End BasicEventTypes --><br />
<!-- BEGIN ALFEvent --><br />
<!-- We declare all the possible event structures --><br />
<!-- 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".<br />
The event comes with MyEventDetails1Types event details and MyToolExtensionData1Type tool extension data. --><br />
<xs:complexType name="MyALFEvent1Type"><br />
<xs:complexContent><br />
<xs:restriction base="ALFEventType"><br />
<xs:sequence><br />
<xs:element name="Base" type="MyEventBase1Type"/><br />
<xs:element name="Detail" type="MyEventDetail1Type"/><br />
<xs:element name="Extension" type="MyEventExtension1Type"/><br />
</xs:sequence><br />
<xs:attribute name="version" type="xs:string" use="required"/><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<!-- MyALFEvent2Type is restricted to an event with the value "My Product Event Type B". <br />
It may contain object with type values of, "My Product Object Type A" or "My Product Object Type B".<br />
The event comes with MyEventDetails2Types event details and MyToolExtensionData2Type tool extension data. --><br />
<xs:complexType name="MyALFEvent2Type"><br />
<xs:complexContent><br />
<xs:restriction base="ALFEventType"><br />
<xs:sequence><br />
<xs:element name="Base" type="MyEventBase2Type"/><br />
<xs:element name="Detail" type="MyEventDetail2Type"/><br />
<xs:element name="Extension" type="MyEventExtension2Type"/><br />
</xs:sequence><br />
<xs:attribute name="version" type="xs:string" use="required"/><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<!-- MyALFEvent3Type iis restricted to an event with the event value "My Product Event Type C". <br />
It may contain object with type values of, "My Product Object Type B", "My Product Object Type C" or "My Product Object Type D"<br />
The event comes with MyEventDetails2Types event details and MyToolExtensionData2Type tool extension data. --><br />
<xs:complexType name="MyALFEvent3Type"><br />
<xs:complexContent><br />
<xs:restriction base="ALFEventType"><br />
<xs:sequence><br />
<xs:element name="Base" type="MyEventBase3Type"/><br />
<xs:element name="Detail" type="MyEventDetail2Type"/><br />
<xs:element name="Extension" type="MyEventExtension2Type"/><br />
</xs:sequence><br />
<xs:attribute name="version" type="xs:string" use="required"/><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<xs:complexType name="MyALFEvent3ResponseType"><br />
<xs:complexContent><br />
<xs:restriction base="ALFEventResponseType"><br />
<xs:sequence><br />
<xs:element name="Base" type="EventBaseType"/><br />
</xs:sequence><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<!-- My Event 1 --><br />
<xs:element name="MyEventNotice1" type="MyALFEvent1Type"/><br />
<!-- My Event 2 --><br />
<xs:element name="MyEventNotice2" type="MyALFEvent2Type"/><br />
<!-- My EventWithReply 3 --><br />
<xs:element name="MyEventNotice3" type="MyALFEvent3Type"/><br />
<xs:element name="MyEventNotice3Response" type="MyALFEvent3ResponseType"/><br />
</xs:schema><br />
<br />
</pre><br />
<br />
== WSDL ==<br />
MyALFEvents_001.wsdl<br />
<br />
This wsdl contains various commented out declarations for reference and to illustrate usage. The WSDL does not declare a real service but a specialized use of a service defined elsewhere (ie the ALF event manager service).<br />
<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<wsdl:definitions name="MyALFEnabledProduct"<br />
targetNamespace="http://www.eclipse.org/alf/XMLSchema/Events.wsdl"<br />
xmlns:tns="http://www.eclipse.org/alf/XMLSchema/Events.wsdl"<br />
xmlns:evt="http://www.eclipse.org/alf/XMLSchema/Events.xsd"<br />
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"<br />
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"<br />
xmlns:xsd="http://www.w3.org/2001/XMLSchema"<br />
xmlns:xs="http://www.w3.org/2001/XMLSchema"<br />
><br />
<wsdl:documentation><br />
WARNING: PRELIMINARY VERSION DO NOT USE<br />
<br />
Derived from ALFEventManager WSDL<br />
Copyright Notice<br />
The material in this document is Copyright (c) Serena Software, Inc. and others, 2005, 2006<br />
Terms and Conditions:<br />
The Eclipse Foundation makes available all content in this document ("Content").<br />
Unless otherwise indicated below, the Content is provided to you under the terms<br />
and conditions of the Eclipse Public License Version 1.0 ("EPL").<br />
A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html.<br />
For purposes of the EPL, "Program" will mean the Content.<br />
If you did not receive this Content directly from the Eclipse Foundation, the<br />
Content is being redistributed by another party ("Redistributor") and different<br />
terms and conditions may apply to your use of any object code in the Content.<br />
Check the Redistributor's license that was provided with the Content.<br />
If you did not receive any such license, contact the Redistributor.<br />
Unless otherwise indicated below, the terms and conditions of the EPL still apply to <br />
the Content.<br />
</wsdl:documentation><br />
<br />
<!-- My ALF Enabled Product Event WSDL --> <br />
<wsdl:types><br />
<xs:schema elementFormDefault="qualified" targetNamespace="http://www.eclipse.org/alf/XMLSchema/Events.xsd"<br />
xmlns:evt="http://www.eclipse.org/alf/XMLSchema/Events.xsd"<br />
xmlns="http://www.eclipse.org/alf/XMLSchema/Events.xsd"><br />
<xs:include schemaLocation="MyALFEvents_001.xsd" /><br />
<br />
</xs:schema><br />
</wsdl:types><br />
<br />
<!-- These Message definitions are the base messages for ALF events. They are provided for reference.<br />
The "EventNotice" has the base event types so therefore it is valid for any derived <br />
event type to appear in this message<br />
<br />
<wsdl:message name="EventNotice"><br />
<wsdl:part name="parameters" element="evt:EventNotice" /><br />
</wsdl:message><br />
<br />
<wsdl:message name="EventNoticeResponse"><br />
<wsdl:part name="parameters" element="evt:EventNoticeResponse" /><br />
</wsdl:message><br />
<br />
<wsdl:message name="EventNoticeWithReply"><br />
<wsdl:part name="parameters" element="evt:EventNoticeWithReply" /><br />
</wsdl:message><br />
<br />
<wsdl:message name="EventNoticeWithReplyResponse"><br />
<wsdl:part name="parameters" element="evt:EventNoticeWithReplyResponse" /><br />
</wsdl:message><br />
--><br />
<br />
<!-- These Messages definitions allow the definition of PortTypes that are specific<br />
to the derived Events --><br />
<!-- Note that these messages don't conform to the Document Literal Wrapped convention<br />
since these are really overloads and the element name "EventNotice" has the base type <br />
and so is not useful for specifying the derived types. Consequently the Message <br />
element name cannot be the same as the operation name for these derived types.<br />
This is probably not important for ALF.<br />
--><br />
<wsdl:message name="MyEventNotice1"><br />
<wsdl:part name="parameters" element="evt:MyEventNotice1" /><br />
</wsdl:message><br />
<br />
<wsdl:message name="MyEventNotice2"><br />
<wsdl:part name="parameters" element="evt:MyEventNotice2" /><br />
</wsdl:message><br />
<br />
<wsdl:message name="MyEventNotice3"><br />
<wsdl:part name="parameters" element="evt:MyEventNotice3" /><br />
</wsdl:message><br />
<br />
<wsdl:message name="MyEventNoticeResponse3"><br />
<wsdl:part name="parameters" element="evt:MyEventNoticeResponse3" /><br />
</wsdl:message><br />
<br />
<!-- This is the base Event port defintion for the event manager<br />
It is provided here for reference<br />
<wsdl:portType name="ALFEventManager"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:EventNotice"/><br />
<wsdl:output message="tns:EventNoticeResponse"/><br />
</wsdl:operation><br />
<wsdl:operation name="EventNoticeWithReply"><br />
<wsdl:input message="tns:EventNotice"/><br />
<wsdl:output message="tns:EventNoticeWithRepyResponse"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
This is the base Event port defintion for any ServiceFlow<br />
It is provided here for reference<br />
<wsdl:portType name="ALFServiceFlow"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:EventNotice"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
This is the base Event port defintion for any ServiceFlow with reply<br />
It is provided here for reference<br />
<wsdl:portType name="ALFServiceFlowWithReply"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:EventNotice"/><br />
<wsdl:output message="tns:EventNoticeResponse"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
--><br />
<br />
<!-- These PortTypes are virtual and are not used at runtime. Their sole purpose <br />
is to declare the derived event messages in a way that can be easily consumed by <br />
code that understands WSDL. In practise the event messages will always be sent to <br />
one of the ALF event manager ports which are defined to take the base event messages<br />
--><br />
<!-- This is the base Event port defintion for a ServiceFlow specifically designed to use the MyEventNotice1 type--><br />
<wsdl:portType name="ALFServiceFlowEventNotice1"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:MyEventNotice1"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
<!-- This is the base Event port defintion for a ServiceFlow specifically designed <br />
to use the MyEventNotice2 type--><br />
<wsdl:portType name="ALFServiceFlowEventNotice2"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:MyEventNotice2"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
<!-- This is the base Event port defintion for a ServiceFlow specifically designed <br />
to use the MyEventNotice3 type--><br />
<wsdl:portType name="ALFServiceFlowWithReplyEventNotice3"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:MyEventNotice3"/><br />
<wsdl:output message="tns:MyEventNoticeResponse3"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
<!-- These are the base Event and Service Flow bindings<br />
They are orginally declared in the ALFEventManager WSDL and repeated here for <br />
reference. This is the base EventManager binding<br />
<br />
<wsdl:binding name="ALFEventManagerSOAP" type="tns:ALFEventManager"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal"/><br />
</wsdl:output><br />
</wsdl:operation><br />
<wsdl:operation name="EventNoticeWithReply"><br />
<soap:operation soapAction="EventNoticeWithReply"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal"/><br />
</wsdl:output><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
This is the base ServiceFlow binding<br />
<br />
<wsdl:binding name="ALFServiceFlowSOAP" type="tns:ALFServiceFlow"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
This is the base ServiceFlowWithResonse binding<br />
<br />
<wsdl:binding name="ALFServiceFlowWithResponseSOAP" type="tns:ALFServiceFlowWithReply"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal"/><br />
</wsdl:output><br />
</wsdl:operation><br />
</wsdl:binding><br />
--><br />
<br />
<!-- These Bindings are virtual and are never actually used. Their sole purpose is<br />
to declare the derived event messages in a way that can be easily consumed by code<br />
that understands WSDL. In practise the event messages will always be sent to one of<br />
the ALF event manager ports which are defined to take the base event messages.<br />
--> <br />
<!-- These are the Event and Service Flow bindings for specific events--><br />
<wsdl:binding name="ALFServiceFlow1SOAP" type="tns:ALFServiceFlowEventNotice1"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
<wsdl:binding name="ALFServiceFlow2SOAP" type="tns:ALFServiceFlowEventNotice2"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
<wsdl:binding name="ALFServiceFlowWithReply3SOAP" type="tns:ALFServiceFlowWithReplyEventNotice3"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal"/><br />
</wsdl:output><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
<!-- Example service definitions<br />
These service definition examples illustrate the definitions of a service flows<br />
that are written to handle the events defined in this WSDL. They are not used <br />
directly but would be constructed by the service flow declarations that handle the <br />
various events.<br />
<br />
This is the ALF event manager service provided for reference<br />
<wsdl:service name="ALFEventManager"><br />
<wsdl:port binding="tns:ALFEventManagerSOAP" name="ALFEventManagerSOAP"><br />
<soap:address location="http://localhost:8080/alfeventmgr/services/ALFEventManager"/><br />
</wsdl:port><br />
</wsdl:service><br />
<br />
This service flow handles "MyEventNotice1" event<br />
<wsdl:service name="ALFServiceFlow1"><br />
<wsdl:port binding="tns:ALFServiceFlow1SOAP" name="ALFServiceFlow1SOAP"><br />
<soap:address location="http://localhost:8080/BPELengine/services/ALFServiceFlow1"/><br />
</wsdl:port><br />
</wsdl:service><br />
<br />
This service flow handles "MyEventNotice2" event<br />
<wsdl:service name="ALFServiceFlow2"><br />
<wsdl:port binding="tns:ALFServiceFlow2SOAP" name="ALFServiceFlow2SOAP"><br />
<soap:address location="http://localhost:8080/BPELengine/services/ALFServiceFlow2"/><br />
</wsdl:port><br />
</wsdl:service><br />
<br />
This service flow handles "MyEventNotice3" event and responds with a "MyEventNoticeResponse3" message<br />
<wsdl:service name="ALFServiceFlowWithReply3"><br />
<wsdl:port binding="tns:ALFServiceFlowWithReply3SOAP" name="ALFServiceFlowWithReply3SOAP"><br />
<soap:address location="http://localhost:8080/BPELengine/services/ALFServiceFlowWithReply3"/><br />
</wsdl:port><br />
</wsdl:service><br />
--> <br />
</wsdl:definitions><br />
<br />
</pre></div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/Vocabularies/Event_Declaration_Schema&diff=13481ALF/Vocabularies/Event Declaration Schema2006-10-10T18:24:25Z<p>Alf tbuss.yahoo.com: /* WSDL */</p>
<hr />
<div>__TOC__<br />
[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
== Event Declaration ==<br />
<br />
There are a number of goals we wish to achieve.<br />
<br />
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<br />
<br />
2. We need to be able to enumerate the possible events as explict combinations for inclusion in the event dispatch map.<br />
<br />
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.<br />
<br />
Attached are some experimental schemas and WSDL that illustrate how a tool might declare its ALF events.<br />
<br />
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.<br />
<br />
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]]<br />
<br />
The following two files are for a fictitious tool that needs to declare events <br />
<br />
MyALFEvents_001.xsd<br />
MyALFEvents_001.wsdl<br />
<br />
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.<br />
<br />
The WSDL uses the derived types to redeclare the ALFEventManager WSDL in terms of the more restrictive and details tool specific types.<br />
<br />
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.<br />
<br />
<br />
Problems with the WSDL - goal #1<br />
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.<br />
<br />
The runtime consequences of this depend on what the tool acutally does when it sends its event message to the EventManager.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Problems with the valid combinations - goal #2<br />
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.<br />
<br />
Problems with enumerating the events - goal #3<br />
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.<br />
<br />
== Schema ==<br />
MyALFEvents_001.xsd<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<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"><br />
<xs:include schemaLocation="ALFEventBase_001.xsd"/><br />
<xs:annotation><br />
<xs:documentation><br />
WARNING: PRELIMINARY VERSION DO NOT USE<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:annotation><br />
<xs:documentation><br />
Copyright Notice<br />
The material in this document is Copyright (c) Serena Software, Inc. and others, 2005<br />
Terms and Conditions:<br />
The Eclipse Foundation makes available all content in this document ("Content").<br />
Unless otherwise indicated below, the Content is provided to you under the terms<br />
and conditions of the Eclipse Public License Version 1.0 ("EPL").<br />
A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html.<br />
For purposes of the EPL, "Program" will mean the Content.<br />
If you did not receive this Content directly from the Eclipse Foundation, the<br />
Content is being redistributed by another party ("Redistributor") and different<br />
terms and conditions may apply to your use of any object code in the Content.<br />
Check the Redistributor's license that was provided with the Content.<br />
If you did not receive any such license, contact the Redistributor.<br />
Unless otherwise indicated below, the terms and conditions of the EPL still apply to the Content.<br />
</xs:documentation><br />
</xs:annotation><br />
<!-- Begin BasicEventTypes --><br />
<!-- These event declarations restrict the possible values for EventType, Object and Source.<br />
There are various options for declaring these derivied types depending on the valid combinations of EventType<br />
and Object values.<br />
If any EventType value can be combined with any Object value then all possible values can be declared in a single<br />
type.<br />
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<br />
Parts of Source is generally constant for any particular product. --><br />
<!-- 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" --><br />
<xs:complexType name="MyEventBase1Type"><br />
<xs:annotation><br />
<xs:documentation><br />
</xs:documentation><br />
</xs:annotation><br />
<xs:complexContent><br />
<xs:restriction base="EventBaseType"><br />
<xs:sequence><br />
<xs:element name="EventID" type="EventIDType"/><br />
<xs:element name="Timestamp" type="TimestampType"/><br />
<xs:element name="EventType" type="MyEventType1Type"/><br />
<xs:element name="Object" type="MyObjectData1Type"/><br />
<xs:element name="Source" type="MySourceType"/><br />
<xs:element name="PredecedingEvent" type="EventIDType" nillable="true"/><br />
<xs:element name="ApplicationName" type="ApplicationNameType" nillable="true"/><br />
<xs:element name="Environment" type="EnvironmentType" nillable="true"/><br />
<xs:element name="User" type="UserType"/><br />
</xs:sequence><br />
<xs:attribute name="alfEventVersion" type="xs:string" use="required"/><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<!-- MyBasicEvent2Type is restricted to an event with the event value "My Product Event Type B". <br />
It may contain object with type values of, "My Product Object Type B" or "My Product Object Type C"--><br />
<xs:complexType name="MyEventBase2Type"><br />
<xs:annotation><br />
<xs:documentation><br />
</xs:documentation><br />
</xs:annotation><br />
<xs:complexContent><br />
<xs:restriction base="EventBaseType"><br />
<xs:sequence><br />
<xs:element name="EventID" type="EventIDType"/><br />
<xs:element name="Timestamp" type="TimestampType"/><br />
<xs:element name="EventType" type="MyEventType2Type"/><br />
<xs:element name="Object" type="MyObjectData2Type"/><br />
<xs:element name="Source" type="MySourceType"/><br />
<xs:element name="PredecedingEvent" type="EventIDType" nillable="true"/><br />
<xs:element name="ApplicationName" type="ApplicationNameType" nillable="true"/><br />
<xs:element name="Environment" type="EnvironmentType" nillable="true"/><br />
<xs:element name="User" type="UserType"/><br />
</xs:sequence><br />
<xs:attribute name="alfEventVersion" type="xs:string" use="required"/><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<!-- MyBasicEvent3Type is restricted to an event with the event value "My Product Event Type C". <br />
It may contain object with type values of, "My Product Object Type B", "My Product Object Type C" or "My Product Object Type D"--><br />
<xs:complexType name="MyEventBase3Type"><br />
<xs:annotation><br />
<xs:documentation><br />
</xs:documentation><br />
</xs:annotation><br />
<xs:complexContent><br />
<xs:restriction base="EventBaseType"><br />
<xs:sequence><br />
<xs:element name="EventID" type="EventIDType"/><br />
<xs:element name="Timestamp" type="TimestampType"/><br />
<xs:element name="EventType" type="MyEventType3Type"/><br />
<xs:element name="Object" type="MyObjectData3Type"/><br />
<xs:element name="Source" type="MySourceType"/><br />
<xs:element name="PredecedingEvent" type="EventIDType" nillable="true"/><br />
<xs:element name="ApplicationName" type="ApplicationNameType" nillable="true"/><br />
<xs:element name="Environment" type="EnvironmentType" nillable="true"/><br />
<xs:element name="User" type="UserType"/><br />
</xs:sequence><br />
<xs:attribute name="alfEventVersion" type="xs:string" use="required"/><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<!-- In order to restrict the EventType, Object and Source values we need to declare custom restricted types.<br />
Depending how the allowed values for EventType, Object and Source combine we can declare either one type<br />
that restricts to all possible values or a number of single value types or some combination --><br />
<!-- These EventType variants each have a single possible value --><br />
<xs:simpleType name="MyEventType1Type"><br />
<xs:restriction base="EventTypeType"><br />
<xs:enumeration value="My Product Event Type A"/><br />
</xs:restriction><br />
</xs:simpleType><br />
<xs:simpleType name="MyEventType2Type"><br />
<xs:restriction base="EventTypeType"><br />
<xs:enumeration value="My Product Event Type B"/><br />
</xs:restriction><br />
</xs:simpleType><br />
<xs:simpleType name="MyEventType3Type"><br />
<xs:restriction base="EventTypeType"><br />
<xs:enumeration value="My Product Event Type C"/><br />
</xs:restriction><br />
</xs:simpleType><br />
<!-- ============= Object that triggered the event ============= --><br />
<!-- MyObjectData1Type is restricted to one possible value --><br />
<!--The ObjectData type derivations illustrate how to combine a number of possible values that may be used interchangeably.<br />
This can be useful shorthand to compact the event definitions by grouping set of values into a single definition.<br />
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.<br />
--><br />
<xs:complexType name="MyObjectData1Type"><br />
<xs:annotation><br />
<xs:documentation><br />
</xs:documentation><br />
</xs:annotation><br />
<xs:complexContent><br />
<xs:restriction base="ObjectDataType"><br />
<xs:sequence><br />
<xs:element name="ObjectType" type="MyObjectType1Type"/><br />
<xs:element name="ObjectId" type="ObjectIdType"/><br />
</xs:sequence><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<xs:simpleType name="MyObjectType1Type"><br />
<xs:annotation><br />
<xs:documentation><br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="ObjectTypeType"><br />
<xs:enumeration value="My Product Object Type A"/><br />
</xs:restriction><br />
</xs:simpleType><br />
<!-- MyObjectData2Type is restricted to two possible values --><br />
<xs:complexType name="MyObjectData2Type"><br />
<xs:annotation><br />
<xs:documentation><br />
</xs:documentation><br />
</xs:annotation><br />
<xs:complexContent><br />
<xs:restriction base="ObjectDataType"><br />
<xs:sequence><br />
<xs:element name="ObjectType" type="MyObjectType2Type"/><br />
<xs:element name="ObjectId" type="ObjectIdType"/><br />
</xs:sequence><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<xs:simpleType name="MyObjectType2Type"><br />
<xs:annotation><br />
<xs:documentation><br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="ObjectTypeType"><br />
<xs:enumeration value="My Product Object Type B"/><br />
<xs:enumeration value="My Product Object Type C"/><br />
</xs:restriction><br />
</xs:simpleType><br />
<!-- MyObjectData3Type is restricted to three possible values --><br />
<xs:complexType name="MyObjectData3Type"><br />
<xs:annotation><br />
<xs:documentation><br />
</xs:documentation><br />
</xs:annotation><br />
<xs:complexContent><br />
<xs:restriction base="ObjectDataType"><br />
<xs:sequence><br />
<xs:element name="ObjectType" type="MyObjectType3Type"/><br />
<xs:element name="ObjectId" type="ObjectIdType"/><br />
</xs:sequence><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<xs:simpleType name="MyObjectType3Type"><br />
<xs:annotation><br />
<xs:documentation><br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="ObjectTypeType"><br />
<xs:enumeration value="My Product Object Type B"/><br />
<xs:enumeration value="My Product Object Type C"/><br />
<xs:enumeration value="My Product Object Type D"/><br />
</xs:restriction><br />
</xs:simpleType><br />
<!-- ============= The source (i.e, tool or product) that emitted the event ============= --><br />
<!-- The values for Product and ProductVersion are constant for all events from a particular product installation -<br />
ProductInstance and ProductCallbackURI are determined at install time an will not have declared restricted values --><br />
<xs:complexType name="MySourceType"><br />
<xs:complexContent><br />
<xs:restriction base="SourceType"><br />
<xs:sequence><br />
<xs:element name="Product" type="MyProductType"/><br />
<xs:element name="ProductVersion" type="MyProductVersionType"/><br />
<xs:element name="ProductInstance" type="ProductInstanceType"/><br />
<xs:element name="ProductCallbackURI" type="ProductCallbackURIType" nillable="true" minOccurs="0"/><br />
</xs:sequence><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<xs:simpleType name="MyProductType"><br />
<xs:restriction base="ProductType"><br />
<xs:enumeration value="My Product Name"/><br />
</xs:restriction><br />
</xs:simpleType><br />
<xs:simpleType name="MyProductVersionType"><br />
<xs:restriction base="ProductVersionType"><br />
<xs:enumeration value="My Product Version"/><br />
</xs:restriction><br />
</xs:simpleType><br />
<!-- Each event type or object type could be associated with different event detail data.<br />
We need to declare the possible EventDetail types--><br />
<xs:complexType name="MyEventDetail1Type"><br />
<xs:complexContent><br />
<xs:restriction base="EventDetailType"><br />
<xs:sequence><br />
<xs:any/><br />
</xs:sequence><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<xs:complexType name="MyEventDetail2Type"><br />
<xs:complexContent><br />
<xs:restriction base="EventDetailType"><br />
<xs:sequence><br />
<xs:any/><br />
</xs:sequence><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<xs:complexType name="MyEventDetail3Type"><br />
<xs:complexContent><br />
<xs:restriction base="EventDetailType"><br />
<xs:sequence><br />
<xs:element name="MyEventDetailDate1" type="xs:string"/><br />
</xs:sequence><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<xs:complexType name="MyEventDetail4Type"><br />
<xs:complexContent><br />
<xs:restriction base="EventExtensionType"><br />
<xs:sequence><br />
<xs:choice><br />
<xs:element name="MyEventDetail1" type="MyEventDetail1Type"/><br />
<xs:element name="MyEventDetail2" type="MyEventDetail2Type"/><br />
<xs:element name="MyEventDetail3" type="MyEventDetail3Type"/><br />
</xs:choice><br />
</xs:sequence><br />
<xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<!-- Each event type or object type could be associated with different ToolExtension data.<br />
We need to declare the possible ToolExtension types--><br />
<xs:complexType name="MyEventExtension1Type"><br />
<xs:complexContent><br />
<xs:restriction base="EventExtensionType"><br />
<xs:sequence><br />
<xs:any/><br />
</xs:sequence><br />
<xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<xs:complexType name="MyEventExtension2Type"><br />
<xs:complexContent><br />
<xs:restriction base="EventExtensionType"><br />
<xs:sequence><br />
<xs:any/><br />
</xs:sequence><br />
<xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<!-- End BasicEventTypes --><br />
<!-- BEGIN ALFEvent --><br />
<!-- We declare all the possible event structures --><br />
<!-- 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".<br />
The event comes with MyEventDetails1Types event details and MyToolExtensionData1Type tool extension data. --><br />
<xs:complexType name="MyALFEvent1Type"><br />
<xs:complexContent><br />
<xs:restriction base="ALFEventType"><br />
<xs:sequence><br />
<xs:element name="Base" type="MyEventBase1Type"/><br />
<xs:element name="Detail" type="MyEventDetail1Type"/><br />
<xs:element name="Extension" type="MyEventExtension1Type"/><br />
</xs:sequence><br />
<xs:attribute name="version" type="xs:string" use="required"/><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<!-- MyALFEvent2Type is restricted to an event with the value "My Product Event Type B". <br />
It may contain object with type values of, "My Product Object Type A" or "My Product Object Type B".<br />
The event comes with MyEventDetails2Types event details and MyToolExtensionData2Type tool extension data. --><br />
<xs:complexType name="MyALFEvent2Type"><br />
<xs:complexContent><br />
<xs:restriction base="ALFEventType"><br />
<xs:sequence><br />
<xs:element name="Base" type="MyEventBase2Type"/><br />
<xs:element name="Detail" type="MyEventDetail2Type"/><br />
<xs:element name="Extension" type="MyEventExtension2Type"/><br />
</xs:sequence><br />
<xs:attribute name="version" type="xs:string" use="required"/><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<!-- MyALFEvent3Type iis restricted to an event with the event value "My Product Event Type C". <br />
It may contain object with type values of, "My Product Object Type B", "My Product Object Type C" or "My Product Object Type D"<br />
The event comes with MyEventDetails2Types event details and MyToolExtensionData2Type tool extension data. --><br />
<xs:complexType name="MyALFEvent3Type"><br />
<xs:complexContent><br />
<xs:restriction base="ALFEventType"><br />
<xs:sequence><br />
<xs:element name="Base" type="MyEventBase3Type"/><br />
<xs:element name="Detail" type="MyEventDetail2Type"/><br />
<xs:element name="Extension" type="MyEventExtension2Type"/><br />
</xs:sequence><br />
<xs:attribute name="version" type="xs:string" use="required"/><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<xs:complexType name="MyALFEvent3ResponseType"><br />
<xs:complexContent><br />
<xs:restriction base="ALFEventResponseType"><br />
<xs:sequence><br />
<xs:element name="Base" type="EventBaseType"/><br />
</xs:sequence><br />
</xs:restriction><br />
</xs:complexContent><br />
</xs:complexType><br />
<!-- My Event 1 --><br />
<xs:element name="MyEventNotice1" type="MyALFEvent1Type"/><br />
<!-- My Event 2 --><br />
<xs:element name="MyEventNotice2" type="MyALFEvent2Type"/><br />
<!-- My EventWithReply 3 --><br />
<xs:element name="MyEventNotice3" type="MyALFEvent3Type"/><br />
<xs:element name="MyEventNotice3Response" type="MyALFEvent3ResponseType"/><br />
</xs:schema><br />
<br />
</pre><br />
<br />
== WSDL ==<br />
MyALFEvents_001.wsdl<br />
<br />
This wsdl contains various commented out declarations for reference and to illustrate usage. The WSDL does not declare a real service but a specialized use of a service defined elsewhere (ie the ALF event manager service).<br />
<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<wsdl:definitions name="MyALFEnabledProduct"<br />
targetNamespace="http://www.eclipse.org/alf/XMLSchema/Events.wsdl"<br />
xmlns:tns="http://www.eclipse.org/alf/XMLSchema/Events.wsdl"<br />
xmlns:evt="http://www.eclipse.org/alf/XMLSchema/Events.xsd"<br />
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"<br />
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"<br />
xmlns:xsd="http://www.w3.org/2001/XMLSchema"<br />
xmlns:xs="http://www.w3.org/2001/XMLSchema"<br />
><br />
<wsdl:documentation><br />
WARNING: PRELIMINARY VERSION DO NOT USE<br />
<br />
Derived from ALFEventManager WSDL<br />
Copyright Notice<br />
The material in this document is Copyright (c) Serena Software, Inc. and others, 2005, 2006<br />
Terms and Conditions:<br />
The Eclipse Foundation makes available all content in this document ("Content").<br />
Unless otherwise indicated below, the Content is provided to you under the terms<br />
and conditions of the Eclipse Public License Version 1.0 ("EPL").<br />
A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html.<br />
For purposes of the EPL, "Program" will mean the Content.<br />
If you did not receive this Content directly from the Eclipse Foundation, the<br />
Content is being redistributed by another party ("Redistributor") and different<br />
terms and conditions may apply to your use of any object code in the Content.<br />
Check the Redistributor's license that was provided with the Content.<br />
If you did not receive any such license, contact the Redistributor.<br />
Unless otherwise indicated below, the terms and conditions of the EPL still apply to <br />
the Content.<br />
</wsdl:documentation><br />
<br />
<!-- My ALF Enabled Product Event WSDL --> <br />
<wsdl:types><br />
<xs:schema elementFormDefault="qualified" targetNamespace="http://www.eclipse.org/alf/XMLSchema/Events.xsd"<br />
xmlns:evt="http://www.eclipse.org/alf/XMLSchema/Events.xsd"<br />
xmlns="http://www.eclipse.org/alf/XMLSchema/Events.xsd"><br />
<xs:include schemaLocation="MyALFEvents_001.xsd" /><br />
<br />
</xs:schema><br />
</wsdl:types><br />
<br />
<!-- These Message definitions are the base messages for ALF events.<br />
The "EventNotice" has the base event types so therefore it is valid for any derived <br />
event type to appear in this message<br />
--><br />
<wsdl:message name="EventNotice"><br />
<wsdl:part name="parameters" element="evt:EventNotice" /><br />
</wsdl:message><br />
<br />
<wsdl:message name="EventNoticeResponse"><br />
<wsdl:part name="parameters" element="evt:EventNoticeResponse" /><br />
</wsdl:message><br />
<br />
<wsdl:message name="EventNoticeWithReply"><br />
<wsdl:part name="parameters" element="evt:EventNoticeWithReply" /><br />
</wsdl:message><br />
<br />
<wsdl:message name="EventNoticeWithReplyResponse"><br />
<wsdl:part name="parameters" element="evt:EventNoticeWithReplyResponse" /><br />
</wsdl:message><br />
<br />
<!-- These Messages definitions allow the definition of PortTypes that are specific<br />
to the derived Events --><br />
<!-- Note that these messages don't conform to the Document Literal Wrapped convention<br />
since these are really overloads and the element name "EventNotice" has the base type <br />
and so is not useful for specifying the derived types. Consequently the Message <br />
element name cannot be the same as the operation name for these derived types.<br />
This is probably not important for ALF.<br />
--><br />
<wsdl:message name="MyEventNotice1"><br />
<wsdl:part name="parameters" element="evt:MyEventNotice1" /><br />
</wsdl:message><br />
<br />
<wsdl:message name="MyEventNotice2"><br />
<wsdl:part name="parameters" element="evt:MyEventNotice2" /><br />
</wsdl:message><br />
<br />
<wsdl:message name="MyEventNotice3"><br />
<wsdl:part name="parameters" element="evt:MyEventNotice3" /><br />
</wsdl:message><br />
<br />
<wsdl:message name="MyEventNoticeResponse3"><br />
<wsdl:part name="parameters" element="evt:MyEventNoticeResponse3" /><br />
</wsdl:message><br />
<br />
<!-- This is the base Event port defintion for the event manager<br />
It is provided here for reference<br />
<wsdl:portType name="ALFEventManager"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:EventNotice"/><br />
<wsdl:output message="tns:EventNoticeResponse"/><br />
</wsdl:operation><br />
<wsdl:operation name="EventNoticeWithReply"><br />
<wsdl:input message="tns:EventNotice"/><br />
<wsdl:output message="tns:EventNoticeWithRepyResponse"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
This is the base Event port defintion for any ServiceFlow<br />
It is provided here for reference<br />
<wsdl:portType name="ALFServiceFlow"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:EventNotice"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
This is the base Event port defintion for any ServiceFlow with reply<br />
It is provided here for reference<br />
<wsdl:portType name="ALFServiceFlowWithReply"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:EventNotice"/><br />
<wsdl:output message="tns:EventNoticeResponse"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
--><br />
<br />
<!-- These PortTypes are virtual and are not used at runtime. Their sole purpose <br />
is to declare the derived event messages in a way that can be easily consumed by <br />
code that understands WSDL. In practise the event messages will always be sent to <br />
one of the ALF event manager ports which are defined to take the base event messages<br />
--><br />
<!-- This is the base Event port defintion for a ServiceFlow specifically designed to use the MyEventNotice1 type--><br />
<wsdl:portType name="ALFServiceFlowEventNotice1"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:MyEventNotice1"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
<!-- This is the base Event port defintion for a ServiceFlow specifically designed <br />
to use the MyEventNotice2 type--><br />
<wsdl:portType name="ALFServiceFlowEventNotice2"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:MyEventNotice2"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
<!-- This is the base Event port defintion for a ServiceFlow specifically designed <br />
to use the MyEventNotice3 type--><br />
<wsdl:portType name="ALFServiceFlowWithReplyEventNotice3"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:MyEventNotice3"/><br />
<wsdl:output message="tns:MyEventNoticeResponse3"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
<!-- These are the base Event and Service Flow bindings<br />
They are orginally declared in the ALFEventManager WSDL and repeated here for <br />
reference. This is the base EventManager binding<br />
<br />
<wsdl:binding name="ALFEventManagerSOAP" type="tns:ALFEventManager"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal"/><br />
</wsdl:output><br />
</wsdl:operation><br />
<wsdl:operation name="EventNoticeWithReply"><br />
<soap:operation soapAction="EventNoticeWithReply"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal"/><br />
</wsdl:output><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
This is the base ServiceFlow binding<br />
<br />
<wsdl:binding name="ALFServiceFlowSOAP" type="tns:ALFServiceFlow"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
This is the base ServiceFlowWithResonse binding<br />
<br />
<wsdl:binding name="ALFServiceFlowWithResponseSOAP" type="tns:ALFServiceFlowWithReply"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal"/><br />
</wsdl:output><br />
</wsdl:operation><br />
</wsdl:binding><br />
--><br />
<br />
<!-- These Bindings are virtual and are never actually used. Their sole purpose is<br />
to declare the derived event messages in a way that can be easily consumed by code<br />
that understands WSDL. In practise the event messages will always be sent to one of<br />
the ALF event manager ports which are defined to take the base event messages.<br />
--> <br />
<!-- These are the Event and Service Flow bindings for specific events--><br />
<wsdl:binding name="ALFServiceFlow1SOAP" type="tns:ALFServiceFlowEventNotice1"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
<wsdl:binding name="ALFServiceFlow2SOAP" type="tns:ALFServiceFlowEventNotice2"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
<wsdl:binding name="ALFServiceFlowWithReply3SOAP" type="tns:ALFServiceFlowWithReplyEventNotice3"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal"/><br />
</wsdl:output><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
<!-- Example service definitions<br />
These service definition examples illustrate the definitions of a service flows<br />
that are written to handle the events defined in this WSDL. They are not used <br />
directly but would be constructed by the service flow declarations that handle the <br />
various events.<br />
<br />
This is the ALF event manager service provided for reference<br />
<wsdl:service name="ALFEventManager"><br />
<wsdl:port binding="tns:ALFEventManagerSOAP" name="ALFEventManagerSOAP"><br />
<soap:address location="http://localhost:8080/alfeventmgr/services/ALFEventManager"/><br />
</wsdl:port><br />
</wsdl:service><br />
<br />
This service flow handles "MyEventNotice1" event<br />
<wsdl:service name="ALFServiceFlow1"><br />
<wsdl:port binding="tns:ALFServiceFlow1SOAP" name="ALFServiceFlow1SOAP"><br />
<soap:address location="http://localhost:8080/BPELengine/services/ALFServiceFlow1"/><br />
</wsdl:port><br />
</wsdl:service><br />
<br />
This service flow handles "MyEventNotice2" event<br />
<wsdl:service name="ALFServiceFlow2"><br />
<wsdl:port binding="tns:ALFServiceFlow2SOAP" name="ALFServiceFlow2SOAP"><br />
<soap:address location="http://localhost:8080/BPELengine/services/ALFServiceFlow2"/><br />
</wsdl:port><br />
</wsdl:service><br />
<br />
This service flow handles "MyEventNotice3" event and responds with a "MyEventNoticeResponse3" message<br />
<wsdl:service name="ALFServiceFlowWithReply3"><br />
<wsdl:port binding="tns:ALFServiceFlowWithReply3SOAP" name="ALFServiceFlowWithReply3SOAP"><br />
<soap:address location="http://localhost:8080/BPELengine/services/ALFServiceFlowWithReply3"/><br />
</wsdl:port><br />
</wsdl:service><br />
--> <br />
</wsdl:definitions><br />
<br />
</pre></div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/architecture/ALF_Schemas_001&diff=13096ALF/architecture/ALF Schemas 0012006-10-05T21:48:11Z<p>Alf tbuss.yahoo.com: /* '''8. "Clean up" or "Gratuitously change" some names.''' */</p>
<hr />
<div>__TOC__ <br />
[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
<br />
== Introduction ==<br />
'''ALF Event Manager Schemas and WSDL version 001'''<br />
<br />
We have been reviewing the ALF Event Schema and our recommendation is that if should be flattened and simplified. Here the details of our suggestions and reasoning so far. The proposed schema is just for illustration and should not <br />
be considered final. Please respond with any comments you may have and any other suggestions about way to streamline the ALF event Schema. <br />
<br />
Here are the details of the changes which have undergone some review and will be likely be adopted. These changes are refected in the Schema and WSDL below<br />
<br />
<br />
=== '''1. Eliminate a nesting level between BasicEventType and Event Data.''' ===<br />
<br />
This serves no particular purpose except to separate it from the Context Array which is not returned on an ACK. If we eliminate the Context Array as I suggest below then this distinction is no longer required.<br />
<br />
<br />
=== '''2. Eliminate the Object Array in favor of a single ObjectType.''' ===<br />
<br />
This is in BasicEventType. It seems to me that is very rare that we will encounter a situation where a tool cannot provide a single identity to use to call back for additional information. While the array and related "relationship" attribute may be potentially powerful it would seem better relegated to a potential common vocabulary type for vocabulary or tool specific event details. The only potential issue is that removing the array from the basic event also removes it from the consideration as part of an ALF event manager dispatch rule. Currently we only use the first object in the array. This seems a reasonable price to pay The array seems somewhat complex for that purpose due to its rather arbitrary nature and, if we find we are really missing it later we have the option of extending the Basic Event to include an array of this nature in addition to the primary object.<br />
<br />
<br />
=== '''3. Eliminate the Context Array''' ===<br />
<br />
We should also merge the current user details into the BasicEventType. The context array does not seem that useful to me. It just makes the current context harder to discern. Further, it does not seem to be desirable from a security standpoint to be passing around arrays of credentials. I don't see any particular programmatic use of this feature and a simple log or a relationship store would be a better method of tracing contexts after the event. Even if it is of some practical use, that use relies on the support to tools to return the context in full in an event. This seems unlikely except by the most avid of ALF participating tools rendering it useless in the foreseeable future.<br />
<br />
=== '''4.Eliminate "InitiatingFlow" and the "nesting" attribute''' ===<br />
<br />
This is an aspect of the Context. This does not provide much useful information and again relies on all participants to behave the ALF way in order for the nesting counter to accurate. Instead provide some preceding IDs ( see below) and rely on logging. I am unclear whether it would be useful to know if the event comes from a user interaction or a service flow. It would seem to me likely that that this can be inferred from the event type and event product information and not explicit flag is required. I am unclear what you would do with it in any case. Thus I would just eliminate it.<br />
<br />
<br />
=== '''5. Add "PrecedingEvent" and "PrecedingServiceFlow" to the Basic Event Type as nillable elements.''' ===<br />
<br />
If the event is generated in the directly by a service flow then the ServiceFlow will fill these, identifying itself and the event that initiated it. Optionally an ALF compliant service may take this data and return it in any event it generates. The Source elements can be used to distinguish the cases.<br />
<br />
<br />
=== '''6. Add a ALFEventNoACK element and associated Type.''' ===<br />
<br />
Async Service flows have this type. Unfortunately the Event Manager currently dispatches using ALFEventACK which is incorrect and confusing. (Note: this change and been subsumed by the name changes describe in 8. below)<br />
<br />
<br />
=== '''7. Eliminate the use of the "mixed" attribute.''' ===<br />
<br />
I believed the used of the attribute "mixed" is incorrect. This attribute means that and element can contain both content text and other elements. I don't think that is the intent. Its use here appears to be associated with the use of an attribute which is incorrect.<br />
<br />
<br />
=== '''8. "Clean up" or "Gratuitously change" some names.''' ===<br />
<br />
The purpose is to make things feel a bit more consistent and this is really our last chance to do so.<br />
<br />
The suggested changes are as follows:<br />
<br />
The schema file will be called ALFEventBase.xsd<br />
<br />
BasicEventType -> EventBaseType<br />
<br />
EventDetailsType -> EventDetailType<br />
<br />
ToolExtensionDataType -> EventExtensionType <br />
<br />
BasicEvent -> Base <br />
<br />
EventDetails -> Detail<br />
<br />
ToolExtensionData -> Extension<br />
<br />
ALFEventACKType -> ALFEventResponseType<br />
<br />
Note: The bool value is eliminated from this since there seems little point in a boolean that will always be true if it is succesfully received but otherwise not received.<br />
<br />
ALFEvent -> EventNotice<br />
<br />
ALFEventACK -> EventNoticeResponse<br />
<br />
Note: this is to conform with the WSDL "Document Literal Wrapped" convention<br />
<br />
The following messages are added for "synchronous events" <br />
EventNoticeWithReply<br />
EventNoticeWithReplyResponse<br />
<br />
The EventNoticeWithReply operations is added to the ALFEventManager service<br />
<br />
Some new ports and corresponding bindings are added to provide the base template for Service Flow services ALFServiceFlow ALFServiceFlowWithReply (see item #11)<br />
<br />
=== '''9. The Credential element should be typed "any".''' ===<br />
It is likely that the credential element will be expressed as XML. It may be more covenient to contain such an element as an XML structure rather than by having it encoded or encapsualted as CData. may the CredentialType "any" allows it to take any of these formats.<br />
<br />
=== '''10. Added New elements to Base".''' ===<br />
''ApplicationName'' - This element distinguishes one ALF application from another. An ALF application is a set of event/service-flow relationships combined to achieve a particualr purpose. The even manager manages these sets independently allowing separate deployment and control of groups of service flows. The rules concerning how ApplicationName is used are described in Admin Service specification<br />
<br />
''Environment'' - This element indicates the environment in which the installed sytem is running. The value will be picked up from some installed configuration attribute (eg from a "properties" file or envirnonment variable). The primary purpose is for logging and to ensure that the various running components are part of the same installation environment (eg Dev, QA, Production, ProductionEastCoast). There are no standard values for this. The value is configured by the installation.<br />
<br />
=== '''11. New Ports and correspondin bindings added".''' ===<br />
Some new ports and corresponding bindings are added to provide the base template for Service Flow services. Previously A service flow had to use the Event manager port to which is subtly different from the Service flow<br />
<br />
ALFServiceFlow - the port/binding intended to be used by a normal "asynchronous" or one way service flow<br />
<br />
ALFServiceFlowWithReply - the port/binding intended to be used by a service flow that provides a response to the caller.<br />
<br />
== Additional Changes ==<br />
Listed below are some other possible simplifications and name changes. These need some some further discussion/definition before we accept them.<br />
<br />
==='''1. Combine Detail and Extension to a single xs:any element perhaps called <payload>.'''===<br />
<br />
It is not clear to me there is an advantage in keeping these separate. If there is we need to make that clear. It would seem adequate to me that a tool would declare its event data and that it will either be a pure ALF vocab structure or it will be custom or it will be some combination. Forcing the division seems like it will just make it inconvenient for tools to declare their data and will mean either misuse or no use of the ALF vocabulary.<br />
<br />
==='''2. Eliminate the "required" attributes.'''===<br />
<br />
''alfEventVersion'' on EventBaseType (nee BasicEventType) I realise the intent is to inform the recipient that the event definition is derived froma particular verision and possibly this is useful a runtime since it would possibly allow use to handle incompatible versions. This seem somewhat unlikely at this level at which it works. Maybe it is cheap enough to make that enough but something bothers me about it and I suspect that it will never be used. It is something that can be added if we ever do need it but for now it's just extra crud someone has to set before sending the event that doesn't do anything. If we have it, it seem like the schema should define the exact value it must contain.<br />
<br />
''schemaLocation'' on EventDetailType (nee EventDetailsType) and EventExtensionType (nee ToolExtensionData) I realise these attributes are supposed to point to the schema for the contained data but I'm not sure what the point of these attributes really is from a practical perspective. It seems to me nothing at runtime will look at these and validate the element content so perhaps they are just gratuitous and unecessary. Possibly there is a clearer way to do this since we do need tools to declare their events. Possibly the schema attribute, if we have it, needs to be higher up in the event structure.<br />
<br />
==='''3. Clarify ProductCallbackURI'''.===<br />
<br />
Possibly Clarify ProductCallbackURI should be named Clarify ProductCallbackURL. I think ''Callback'' implies it must be an URL and not just a URI. I'm a bit unclear how this would be used. I think it may need some more definition to make it useful. Does it define a server, a service, an operation ??? If I was trying to design to it I would presumably need a WSDL which presumably would need to be defined as part of the event declaration.<br />
<br />
BPEL uses the WS Addressing schema allows assignment of an wsa.EndpointReference to a PartnerLink. This allows a service endpoint to be set dynamically. ie.<br />
<br />
The wsa namespace:<br />
<pre><br />
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing"<br />
</pre><br />
<br />
defines the endpoint reference as:<br />
<pre><br />
<wsa:EndpointReference><br />
<wsa:Address>anyURI</wsa:Address><br />
<wsa:ServiceName>tns:Service</wsa:ServiceName><br />
</wsa:EndpointReference><br />
</pre><br />
<br />
This may be a better type to choose for the ProductCallbackURI. Not that the operation is not included. It is not clear if an operation can be set dynamically in BPEL. Given that an operation is genrally tied to its in and out messages, setting the operation dynamically presents problems in the general case so it seems likely that this is not supported.<br />
<br />
==='''4. Eliminate the BaseEvent structure in the ALFEventResponse message.'''===<br />
<br />
Currently the event manager sends back the EventBase structure that it received. I'm not sure if there was a purpose to this. It seems unecessary to send the whole structure and other information might be useful also like an indication that the event matched to a service flow. Probably worth a discussion before we put it to bed.<br />
<br />
== Schema 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventBase_001.xsd | ALFEventBase_001.xsd]]<br />
<br />
== WSDL 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventManager_001.WSDL | ALFEventManager_001.WSDL]]</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/architecture/ALF_Schemas_001&diff=13095ALF/architecture/ALF Schemas 0012006-10-05T21:47:23Z<p>Alf tbuss.yahoo.com: /* '''8. "Clean up" or "Gratuitously change" some names.''' */</p>
<hr />
<div>__TOC__ <br />
[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
<br />
== Introduction ==<br />
'''ALF Event Manager Schemas and WSDL version 001'''<br />
<br />
We have been reviewing the ALF Event Schema and our recommendation is that if should be flattened and simplified. Here the details of our suggestions and reasoning so far. The proposed schema is just for illustration and should not <br />
be considered final. Please respond with any comments you may have and any other suggestions about way to streamline the ALF event Schema. <br />
<br />
Here are the details of the changes which have undergone some review and will be likely be adopted. These changes are refected in the Schema and WSDL below<br />
<br />
<br />
=== '''1. Eliminate a nesting level between BasicEventType and Event Data.''' ===<br />
<br />
This serves no particular purpose except to separate it from the Context Array which is not returned on an ACK. If we eliminate the Context Array as I suggest below then this distinction is no longer required.<br />
<br />
<br />
=== '''2. Eliminate the Object Array in favor of a single ObjectType.''' ===<br />
<br />
This is in BasicEventType. It seems to me that is very rare that we will encounter a situation where a tool cannot provide a single identity to use to call back for additional information. While the array and related "relationship" attribute may be potentially powerful it would seem better relegated to a potential common vocabulary type for vocabulary or tool specific event details. The only potential issue is that removing the array from the basic event also removes it from the consideration as part of an ALF event manager dispatch rule. Currently we only use the first object in the array. This seems a reasonable price to pay The array seems somewhat complex for that purpose due to its rather arbitrary nature and, if we find we are really missing it later we have the option of extending the Basic Event to include an array of this nature in addition to the primary object.<br />
<br />
<br />
=== '''3. Eliminate the Context Array''' ===<br />
<br />
We should also merge the current user details into the BasicEventType. The context array does not seem that useful to me. It just makes the current context harder to discern. Further, it does not seem to be desirable from a security standpoint to be passing around arrays of credentials. I don't see any particular programmatic use of this feature and a simple log or a relationship store would be a better method of tracing contexts after the event. Even if it is of some practical use, that use relies on the support to tools to return the context in full in an event. This seems unlikely except by the most avid of ALF participating tools rendering it useless in the foreseeable future.<br />
<br />
=== '''4.Eliminate "InitiatingFlow" and the "nesting" attribute''' ===<br />
<br />
This is an aspect of the Context. This does not provide much useful information and again relies on all participants to behave the ALF way in order for the nesting counter to accurate. Instead provide some preceding IDs ( see below) and rely on logging. I am unclear whether it would be useful to know if the event comes from a user interaction or a service flow. It would seem to me likely that that this can be inferred from the event type and event product information and not explicit flag is required. I am unclear what you would do with it in any case. Thus I would just eliminate it.<br />
<br />
<br />
=== '''5. Add "PrecedingEvent" and "PrecedingServiceFlow" to the Basic Event Type as nillable elements.''' ===<br />
<br />
If the event is generated in the directly by a service flow then the ServiceFlow will fill these, identifying itself and the event that initiated it. Optionally an ALF compliant service may take this data and return it in any event it generates. The Source elements can be used to distinguish the cases.<br />
<br />
<br />
=== '''6. Add a ALFEventNoACK element and associated Type.''' ===<br />
<br />
Async Service flows have this type. Unfortunately the Event Manager currently dispatches using ALFEventACK which is incorrect and confusing. (Note: this change and been subsumed by the name changes describe in 8. below)<br />
<br />
<br />
=== '''7. Eliminate the use of the "mixed" attribute.''' ===<br />
<br />
I believed the used of the attribute "mixed" is incorrect. This attribute means that and element can contain both content text and other elements. I don't think that is the intent. Its use here appears to be associated with the use of an attribute which is incorrect.<br />
<br />
<br />
=== '''8. "Clean up" or "Gratuitously change" some names.''' ===<br />
<br />
The purpose is to make things feel a bit more consistent and this is really our last chance to do so.<br />
<br />
The suggested changes are as follows:<br />
<br />
The schema file will be called ALFEventBase.xsd<br />
<br />
BasicEventType -> EventBaseType<br />
<br />
EventDetailsType -> EventDetailType<br />
<br />
ToolExtensionDataType -> EventExtensionType BasicEvent -> Base EventDetails -> Detail<br />
<br />
ToolExtensionData -> Extension<br />
<br />
ALFEventACKType -> ALFEventResponseType<br />
<br />
Note: The bool value is eliminated from this since there seems little point in a boolean that will always be true if it is succesfully received but otherwise not received.<br />
<br />
ALFEvent -> EventNotice<br />
<br />
ALFEventACK -> EventNoticeResponse<br />
<br />
Note: this is to conform with the WSDL "Document Literal Wrapped" convention<br />
<br />
The following messages are added for "synchronous events" <br />
EventNoticeWithReply<br />
EventNoticeWithReplyResponse<br />
<br />
The EventNoticeWithReply operations is added to the ALFEventManager service<br />
<br />
Some new ports and corresponding bindings are added to provide the base template for Service Flow services ALFServiceFlow ALFServiceFlowWithReply (see item #11)<br />
<br />
=== '''9. The Credential element should be typed "any".''' ===<br />
It is likely that the credential element will be expressed as XML. It may be more covenient to contain such an element as an XML structure rather than by having it encoded or encapsualted as CData. may the CredentialType "any" allows it to take any of these formats.<br />
<br />
=== '''10. Added New elements to Base".''' ===<br />
''ApplicationName'' - This element distinguishes one ALF application from another. An ALF application is a set of event/service-flow relationships combined to achieve a particualr purpose. The even manager manages these sets independently allowing separate deployment and control of groups of service flows. The rules concerning how ApplicationName is used are described in Admin Service specification<br />
<br />
''Environment'' - This element indicates the environment in which the installed sytem is running. The value will be picked up from some installed configuration attribute (eg from a "properties" file or envirnonment variable). The primary purpose is for logging and to ensure that the various running components are part of the same installation environment (eg Dev, QA, Production, ProductionEastCoast). There are no standard values for this. The value is configured by the installation.<br />
<br />
=== '''11. New Ports and correspondin bindings added".''' ===<br />
Some new ports and corresponding bindings are added to provide the base template for Service Flow services. Previously A service flow had to use the Event manager port to which is subtly different from the Service flow<br />
<br />
ALFServiceFlow - the port/binding intended to be used by a normal "asynchronous" or one way service flow<br />
<br />
ALFServiceFlowWithReply - the port/binding intended to be used by a service flow that provides a response to the caller.<br />
<br />
== Additional Changes ==<br />
Listed below are some other possible simplifications and name changes. These need some some further discussion/definition before we accept them.<br />
<br />
==='''1. Combine Detail and Extension to a single xs:any element perhaps called <payload>.'''===<br />
<br />
It is not clear to me there is an advantage in keeping these separate. If there is we need to make that clear. It would seem adequate to me that a tool would declare its event data and that it will either be a pure ALF vocab structure or it will be custom or it will be some combination. Forcing the division seems like it will just make it inconvenient for tools to declare their data and will mean either misuse or no use of the ALF vocabulary.<br />
<br />
==='''2. Eliminate the "required" attributes.'''===<br />
<br />
''alfEventVersion'' on EventBaseType (nee BasicEventType) I realise the intent is to inform the recipient that the event definition is derived froma particular verision and possibly this is useful a runtime since it would possibly allow use to handle incompatible versions. This seem somewhat unlikely at this level at which it works. Maybe it is cheap enough to make that enough but something bothers me about it and I suspect that it will never be used. It is something that can be added if we ever do need it but for now it's just extra crud someone has to set before sending the event that doesn't do anything. If we have it, it seem like the schema should define the exact value it must contain.<br />
<br />
''schemaLocation'' on EventDetailType (nee EventDetailsType) and EventExtensionType (nee ToolExtensionData) I realise these attributes are supposed to point to the schema for the contained data but I'm not sure what the point of these attributes really is from a practical perspective. It seems to me nothing at runtime will look at these and validate the element content so perhaps they are just gratuitous and unecessary. Possibly there is a clearer way to do this since we do need tools to declare their events. Possibly the schema attribute, if we have it, needs to be higher up in the event structure.<br />
<br />
==='''3. Clarify ProductCallbackURI'''.===<br />
<br />
Possibly Clarify ProductCallbackURI should be named Clarify ProductCallbackURL. I think ''Callback'' implies it must be an URL and not just a URI. I'm a bit unclear how this would be used. I think it may need some more definition to make it useful. Does it define a server, a service, an operation ??? If I was trying to design to it I would presumably need a WSDL which presumably would need to be defined as part of the event declaration.<br />
<br />
BPEL uses the WS Addressing schema allows assignment of an wsa.EndpointReference to a PartnerLink. This allows a service endpoint to be set dynamically. ie.<br />
<br />
The wsa namespace:<br />
<pre><br />
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing"<br />
</pre><br />
<br />
defines the endpoint reference as:<br />
<pre><br />
<wsa:EndpointReference><br />
<wsa:Address>anyURI</wsa:Address><br />
<wsa:ServiceName>tns:Service</wsa:ServiceName><br />
</wsa:EndpointReference><br />
</pre><br />
<br />
This may be a better type to choose for the ProductCallbackURI. Not that the operation is not included. It is not clear if an operation can be set dynamically in BPEL. Given that an operation is genrally tied to its in and out messages, setting the operation dynamically presents problems in the general case so it seems likely that this is not supported.<br />
<br />
==='''4. Eliminate the BaseEvent structure in the ALFEventResponse message.'''===<br />
<br />
Currently the event manager sends back the EventBase structure that it received. I'm not sure if there was a purpose to this. It seems unecessary to send the whole structure and other information might be useful also like an indication that the event matched to a service flow. Probably worth a discussion before we put it to bed.<br />
<br />
== Schema 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventBase_001.xsd | ALFEventBase_001.xsd]]<br />
<br />
== WSDL 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventManager_001.WSDL | ALFEventManager_001.WSDL]]</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/architecture/ALF_Schemas_001&diff=13057ALF/architecture/ALF Schemas 0012006-10-05T21:18:54Z<p>Alf tbuss.yahoo.com: /* '''8. "Clean up" or "Gratuitously change" some names.''' */</p>
<hr />
<div>__TOC__ <br />
[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
<br />
== Introduction ==<br />
'''ALF Event Manager Schemas and WSDL version 001'''<br />
<br />
We have been reviewing the ALF Event Schema and our recommendation is that if should be flattened and simplified. Here the details of our suggestions and reasoning so far. The proposed schema is just for illustration and should not <br />
be considered final. Please respond with any comments you may have and any other suggestions about way to streamline the ALF event Schema. <br />
<br />
Here are the details of the changes which have undergone some review and will be likely be adopted. These changes are refected in the Schema and WSDL below<br />
<br />
<br />
=== '''1. Eliminate a nesting level between BasicEventType and Event Data.''' ===<br />
<br />
This serves no particular purpose except to separate it from the Context Array which is not returned on an ACK. If we eliminate the Context Array as I suggest below then this distinction is no longer required.<br />
<br />
<br />
=== '''2. Eliminate the Object Array in favor of a single ObjectType.''' ===<br />
<br />
This is in BasicEventType. It seems to me that is very rare that we will encounter a situation where a tool cannot provide a single identity to use to call back for additional information. While the array and related "relationship" attribute may be potentially powerful it would seem better relegated to a potential common vocabulary type for vocabulary or tool specific event details. The only potential issue is that removing the array from the basic event also removes it from the consideration as part of an ALF event manager dispatch rule. Currently we only use the first object in the array. This seems a reasonable price to pay The array seems somewhat complex for that purpose due to its rather arbitrary nature and, if we find we are really missing it later we have the option of extending the Basic Event to include an array of this nature in addition to the primary object.<br />
<br />
<br />
=== '''3. Eliminate the Context Array''' ===<br />
<br />
We should also merge the current user details into the BasicEventType. The context array does not seem that useful to me. It just makes the current context harder to discern. Further, it does not seem to be desirable from a security standpoint to be passing around arrays of credentials. I don't see any particular programmatic use of this feature and a simple log or a relationship store would be a better method of tracing contexts after the event. Even if it is of some practical use, that use relies on the support to tools to return the context in full in an event. This seems unlikely except by the most avid of ALF participating tools rendering it useless in the foreseeable future.<br />
<br />
=== '''4.Eliminate "InitiatingFlow" and the "nesting" attribute''' ===<br />
<br />
This is an aspect of the Context. This does not provide much useful information and again relies on all participants to behave the ALF way in order for the nesting counter to accurate. Instead provide some preceding IDs ( see below) and rely on logging. I am unclear whether it would be useful to know if the event comes from a user interaction or a service flow. It would seem to me likely that that this can be inferred from the event type and event product information and not explicit flag is required. I am unclear what you would do with it in any case. Thus I would just eliminate it.<br />
<br />
<br />
=== '''5. Add "PrecedingEvent" and "PrecedingServiceFlow" to the Basic Event Type as nillable elements.''' ===<br />
<br />
If the event is generated in the directly by a service flow then the ServiceFlow will fill these, identifying itself and the event that initiated it. Optionally an ALF compliant service may take this data and return it in any event it generates. The Source elements can be used to distinguish the cases.<br />
<br />
<br />
=== '''6. Add a ALFEventNoACK element and associated Type.''' ===<br />
<br />
Async Service flows have this type. Unfortunately the Event Manager currently dispatches using ALFEventACK which is incorrect and confusing. (Note: this change and been subsumed by the name changes describe in 8. below)<br />
<br />
<br />
=== '''7. Eliminate the use of the "mixed" attribute.''' ===<br />
<br />
I believed the used of the attribute "mixed" is incorrect. This attribute means that and element can contain both content text and other elements. I don't think that is the intent. Its use here appears to be associated with the use of an attribute which is incorrect.<br />
<br />
<br />
=== '''8. "Clean up" or "Gratuitously change" some names.''' ===<br />
<br />
The purpose is to make things feel a bit more consistent and this is really our last chance to do so.<br />
<br />
The suggested changes are as follows:<br />
<br />
The schema file will be called ALFEventBase.xsd<br />
<br />
BasicEventType -> EventBaseType<br />
EventDetailsType -> EventDetailType<br />
ToolExtensionDataType -> EventExtensionType BasicEvent -> Base EventDetails -> Detail ToolExtensionData -> Extension<br />
<br />
ALFEventACKType -> ALFEventResponseType<br />
Note: The bool value is eliminated from this since there seems little point in a boolean that will always be true if it is succesfully received but otherwise not received.<br />
<br />
ALFEvent -> EventNotice<br />
ALFEventACK -> EventNoticeResponse<br />
Note: this is to conform with the WSDL "Document Literal Wrapped" convention<br />
<br />
The following messages are added for "synchronous events" <br />
EventNoticeWithReply<br />
EventNoticeWithReplyResponse<br />
<br />
The EventNoticeWithReply operations is added to the ALFEventManager service<br />
<br />
Some new ports and corresponding bindings are added to provide the base template for Service Flow services ALFServiceFlow ALFServiceFlowWithReply (see item #11)<br />
<br />
=== '''9. The Credential element should be typed "any".''' ===<br />
It is likely that the credential element will be expressed as XML. It may be more covenient to contain such an element as an XML structure rather than by having it encoded or encapsualted as CData. may the CredentialType "any" allows it to take any of these formats.<br />
<br />
=== '''10. Added New elements to Base".''' ===<br />
''ApplicationName'' - This element distinguishes one ALF application from another. An ALF application is a set of event/service-flow relationships combined to achieve a particualr purpose. The even manager manages these sets independently allowing separate deployment and control of groups of service flows. The rules concerning how ApplicationName is used are described in Admin Service specification<br />
<br />
''Environment'' - This element indicates the environment in which the installed sytem is running. The value will be picked up from some installed configuration attribute (eg from a "properties" file or envirnonment variable). The primary purpose is for logging and to ensure that the various running components are part of the same installation environment (eg Dev, QA, Production, ProductionEastCoast). There are no standard values for this. The value is configured by the installation.<br />
<br />
=== '''11. New Ports and correspondin bindings added".''' ===<br />
Some new ports and corresponding bindings are added to provide the base template for Service Flow services. Previously A service flow had to use the Event manager port to which is subtly different from the Service flow<br />
<br />
ALFServiceFlow - the port/binding intended to be used by a normal "asynchronous" or one way service flow<br />
<br />
ALFServiceFlowWithReply - the port/binding intended to be used by a service flow that provides a response to the caller.<br />
<br />
== Additional Changes ==<br />
Listed below are some other possible simplifications and name changes. These need some some further discussion/definition before we accept them.<br />
<br />
==='''1. Combine Detail and Extension to a single xs:any element perhaps called <payload>.'''===<br />
<br />
It is not clear to me there is an advantage in keeping these separate. If there is we need to make that clear. It would seem adequate to me that a tool would declare its event data and that it will either be a pure ALF vocab structure or it will be custom or it will be some combination. Forcing the division seems like it will just make it inconvenient for tools to declare their data and will mean either misuse or no use of the ALF vocabulary.<br />
<br />
==='''2. Eliminate the "required" attributes.'''===<br />
<br />
''alfEventVersion'' on EventBaseType (nee BasicEventType) I realise the intent is to inform the recipient that the event definition is derived froma particular verision and possibly this is useful a runtime since it would possibly allow use to handle incompatible versions. This seem somewhat unlikely at this level at which it works. Maybe it is cheap enough to make that enough but something bothers me about it and I suspect that it will never be used. It is something that can be added if we ever do need it but for now it's just extra crud someone has to set before sending the event that doesn't do anything. If we have it, it seem like the schema should define the exact value it must contain.<br />
<br />
''schemaLocation'' on EventDetailType (nee EventDetailsType) and EventExtensionType (nee ToolExtensionData) I realise these attributes are supposed to point to the schema for the contained data but I'm not sure what the point of these attributes really is from a practical perspective. It seems to me nothing at runtime will look at these and validate the element content so perhaps they are just gratuitous and unecessary. Possibly there is a clearer way to do this since we do need tools to declare their events. Possibly the schema attribute, if we have it, needs to be higher up in the event structure.<br />
<br />
==='''3. Clarify ProductCallbackURI'''.===<br />
<br />
Possibly Clarify ProductCallbackURI should be named Clarify ProductCallbackURL. I think ''Callback'' implies it must be an URL and not just a URI. I'm a bit unclear how this would be used. I think it may need some more definition to make it useful. Does it define a server, a service, an operation ??? If I was trying to design to it I would presumably need a WSDL which presumably would need to be defined as part of the event declaration.<br />
<br />
BPEL uses the WS Addressing schema allows assignment of an wsa.EndpointReference to a PartnerLink. This allows a service endpoint to be set dynamically. ie.<br />
<br />
The wsa namespace:<br />
<pre><br />
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing"<br />
</pre><br />
<br />
defines the endpoint reference as:<br />
<pre><br />
<wsa:EndpointReference><br />
<wsa:Address>anyURI</wsa:Address><br />
<wsa:ServiceName>tns:Service</wsa:ServiceName><br />
</wsa:EndpointReference><br />
</pre><br />
<br />
This may be a better type to choose for the ProductCallbackURI. Not that the operation is not included. It is not clear if an operation can be set dynamically in BPEL. Given that an operation is genrally tied to its in and out messages, setting the operation dynamically presents problems in the general case so it seems likely that this is not supported.<br />
<br />
==='''4. Eliminate the BaseEvent structure in the ALFEventResponse message.'''===<br />
<br />
Currently the event manager sends back the EventBase structure that it received. I'm not sure if there was a purpose to this. It seems unecessary to send the whole structure and other information might be useful also like an indication that the event matched to a service flow. Probably worth a discussion before we put it to bed.<br />
<br />
== Schema 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventBase_001.xsd | ALFEventBase_001.xsd]]<br />
<br />
== WSDL 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventManager_001.WSDL | ALFEventManager_001.WSDL]]</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/architecture/ALF_Schemas_001&diff=13054ALF/architecture/ALF Schemas 0012006-10-05T21:17:24Z<p>Alf tbuss.yahoo.com: /* '''10. Added New elements to Base".''' */</p>
<hr />
<div>__TOC__ <br />
[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
<br />
== Introduction ==<br />
'''ALF Event Manager Schemas and WSDL version 001'''<br />
<br />
We have been reviewing the ALF Event Schema and our recommendation is that if should be flattened and simplified. Here the details of our suggestions and reasoning so far. The proposed schema is just for illustration and should not <br />
be considered final. Please respond with any comments you may have and any other suggestions about way to streamline the ALF event Schema. <br />
<br />
Here are the details of the changes which have undergone some review and will be likely be adopted. These changes are refected in the Schema and WSDL below<br />
<br />
<br />
=== '''1. Eliminate a nesting level between BasicEventType and Event Data.''' ===<br />
<br />
This serves no particular purpose except to separate it from the Context Array which is not returned on an ACK. If we eliminate the Context Array as I suggest below then this distinction is no longer required.<br />
<br />
<br />
=== '''2. Eliminate the Object Array in favor of a single ObjectType.''' ===<br />
<br />
This is in BasicEventType. It seems to me that is very rare that we will encounter a situation where a tool cannot provide a single identity to use to call back for additional information. While the array and related "relationship" attribute may be potentially powerful it would seem better relegated to a potential common vocabulary type for vocabulary or tool specific event details. The only potential issue is that removing the array from the basic event also removes it from the consideration as part of an ALF event manager dispatch rule. Currently we only use the first object in the array. This seems a reasonable price to pay The array seems somewhat complex for that purpose due to its rather arbitrary nature and, if we find we are really missing it later we have the option of extending the Basic Event to include an array of this nature in addition to the primary object.<br />
<br />
<br />
=== '''3. Eliminate the Context Array''' ===<br />
<br />
We should also merge the current user details into the BasicEventType. The context array does not seem that useful to me. It just makes the current context harder to discern. Further, it does not seem to be desirable from a security standpoint to be passing around arrays of credentials. I don't see any particular programmatic use of this feature and a simple log or a relationship store would be a better method of tracing contexts after the event. Even if it is of some practical use, that use relies on the support to tools to return the context in full in an event. This seems unlikely except by the most avid of ALF participating tools rendering it useless in the foreseeable future.<br />
<br />
=== '''4.Eliminate "InitiatingFlow" and the "nesting" attribute''' ===<br />
<br />
This is an aspect of the Context. This does not provide much useful information and again relies on all participants to behave the ALF way in order for the nesting counter to accurate. Instead provide some preceding IDs ( see below) and rely on logging. I am unclear whether it would be useful to know if the event comes from a user interaction or a service flow. It would seem to me likely that that this can be inferred from the event type and event product information and not explicit flag is required. I am unclear what you would do with it in any case. Thus I would just eliminate it.<br />
<br />
<br />
=== '''5. Add "PrecedingEvent" and "PrecedingServiceFlow" to the Basic Event Type as nillable elements.''' ===<br />
<br />
If the event is generated in the directly by a service flow then the ServiceFlow will fill these, identifying itself and the event that initiated it. Optionally an ALF compliant service may take this data and return it in any event it generates. The Source elements can be used to distinguish the cases.<br />
<br />
<br />
=== '''6. Add a ALFEventNoACK element and associated Type.''' ===<br />
<br />
Async Service flows have this type. Unfortunately the Event Manager currently dispatches using ALFEventACK which is incorrect and confusing. (Note: this change and been subsumed by the name changes describe in 8. below)<br />
<br />
<br />
=== '''7. Eliminate the use of the "mixed" attribute.''' ===<br />
<br />
I believed the used of the attribute "mixed" is incorrect. This attribute means that and element can contain both content text and other elements. I don't think that is the intent. Its use here appears to be associated with the use of an attribute which is incorrect.<br />
<br />
<br />
=== '''8. "Clean up" or "Gratuitously change" some names.''' ===<br />
<br />
The purpose is to make things feel a bit more consistent and this is really our last chance to do so.<br />
<br />
The suggested changes are as follows:<br />
<br />
The schema file will be called ALFEventBase.xsd<br />
<br />
BasicEventType -> EventBaseType<br />
EventDetailsType -> EventDetailType<br />
ToolExtensionDataType -> EventExtensionType BasicEvent -> Base EventDetails -> Detail ToolExtensionData -> Extension<br />
<br />
ALFEventACKType -> ALFEventResponseType<br />
Note: The bool value is eliminated from this since there seems little point in a boolean that will always be true if it is succesfully received but otherwise not received.<br />
<br />
ALFEvent -> EventNotice<br />
ALFEventACK -> EventNoticeResponse<br />
Note: this is to conform with the WSDL "Document Literal Wrapped" convention<br />
<br />
The following messages are added for "synchronous events" <br />
EventNoticeWithReply<br />
EventNoticeWithReplyResponse<br />
<br />
The EventNoticeWithReply operations is added to the ALFEventManager service<br />
<br />
Some new ports and corresponding bindings are added to provide the base template for Service Flow services ALFServiceFlow ALFServiceFlowWithReply<br />
<br />
=== '''9. The Credential element should be typed "any".''' ===<br />
It is likely that the credential element will be expressed as XML. It may be more covenient to contain such an element as an XML structure rather than by having it encoded or encapsualted as CData. may the CredentialType "any" allows it to take any of these formats.<br />
<br />
=== '''10. Added New elements to Base".''' ===<br />
''ApplicationName'' - This element distinguishes one ALF application from another. An ALF application is a set of event/service-flow relationships combined to achieve a particualr purpose. The even manager manages these sets independently allowing separate deployment and control of groups of service flows. The rules concerning how ApplicationName is used are described in Admin Service specification<br />
<br />
''Environment'' - This element indicates the environment in which the installed sytem is running. The value will be picked up from some installed configuration attribute (eg from a "properties" file or envirnonment variable). The primary purpose is for logging and to ensure that the various running components are part of the same installation environment (eg Dev, QA, Production, ProductionEastCoast). There are no standard values for this. The value is configured by the installation.<br />
<br />
=== '''11. New Ports and correspondin bindings added".''' ===<br />
Some new ports and corresponding bindings are added to provide the base template for Service Flow services. Previously A service flow had to use the Event manager port to which is subtly different from the Service flow<br />
<br />
ALFServiceFlow - the port/binding intended to be used by a normal "asynchronous" or one way service flow<br />
<br />
ALFServiceFlowWithReply - the port/binding intended to be used by a service flow that provides a response to the caller.<br />
<br />
== Additional Changes ==<br />
Listed below are some other possible simplifications and name changes. These need some some further discussion/definition before we accept them.<br />
<br />
==='''1. Combine Detail and Extension to a single xs:any element perhaps called <payload>.'''===<br />
<br />
It is not clear to me there is an advantage in keeping these separate. If there is we need to make that clear. It would seem adequate to me that a tool would declare its event data and that it will either be a pure ALF vocab structure or it will be custom or it will be some combination. Forcing the division seems like it will just make it inconvenient for tools to declare their data and will mean either misuse or no use of the ALF vocabulary.<br />
<br />
==='''2. Eliminate the "required" attributes.'''===<br />
<br />
''alfEventVersion'' on EventBaseType (nee BasicEventType) I realise the intent is to inform the recipient that the event definition is derived froma particular verision and possibly this is useful a runtime since it would possibly allow use to handle incompatible versions. This seem somewhat unlikely at this level at which it works. Maybe it is cheap enough to make that enough but something bothers me about it and I suspect that it will never be used. It is something that can be added if we ever do need it but for now it's just extra crud someone has to set before sending the event that doesn't do anything. If we have it, it seem like the schema should define the exact value it must contain.<br />
<br />
''schemaLocation'' on EventDetailType (nee EventDetailsType) and EventExtensionType (nee ToolExtensionData) I realise these attributes are supposed to point to the schema for the contained data but I'm not sure what the point of these attributes really is from a practical perspective. It seems to me nothing at runtime will look at these and validate the element content so perhaps they are just gratuitous and unecessary. Possibly there is a clearer way to do this since we do need tools to declare their events. Possibly the schema attribute, if we have it, needs to be higher up in the event structure.<br />
<br />
==='''3. Clarify ProductCallbackURI'''.===<br />
<br />
Possibly Clarify ProductCallbackURI should be named Clarify ProductCallbackURL. I think ''Callback'' implies it must be an URL and not just a URI. I'm a bit unclear how this would be used. I think it may need some more definition to make it useful. Does it define a server, a service, an operation ??? If I was trying to design to it I would presumably need a WSDL which presumably would need to be defined as part of the event declaration.<br />
<br />
BPEL uses the WS Addressing schema allows assignment of an wsa.EndpointReference to a PartnerLink. This allows a service endpoint to be set dynamically. ie.<br />
<br />
The wsa namespace:<br />
<pre><br />
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing"<br />
</pre><br />
<br />
defines the endpoint reference as:<br />
<pre><br />
<wsa:EndpointReference><br />
<wsa:Address>anyURI</wsa:Address><br />
<wsa:ServiceName>tns:Service</wsa:ServiceName><br />
</wsa:EndpointReference><br />
</pre><br />
<br />
This may be a better type to choose for the ProductCallbackURI. Not that the operation is not included. It is not clear if an operation can be set dynamically in BPEL. Given that an operation is genrally tied to its in and out messages, setting the operation dynamically presents problems in the general case so it seems likely that this is not supported.<br />
<br />
==='''4. Eliminate the BaseEvent structure in the ALFEventResponse message.'''===<br />
<br />
Currently the event manager sends back the EventBase structure that it received. I'm not sure if there was a purpose to this. It seems unecessary to send the whole structure and other information might be useful also like an indication that the event matched to a service flow. Probably worth a discussion before we put it to bed.<br />
<br />
== Schema 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventBase_001.xsd | ALFEventBase_001.xsd]]<br />
<br />
== WSDL 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventManager_001.WSDL | ALFEventManager_001.WSDL]]</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/architecture/ALF_Schemas_001&diff=12812ALF/architecture/ALF Schemas 0012006-10-05T01:01:53Z<p>Alf tbuss.yahoo.com: /* '''10. Added New elements to Base".''' */</p>
<hr />
<div>__TOC__ <br />
[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
<br />
== Introduction ==<br />
'''ALF Event Manager Schemas and WSDL version 001'''<br />
<br />
We have been reviewing the ALF Event Schema and our recommendation is that if should be flattened and simplified. Here the details of our suggestions and reasoning so far. The proposed schema is just for illustration and should not <br />
be considered final. Please respond with any comments you may have and any other suggestions about way to streamline the ALF event Schema. <br />
<br />
Here are the details of the changes which have undergone some review and will be likely be adopted. These changes are refected in the Schema and WSDL below<br />
<br />
<br />
=== '''1. Eliminate a nesting level between BasicEventType and Event Data.''' ===<br />
<br />
This serves no particular purpose except to separate it from the Context Array which is not returned on an ACK. If we eliminate the Context Array as I suggest below then this distinction is no longer required.<br />
<br />
<br />
=== '''2. Eliminate the Object Array in favor of a single ObjectType.''' ===<br />
<br />
This is in BasicEventType. It seems to me that is very rare that we will encounter a situation where a tool cannot provide a single identity to use to call back for additional information. While the array and related "relationship" attribute may be potentially powerful it would seem better relegated to a potential common vocabulary type for vocabulary or tool specific event details. The only potential issue is that removing the array from the basic event also removes it from the consideration as part of an ALF event manager dispatch rule. Currently we only use the first object in the array. This seems a reasonable price to pay The array seems somewhat complex for that purpose due to its rather arbitrary nature and, if we find we are really missing it later we have the option of extending the Basic Event to include an array of this nature in addition to the primary object.<br />
<br />
<br />
=== '''3. Eliminate the Context Array''' ===<br />
<br />
We should also merge the current user details into the BasicEventType. The context array does not seem that useful to me. It just makes the current context harder to discern. Further, it does not seem to be desirable from a security standpoint to be passing around arrays of credentials. I don't see any particular programmatic use of this feature and a simple log or a relationship store would be a better method of tracing contexts after the event. Even if it is of some practical use, that use relies on the support to tools to return the context in full in an event. This seems unlikely except by the most avid of ALF participating tools rendering it useless in the foreseeable future.<br />
<br />
=== '''4.Eliminate "InitiatingFlow" and the "nesting" attribute''' ===<br />
<br />
This is an aspect of the Context. This does not provide much useful information and again relies on all participants to behave the ALF way in order for the nesting counter to accurate. Instead provide some preceding IDs ( see below) and rely on logging. I am unclear whether it would be useful to know if the event comes from a user interaction or a service flow. It would seem to me likely that that this can be inferred from the event type and event product information and not explicit flag is required. I am unclear what you would do with it in any case. Thus I would just eliminate it.<br />
<br />
<br />
=== '''5. Add "PrecedingEvent" and "PrecedingServiceFlow" to the Basic Event Type as nillable elements.''' ===<br />
<br />
If the event is generated in the directly by a service flow then the ServiceFlow will fill these, identifying itself and the event that initiated it. Optionally an ALF compliant service may take this data and return it in any event it generates. The Source elements can be used to distinguish the cases.<br />
<br />
<br />
=== '''6. Add a ALFEventNoACK element and associated Type.''' ===<br />
<br />
Async Service flows have this type. Unfortunately the Event Manager currently dispatches using ALFEventACK which is incorrect and confusing. (Note: this change and been subsumed by the name changes describe in 8. below)<br />
<br />
<br />
=== '''7. Eliminate the use of the "mixed" attribute.''' ===<br />
<br />
I believed the used of the attribute "mixed" is incorrect. This attribute means that and element can contain both content text and other elements. I don't think that is the intent. Its use here appears to be associated with the use of an attribute which is incorrect.<br />
<br />
<br />
=== '''8. "Clean up" or "Gratuitously change" some names.''' ===<br />
<br />
The purpose is to make things feel a bit more consistent and this is really our last chance to do so.<br />
<br />
The suggested changes are as follows:<br />
<br />
The schema file will be called ALFEventBase.xsd<br />
<br />
BasicEventType -> EventBaseType<br />
EventDetailsType -> EventDetailType<br />
ToolExtensionDataType -> EventExtensionType BasicEvent -> Base EventDetails -> Detail ToolExtensionData -> Extension<br />
<br />
ALFEventACKType -> ALFEventResponseType<br />
Note: The bool value is eliminated from this since there seems little point in a boolean that will always be true if it is succesfully received but otherwise not received.<br />
<br />
ALFEvent -> EventNotice<br />
ALFEventACK -> EventNoticeResponse<br />
Note: this is to conform with the WSDL "Document Literal Wrapped" convention<br />
<br />
The following messages are added for "synchronous events" <br />
EventNoticeWithReply<br />
EventNoticeWithReplyResponse<br />
<br />
The EventNoticeWithReply operations is added to the ALFEventManager service<br />
<br />
Some new ports and corresponding bindings are added to provide the base template for Service Flow services ALFServiceFlow ALFServiceFlowWithReply<br />
<br />
=== '''9. The Credential element should be typed "any".''' ===<br />
It is likely that the credential element will be expressed as XML. It may be more covenient to contain such an element as an XML structure rather than by having it encoded or encapsualted as CData. may the CredentialType "any" allows it to take any of these formats.<br />
<br />
=== '''10. Added New elements to Base".''' ===<br />
''ApplicationName'' - This element distinguishes one ALF application from another. An ALF application is a set of event/service-flow relationships combined to achieve a particualr purpose. The even manager manages these sets independently allowing separate deployment and control of groups of service flows. The rules concerning how ApplicationName is used are described in Admin Service specification<br />
<br />
''Environment'' - This element indicates the environment in which the installed sytem is running. The value will be picked up from some installed configuration attribute (eg from a "properties" file or envirnonment variable). The primary purpose is for logging and to ensure that the various running components are part of the same installation environment (eg Dev, QA, Production, ProductionEastCoast). There are no standard values for this. The value is configured by the installation.<br />
<br />
== Additional Changes ==<br />
Listed below are some other possible simplifications and name changes. These need some some further discussion/definition before we accept them.<br />
<br />
==='''1. Combine Detail and Extension to a single xs:any element perhaps called <payload>.'''===<br />
<br />
It is not clear to me there is an advantage in keeping these separate. If there is we need to make that clear. It would seem adequate to me that a tool would declare its event data and that it will either be a pure ALF vocab structure or it will be custom or it will be some combination. Forcing the division seems like it will just make it inconvenient for tools to declare their data and will mean either misuse or no use of the ALF vocabulary.<br />
<br />
==='''2. Eliminate the "required" attributes.'''===<br />
<br />
''alfEventVersion'' on EventBaseType (nee BasicEventType) I realise the intent is to inform the recipient that the event definition is derived froma particular verision and possibly this is useful a runtime since it would possibly allow use to handle incompatible versions. This seem somewhat unlikely at this level at which it works. Maybe it is cheap enough to make that enough but something bothers me about it and I suspect that it will never be used. It is something that can be added if we ever do need it but for now it's just extra crud someone has to set before sending the event that doesn't do anything. If we have it, it seem like the schema should define the exact value it must contain.<br />
<br />
''schemaLocation'' on EventDetailType (nee EventDetailsType) and EventExtensionType (nee ToolExtensionData) I realise these attributes are supposed to point to the schema for the contained data but I'm not sure what the point of these attributes really is from a practical perspective. It seems to me nothing at runtime will look at these and validate the element content so perhaps they are just gratuitous and unecessary. Possibly there is a clearer way to do this since we do need tools to declare their events. Possibly the schema attribute, if we have it, needs to be higher up in the event structure.<br />
<br />
==='''3. Clarify ProductCallbackURI'''.===<br />
<br />
Possibly Clarify ProductCallbackURI should be named Clarify ProductCallbackURL. I think ''Callback'' implies it must be an URL and not just a URI. I'm a bit unclear how this would be used. I think it may need some more definition to make it useful. Does it define a server, a service, an operation ??? If I was trying to design to it I would presumably need a WSDL which presumably would need to be defined as part of the event declaration.<br />
<br />
BPEL uses the WS Addressing schema allows assignment of an wsa.EndpointReference to a PartnerLink. This allows a service endpoint to be set dynamically. ie.<br />
<br />
The wsa namespace:<br />
<pre><br />
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing"<br />
</pre><br />
<br />
defines the endpoint reference as:<br />
<pre><br />
<wsa:EndpointReference><br />
<wsa:Address>anyURI</wsa:Address><br />
<wsa:ServiceName>tns:Service</wsa:ServiceName><br />
</wsa:EndpointReference><br />
</pre><br />
<br />
This may be a better type to choose for the ProductCallbackURI. Not that the operation is not included. It is not clear if an operation can be set dynamically in BPEL. Given that an operation is genrally tied to its in and out messages, setting the operation dynamically presents problems in the general case so it seems likely that this is not supported.<br />
<br />
==='''4. Eliminate the BaseEvent structure in the ALFEventResponse message.'''===<br />
<br />
Currently the event manager sends back the EventBase structure that it received. I'm not sure if there was a purpose to this. It seems unecessary to send the whole structure and other information might be useful also like an indication that the event matched to a service flow. Probably worth a discussion before we put it to bed.<br />
<br />
== Schema 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventBase_001.xsd | ALFEventBase_001.xsd]]<br />
<br />
== WSDL 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventManager_001.WSDL | ALFEventManager_001.WSDL]]</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/architecture/ALF_Schemas_001&diff=12797ALF/architecture/ALF Schemas 0012006-10-05T00:32:26Z<p>Alf tbuss.yahoo.com: /* '''10. Added New elements to Base".''' */</p>
<hr />
<div>__TOC__ <br />
[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
<br />
== Introduction ==<br />
'''ALF Event Manager Schemas and WSDL version 001'''<br />
<br />
We have been reviewing the ALF Event Schema and our recommendation is that if should be flattened and simplified. Here the details of our suggestions and reasoning so far. The proposed schema is just for illustration and should not <br />
be considered final. Please respond with any comments you may have and any other suggestions about way to streamline the ALF event Schema. <br />
<br />
Here are the details of the changes which have undergone some review and will be likely be adopted. These changes are refected in the Schema and WSDL below<br />
<br />
<br />
=== '''1. Eliminate a nesting level between BasicEventType and Event Data.''' ===<br />
<br />
This serves no particular purpose except to separate it from the Context Array which is not returned on an ACK. If we eliminate the Context Array as I suggest below then this distinction is no longer required.<br />
<br />
<br />
=== '''2. Eliminate the Object Array in favor of a single ObjectType.''' ===<br />
<br />
This is in BasicEventType. It seems to me that is very rare that we will encounter a situation where a tool cannot provide a single identity to use to call back for additional information. While the array and related "relationship" attribute may be potentially powerful it would seem better relegated to a potential common vocabulary type for vocabulary or tool specific event details. The only potential issue is that removing the array from the basic event also removes it from the consideration as part of an ALF event manager dispatch rule. Currently we only use the first object in the array. This seems a reasonable price to pay The array seems somewhat complex for that purpose due to its rather arbitrary nature and, if we find we are really missing it later we have the option of extending the Basic Event to include an array of this nature in addition to the primary object.<br />
<br />
<br />
=== '''3. Eliminate the Context Array''' ===<br />
<br />
We should also merge the current user details into the BasicEventType. The context array does not seem that useful to me. It just makes the current context harder to discern. Further, it does not seem to be desirable from a security standpoint to be passing around arrays of credentials. I don't see any particular programmatic use of this feature and a simple log or a relationship store would be a better method of tracing contexts after the event. Even if it is of some practical use, that use relies on the support to tools to return the context in full in an event. This seems unlikely except by the most avid of ALF participating tools rendering it useless in the foreseeable future.<br />
<br />
=== '''4.Eliminate "InitiatingFlow" and the "nesting" attribute''' ===<br />
<br />
This is an aspect of the Context. This does not provide much useful information and again relies on all participants to behave the ALF way in order for the nesting counter to accurate. Instead provide some preceding IDs ( see below) and rely on logging. I am unclear whether it would be useful to know if the event comes from a user interaction or a service flow. It would seem to me likely that that this can be inferred from the event type and event product information and not explicit flag is required. I am unclear what you would do with it in any case. Thus I would just eliminate it.<br />
<br />
<br />
=== '''5. Add "PrecedingEvent" and "PrecedingServiceFlow" to the Basic Event Type as nillable elements.''' ===<br />
<br />
If the event is generated in the directly by a service flow then the ServiceFlow will fill these, identifying itself and the event that initiated it. Optionally an ALF compliant service may take this data and return it in any event it generates. The Source elements can be used to distinguish the cases.<br />
<br />
<br />
=== '''6. Add a ALFEventNoACK element and associated Type.''' ===<br />
<br />
Async Service flows have this type. Unfortunately the Event Manager currently dispatches using ALFEventACK which is incorrect and confusing. (Note: this change and been subsumed by the name changes describe in 8. below)<br />
<br />
<br />
=== '''7. Eliminate the use of the "mixed" attribute.''' ===<br />
<br />
I believed the used of the attribute "mixed" is incorrect. This attribute means that and element can contain both content text and other elements. I don't think that is the intent. Its use here appears to be associated with the use of an attribute which is incorrect.<br />
<br />
<br />
=== '''8. "Clean up" or "Gratuitously change" some names.''' ===<br />
<br />
The purpose is to make things feel a bit more consistent and this is really our last chance to do so.<br />
<br />
The suggested changes are as follows:<br />
<br />
The schema file will be called ALFEventBase.xsd<br />
<br />
BasicEventType -> EventBaseType<br />
EventDetailsType -> EventDetailType<br />
ToolExtensionDataType -> EventExtensionType BasicEvent -> Base EventDetails -> Detail ToolExtensionData -> Extension<br />
<br />
ALFEventACKType -> ALFEventResponseType<br />
Note: The bool value is eliminated from this since there seems little point in a boolean that will always be true if it is succesfully received but otherwise not received.<br />
<br />
ALFEvent -> EventNotice<br />
ALFEventACK -> EventNoticeResponse<br />
Note: this is to conform with the WSDL "Document Literal Wrapped" convention<br />
<br />
The following messages are added for "synchronous events" <br />
EventNoticeWithReply<br />
EventNoticeWithReplyResponse<br />
<br />
The EventNoticeWithReply operations is added to the ALFEventManager service<br />
<br />
Some new ports and corresponding bindings are added to provide the base template for Service Flow services ALFServiceFlow ALFServiceFlowWithReply<br />
<br />
=== '''9. The Credential element should be typed "any".''' ===<br />
It is likely that the credential element will be expressed as XML. It may be more covenient to contain such an element as an XML structure rather than by having it encoded or encapsualted as CData. may the CredentialType "any" allows it to take any of these formats.<br />
<br />
=== '''10. Added New elements to Base".''' ===<br />
''ApplicationName''<br />
''Environment''<br />
<br />
== Additional Changes ==<br />
Listed below are some other possible simplifications and name changes. These need some some further discussion/definition before we accept them.<br />
<br />
==='''1. Combine Detail and Extension to a single xs:any element perhaps called <payload>.'''===<br />
<br />
It is not clear to me there is an advantage in keeping these separate. If there is we need to make that clear. It would seem adequate to me that a tool would declare its event data and that it will either be a pure ALF vocab structure or it will be custom or it will be some combination. Forcing the division seems like it will just make it inconvenient for tools to declare their data and will mean either misuse or no use of the ALF vocabulary.<br />
<br />
==='''2. Eliminate the "required" attributes.'''===<br />
<br />
''alfEventVersion'' on EventBaseType (nee BasicEventType) I realise the intent is to inform the recipient that the event definition is derived froma particular verision and possibly this is useful a runtime since it would possibly allow use to handle incompatible versions. This seem somewhat unlikely at this level at which it works. Maybe it is cheap enough to make that enough but something bothers me about it and I suspect that it will never be used. It is something that can be added if we ever do need it but for now it's just extra crud someone has to set before sending the event that doesn't do anything. If we have it, it seem like the schema should define the exact value it must contain.<br />
<br />
''schemaLocation'' on EventDetailType (nee EventDetailsType) and EventExtensionType (nee ToolExtensionData) I realise these attributes are supposed to point to the schema for the contained data but I'm not sure what the point of these attributes really is from a practical perspective. It seems to me nothing at runtime will look at these and validate the element content so perhaps they are just gratuitous and unecessary. Possibly there is a clearer way to do this since we do need tools to declare their events. Possibly the schema attribute, if we have it, needs to be higher up in the event structure.<br />
<br />
==='''3. Clarify ProductCallbackURI'''.===<br />
<br />
Possibly Clarify ProductCallbackURI should be named Clarify ProductCallbackURL. I think ''Callback'' implies it must be an URL and not just a URI. I'm a bit unclear how this would be used. I think it may need some more definition to make it useful. Does it define a server, a service, an operation ??? If I was trying to design to it I would presumably need a WSDL which presumably would need to be defined as part of the event declaration.<br />
<br />
BPEL uses the WS Addressing schema allows assignment of an wsa.EndpointReference to a PartnerLink. This allows a service endpoint to be set dynamically. ie.<br />
<br />
The wsa namespace:<br />
<pre><br />
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing"<br />
</pre><br />
<br />
defines the endpoint reference as:<br />
<pre><br />
<wsa:EndpointReference><br />
<wsa:Address>anyURI</wsa:Address><br />
<wsa:ServiceName>tns:Service</wsa:ServiceName><br />
</wsa:EndpointReference><br />
</pre><br />
<br />
This may be a better type to choose for the ProductCallbackURI. Not that the operation is not included. It is not clear if an operation can be set dynamically in BPEL. Given that an operation is genrally tied to its in and out messages, setting the operation dynamically presents problems in the general case so it seems likely that this is not supported.<br />
<br />
==='''4. Eliminate the BaseEvent structure in the ALFEventResponse message.'''===<br />
<br />
Currently the event manager sends back the EventBase structure that it received. I'm not sure if there was a purpose to this. It seems unecessary to send the whole structure and other information might be useful also like an indication that the event matched to a service flow. Probably worth a discussion before we put it to bed.<br />
<br />
== Schema 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventBase_001.xsd | ALFEventBase_001.xsd]]<br />
<br />
== WSDL 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventManager_001.WSDL | ALFEventManager_001.WSDL]]</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/architecture/ALF_Schemas_001&diff=12796ALF/architecture/ALF Schemas 0012006-10-05T00:31:39Z<p>Alf tbuss.yahoo.com: /* '''9. The Credential element should be typed "any".''' */</p>
<hr />
<div>__TOC__ <br />
[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
<br />
== Introduction ==<br />
'''ALF Event Manager Schemas and WSDL version 001'''<br />
<br />
We have been reviewing the ALF Event Schema and our recommendation is that if should be flattened and simplified. Here the details of our suggestions and reasoning so far. The proposed schema is just for illustration and should not <br />
be considered final. Please respond with any comments you may have and any other suggestions about way to streamline the ALF event Schema. <br />
<br />
Here are the details of the changes which have undergone some review and will be likely be adopted. These changes are refected in the Schema and WSDL below<br />
<br />
<br />
=== '''1. Eliminate a nesting level between BasicEventType and Event Data.''' ===<br />
<br />
This serves no particular purpose except to separate it from the Context Array which is not returned on an ACK. If we eliminate the Context Array as I suggest below then this distinction is no longer required.<br />
<br />
<br />
=== '''2. Eliminate the Object Array in favor of a single ObjectType.''' ===<br />
<br />
This is in BasicEventType. It seems to me that is very rare that we will encounter a situation where a tool cannot provide a single identity to use to call back for additional information. While the array and related "relationship" attribute may be potentially powerful it would seem better relegated to a potential common vocabulary type for vocabulary or tool specific event details. The only potential issue is that removing the array from the basic event also removes it from the consideration as part of an ALF event manager dispatch rule. Currently we only use the first object in the array. This seems a reasonable price to pay The array seems somewhat complex for that purpose due to its rather arbitrary nature and, if we find we are really missing it later we have the option of extending the Basic Event to include an array of this nature in addition to the primary object.<br />
<br />
<br />
=== '''3. Eliminate the Context Array''' ===<br />
<br />
We should also merge the current user details into the BasicEventType. The context array does not seem that useful to me. It just makes the current context harder to discern. Further, it does not seem to be desirable from a security standpoint to be passing around arrays of credentials. I don't see any particular programmatic use of this feature and a simple log or a relationship store would be a better method of tracing contexts after the event. Even if it is of some practical use, that use relies on the support to tools to return the context in full in an event. This seems unlikely except by the most avid of ALF participating tools rendering it useless in the foreseeable future.<br />
<br />
=== '''4.Eliminate "InitiatingFlow" and the "nesting" attribute''' ===<br />
<br />
This is an aspect of the Context. This does not provide much useful information and again relies on all participants to behave the ALF way in order for the nesting counter to accurate. Instead provide some preceding IDs ( see below) and rely on logging. I am unclear whether it would be useful to know if the event comes from a user interaction or a service flow. It would seem to me likely that that this can be inferred from the event type and event product information and not explicit flag is required. I am unclear what you would do with it in any case. Thus I would just eliminate it.<br />
<br />
<br />
=== '''5. Add "PrecedingEvent" and "PrecedingServiceFlow" to the Basic Event Type as nillable elements.''' ===<br />
<br />
If the event is generated in the directly by a service flow then the ServiceFlow will fill these, identifying itself and the event that initiated it. Optionally an ALF compliant service may take this data and return it in any event it generates. The Source elements can be used to distinguish the cases.<br />
<br />
<br />
=== '''6. Add a ALFEventNoACK element and associated Type.''' ===<br />
<br />
Async Service flows have this type. Unfortunately the Event Manager currently dispatches using ALFEventACK which is incorrect and confusing. (Note: this change and been subsumed by the name changes describe in 8. below)<br />
<br />
<br />
=== '''7. Eliminate the use of the "mixed" attribute.''' ===<br />
<br />
I believed the used of the attribute "mixed" is incorrect. This attribute means that and element can contain both content text and other elements. I don't think that is the intent. Its use here appears to be associated with the use of an attribute which is incorrect.<br />
<br />
<br />
=== '''8. "Clean up" or "Gratuitously change" some names.''' ===<br />
<br />
The purpose is to make things feel a bit more consistent and this is really our last chance to do so.<br />
<br />
The suggested changes are as follows:<br />
<br />
The schema file will be called ALFEventBase.xsd<br />
<br />
BasicEventType -> EventBaseType<br />
EventDetailsType -> EventDetailType<br />
ToolExtensionDataType -> EventExtensionType BasicEvent -> Base EventDetails -> Detail ToolExtensionData -> Extension<br />
<br />
ALFEventACKType -> ALFEventResponseType<br />
Note: The bool value is eliminated from this since there seems little point in a boolean that will always be true if it is succesfully received but otherwise not received.<br />
<br />
ALFEvent -> EventNotice<br />
ALFEventACK -> EventNoticeResponse<br />
Note: this is to conform with the WSDL "Document Literal Wrapped" convention<br />
<br />
The following messages are added for "synchronous events" <br />
EventNoticeWithReply<br />
EventNoticeWithReplyResponse<br />
<br />
The EventNoticeWithReply operations is added to the ALFEventManager service<br />
<br />
Some new ports and corresponding bindings are added to provide the base template for Service Flow services ALFServiceFlow ALFServiceFlowWithReply<br />
<br />
=== '''9. The Credential element should be typed "any".''' ===<br />
It is likely that the credential element will be expressed as XML. It may be more covenient to contain such an element as an XML structure rather than by having it encoded or encapsualted as CData. may the CredentialType "any" allows it to take any of these formats.<br />
<br />
=== '''10. Added New elements to Base".''' ===<br />
'''ApplicationName'''<br />
'''Environment'''<br />
<br />
== Additional Changes ==<br />
Listed below are some other possible simplifications and name changes. These need some some further discussion/definition before we accept them.<br />
<br />
==='''1. Combine Detail and Extension to a single xs:any element perhaps called <payload>.'''===<br />
<br />
It is not clear to me there is an advantage in keeping these separate. If there is we need to make that clear. It would seem adequate to me that a tool would declare its event data and that it will either be a pure ALF vocab structure or it will be custom or it will be some combination. Forcing the division seems like it will just make it inconvenient for tools to declare their data and will mean either misuse or no use of the ALF vocabulary.<br />
<br />
==='''2. Eliminate the "required" attributes.'''===<br />
<br />
''alfEventVersion'' on EventBaseType (nee BasicEventType) I realise the intent is to inform the recipient that the event definition is derived froma particular verision and possibly this is useful a runtime since it would possibly allow use to handle incompatible versions. This seem somewhat unlikely at this level at which it works. Maybe it is cheap enough to make that enough but something bothers me about it and I suspect that it will never be used. It is something that can be added if we ever do need it but for now it's just extra crud someone has to set before sending the event that doesn't do anything. If we have it, it seem like the schema should define the exact value it must contain.<br />
<br />
''schemaLocation'' on EventDetailType (nee EventDetailsType) and EventExtensionType (nee ToolExtensionData) I realise these attributes are supposed to point to the schema for the contained data but I'm not sure what the point of these attributes really is from a practical perspective. It seems to me nothing at runtime will look at these and validate the element content so perhaps they are just gratuitous and unecessary. Possibly there is a clearer way to do this since we do need tools to declare their events. Possibly the schema attribute, if we have it, needs to be higher up in the event structure.<br />
<br />
==='''3. Clarify ProductCallbackURI'''.===<br />
<br />
Possibly Clarify ProductCallbackURI should be named Clarify ProductCallbackURL. I think ''Callback'' implies it must be an URL and not just a URI. I'm a bit unclear how this would be used. I think it may need some more definition to make it useful. Does it define a server, a service, an operation ??? If I was trying to design to it I would presumably need a WSDL which presumably would need to be defined as part of the event declaration.<br />
<br />
BPEL uses the WS Addressing schema allows assignment of an wsa.EndpointReference to a PartnerLink. This allows a service endpoint to be set dynamically. ie.<br />
<br />
The wsa namespace:<br />
<pre><br />
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing"<br />
</pre><br />
<br />
defines the endpoint reference as:<br />
<pre><br />
<wsa:EndpointReference><br />
<wsa:Address>anyURI</wsa:Address><br />
<wsa:ServiceName>tns:Service</wsa:ServiceName><br />
</wsa:EndpointReference><br />
</pre><br />
<br />
This may be a better type to choose for the ProductCallbackURI. Not that the operation is not included. It is not clear if an operation can be set dynamically in BPEL. Given that an operation is genrally tied to its in and out messages, setting the operation dynamically presents problems in the general case so it seems likely that this is not supported.<br />
<br />
==='''4. Eliminate the BaseEvent structure in the ALFEventResponse message.'''===<br />
<br />
Currently the event manager sends back the EventBase structure that it received. I'm not sure if there was a purpose to this. It seems unecessary to send the whole structure and other information might be useful also like an indication that the event matched to a service flow. Probably worth a discussion before we put it to bed.<br />
<br />
== Schema 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventBase_001.xsd | ALFEventBase_001.xsd]]<br />
<br />
== WSDL 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventManager_001.WSDL | ALFEventManager_001.WSDL]]</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/architecture/ALF_Schemas_001&diff=12781ALF/architecture/ALF Schemas 0012006-10-05T00:12:04Z<p>Alf tbuss.yahoo.com: /* Introduction */</p>
<hr />
<div>__TOC__ <br />
[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
<br />
== Introduction ==<br />
'''ALF Event Manager Schemas and WSDL version 001'''<br />
<br />
We have been reviewing the ALF Event Schema and our recommendation is that if should be flattened and simplified. Here the details of our suggestions and reasoning so far. The proposed schema is just for illustration and should not <br />
be considered final. Please respond with any comments you may have and any other suggestions about way to streamline the ALF event Schema. <br />
<br />
Here are the details of the changes which have undergone some review and will be likely be adopted. These changes are refected in the Schema and WSDL below<br />
<br />
<br />
=== '''1. Eliminate a nesting level between BasicEventType and Event Data.''' ===<br />
<br />
This serves no particular purpose except to separate it from the Context Array which is not returned on an ACK. If we eliminate the Context Array as I suggest below then this distinction is no longer required.<br />
<br />
<br />
=== '''2. Eliminate the Object Array in favor of a single ObjectType.''' ===<br />
<br />
This is in BasicEventType. It seems to me that is very rare that we will encounter a situation where a tool cannot provide a single identity to use to call back for additional information. While the array and related "relationship" attribute may be potentially powerful it would seem better relegated to a potential common vocabulary type for vocabulary or tool specific event details. The only potential issue is that removing the array from the basic event also removes it from the consideration as part of an ALF event manager dispatch rule. Currently we only use the first object in the array. This seems a reasonable price to pay The array seems somewhat complex for that purpose due to its rather arbitrary nature and, if we find we are really missing it later we have the option of extending the Basic Event to include an array of this nature in addition to the primary object.<br />
<br />
<br />
=== '''3. Eliminate the Context Array''' ===<br />
<br />
We should also merge the current user details into the BasicEventType. The context array does not seem that useful to me. It just makes the current context harder to discern. Further, it does not seem to be desirable from a security standpoint to be passing around arrays of credentials. I don't see any particular programmatic use of this feature and a simple log or a relationship store would be a better method of tracing contexts after the event. Even if it is of some practical use, that use relies on the support to tools to return the context in full in an event. This seems unlikely except by the most avid of ALF participating tools rendering it useless in the foreseeable future.<br />
<br />
=== '''4.Eliminate "InitiatingFlow" and the "nesting" attribute''' ===<br />
<br />
This is an aspect of the Context. This does not provide much useful information and again relies on all participants to behave the ALF way in order for the nesting counter to accurate. Instead provide some preceding IDs ( see below) and rely on logging. I am unclear whether it would be useful to know if the event comes from a user interaction or a service flow. It would seem to me likely that that this can be inferred from the event type and event product information and not explicit flag is required. I am unclear what you would do with it in any case. Thus I would just eliminate it.<br />
<br />
<br />
=== '''5. Add "PrecedingEvent" and "PrecedingServiceFlow" to the Basic Event Type as nillable elements.''' ===<br />
<br />
If the event is generated in the directly by a service flow then the ServiceFlow will fill these, identifying itself and the event that initiated it. Optionally an ALF compliant service may take this data and return it in any event it generates. The Source elements can be used to distinguish the cases.<br />
<br />
<br />
=== '''6. Add a ALFEventNoACK element and associated Type.''' ===<br />
<br />
Async Service flows have this type. Unfortunately the Event Manager currently dispatches using ALFEventACK which is incorrect and confusing. (Note: this change and been subsumed by the name changes describe in 8. below)<br />
<br />
<br />
=== '''7. Eliminate the use of the "mixed" attribute.''' ===<br />
<br />
I believed the used of the attribute "mixed" is incorrect. This attribute means that and element can contain both content text and other elements. I don't think that is the intent. Its use here appears to be associated with the use of an attribute which is incorrect.<br />
<br />
<br />
=== '''8. "Clean up" or "Gratuitously change" some names.''' ===<br />
<br />
The purpose is to make things feel a bit more consistent and this is really our last chance to do so.<br />
<br />
The suggested changes are as follows:<br />
<br />
The schema file will be called ALFEventBase.xsd<br />
<br />
BasicEventType -> EventBaseType<br />
EventDetailsType -> EventDetailType<br />
ToolExtensionDataType -> EventExtensionType BasicEvent -> Base EventDetails -> Detail ToolExtensionData -> Extension<br />
<br />
ALFEventACKType -> ALFEventResponseType<br />
Note: The bool value is eliminated from this since there seems little point in a boolean that will always be true if it is succesfully received but otherwise not received.<br />
<br />
ALFEvent -> EventNotice<br />
ALFEventACK -> EventNoticeResponse<br />
Note: this is to conform with the WSDL "Document Literal Wrapped" convention<br />
<br />
The following messages are added for "synchronous events" <br />
EventNoticeWithReply<br />
EventNoticeWithReplyResponse<br />
<br />
The EventNoticeWithReply operations is added to the ALFEventManager service<br />
<br />
Some new ports and corresponding bindings are added to provide the base template for Service Flow services ALFServiceFlow ALFServiceFlowWithReply<br />
<br />
=== '''9. The Credential element should be typed "any".''' ===<br />
It is likely that the credential element will be expressed as XML. It may be more covenient to contain such an element as an XML structure rather than by having it encoded or encapsualted as CData. may the CredentialType "any" allows it to take any of these formats<br />
<br />
== Additional Changes ==<br />
Listed below are some other possible simplifications and name changes. These need some some further discussion/definition before we accept them.<br />
<br />
==='''1. Combine Detail and Extension to a single xs:any element perhaps called <payload>.'''===<br />
<br />
It is not clear to me there is an advantage in keeping these separate. If there is we need to make that clear. It would seem adequate to me that a tool would declare its event data and that it will either be a pure ALF vocab structure or it will be custom or it will be some combination. Forcing the division seems like it will just make it inconvenient for tools to declare their data and will mean either misuse or no use of the ALF vocabulary.<br />
<br />
==='''2. Eliminate the "required" attributes.'''===<br />
<br />
''alfEventVersion'' on EventBaseType (nee BasicEventType) I realise the intent is to inform the recipient that the event definition is derived froma particular verision and possibly this is useful a runtime since it would possibly allow use to handle incompatible versions. This seem somewhat unlikely at this level at which it works. Maybe it is cheap enough to make that enough but something bothers me about it and I suspect that it will never be used. It is something that can be added if we ever do need it but for now it's just extra crud someone has to set before sending the event that doesn't do anything. If we have it, it seem like the schema should define the exact value it must contain.<br />
<br />
''schemaLocation'' on EventDetailType (nee EventDetailsType) and EventExtensionType (nee ToolExtensionData) I realise these attributes are supposed to point to the schema for the contained data but I'm not sure what the point of these attributes really is from a practical perspective. It seems to me nothing at runtime will look at these and validate the element content so perhaps they are just gratuitous and unecessary. Possibly there is a clearer way to do this since we do need tools to declare their events. Possibly the schema attribute, if we have it, needs to be higher up in the event structure.<br />
<br />
==='''3. Clarify ProductCallbackURI'''.===<br />
<br />
Possibly Clarify ProductCallbackURI should be named Clarify ProductCallbackURL. I think ''Callback'' implies it must be an URL and not just a URI. I'm a bit unclear how this would be used. I think it may need some more definition to make it useful. Does it define a server, a service, an operation ??? If I was trying to design to it I would presumably need a WSDL which presumably would need to be defined as part of the event declaration.<br />
<br />
BPEL uses the WS Addressing schema allows assignment of an wsa.EndpointReference to a PartnerLink. This allows a service endpoint to be set dynamically. ie.<br />
<br />
The wsa namespace:<br />
<pre><br />
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing"<br />
</pre><br />
<br />
defines the endpoint reference as:<br />
<pre><br />
<wsa:EndpointReference><br />
<wsa:Address>anyURI</wsa:Address><br />
<wsa:ServiceName>tns:Service</wsa:ServiceName><br />
</wsa:EndpointReference><br />
</pre><br />
<br />
This may be a better type to choose for the ProductCallbackURI. Not that the operation is not included. It is not clear if an operation can be set dynamically in BPEL. Given that an operation is genrally tied to its in and out messages, setting the operation dynamically presents problems in the general case so it seems likely that this is not supported.<br />
<br />
==='''4. Eliminate the BaseEvent structure in the ALFEventResponse message.'''===<br />
<br />
Currently the event manager sends back the EventBase structure that it received. I'm not sure if there was a purpose to this. It seems unecessary to send the whole structure and other information might be useful also like an indication that the event matched to a service flow. Probably worth a discussion before we put it to bed.<br />
<br />
== Schema 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventBase_001.xsd | ALFEventBase_001.xsd]]<br />
<br />
== WSDL 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventManager_001.WSDL | ALFEventManager_001.WSDL]]</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/Build_Vocabulary/Schema&diff=12778ALF/Build Vocabulary/Schema2006-10-05T00:09:24Z<p>Alf tbuss.yahoo.com: </p>
<hr />
<div>[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
== Build Vocabulary Schema ==<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8" ?><br />
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"<br />
xmlns="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
xmlns:tns="http://www.eclipse.org/alf/schema/alfcommonvocabulary/v0.00"<br />
targetNamespace="http://www.eclipse.org/alf/schema/buildvocabulary/v0.00"<br />
elementFormDefault="qualified" attributeFormDefault="unqualified"><br />
<xsd:annotation><br />
<xsd:documentation><br />
WARNING! PRELIMINARY FOR COMMENT ONLY<br />
Copyright Notice The material in this document is Copyright<br />
(c) Catalyst Systems Corporation and others, 2005,2006 Terms and<br />
Conditions: The Eclipse Foundation makes available all<br />
content in this document ("Content"). Unless otherwise<br />
indicated below, the Content is provided to you under the<br />
terms and conditions of the Eclipse Public License Version<br />
1.0 ("EPL"). A copy of the EPL is available at<br />
http://www.eclipse.org/legal/epl-v10.html. For purposes of<br />
the EPL, "Program" will mean the Content. If you did not<br />
receive this Content directly from the Eclipse Foundation,<br />
the Content is being redistributed by another party<br />
("Redistributor") and different terms and conditions may<br />
apply to your use of any object code in the Content. Check<br />
the Redistributor's license that was provided with the<br />
Content. If you did not receive any such license, contact<br />
the Redistributor. Unless otherwise indicated below, the<br />
terms and conditions of the EPL still apply to the Content.<br />
</xsd:documentation><br />
</xsd:annotation><br />
<br />
<xsd:complexType name="ReportTypeType"><br />
<xsd:sequence><br />
<xsd:element name="ReportType" type="xsd:string" /><br />
<xsd:element name="Report" type="xsd:string" /><br />
</xsd:sequence> <br />
</xsd:complexType> <br />
<br />
<xsd:complexType name="BuildResultsType"><br />
<xsd:sequence><br />
<xsd:element name="BuildLog" type="xsd:string" /><br />
<xsd:element name="ReturnCode" type="xsd:integer" /><br />
<xsd:element name="StepReturnCodes" type="xsd:integer" /><br />
<xsd:element name="Reports" type="ReportTypeType" minOccurs="0" maxOccurs="unbounded"/> <br />
<xsd:element name="BuiltTargetList" type="xsd:string" minOccurs="0" maxOccurs="unbounded" /><br />
<xsd:element name="FailedTargetList" type="xsd:string" minOccurs="0" maxOccurs="unbounded" /><br />
<xsd:element name="FailedSourceList" type="xsd:string" minOccurs="0" maxOccurs="unbounded" /><br />
</xsd:sequence> <br />
</xsd:complexType><br />
<br />
<xsd:complexType name="BuildPropertyType"><br />
<xsd:sequence><br />
<xsd:element name="BuildPropertyName" type="xsd:string" /> <br />
<xsd:element name="Target" type="xsd:string" /><br />
<xsd:element name="Clean" type="xsd:boolean" /><br />
<xsd:element name="All" type="xsd:boolean" /><br />
<xsd:element name="ForceFullBuild" type="xsd:boolean" /><br />
<xsd:element name="Debug" type="xsd:boolean" /> <br />
<xsd:element name="Release" type="xsd:boolean" /> <br />
<xsd:element name="BuildAsVersion" type="xsd:string" /><br />
<xsd:element name="BuildLabel" type="xsd:string" /><br />
<xsd:element name="BuildNumber" type="xsd:string" /> <br />
</xsd:sequence><br />
</xsd:complexType><br />
<br />
<xsd:complexType name="BuildConfigurationType"><br />
<xsd:sequence><br />
<xsd:element name="BuildConfigurationName" type="xsd:string" /><br />
<xsd:element name="BuildProperty" type="BuildProperyType" minOccurs="0" maxOccurs="unbounded" /> <br />
</xsd:sequence><br />
</xsd:complexType><br />
<br />
<xsd:complexType name="BuildWorkspaceType"><br />
<xsd:sequence><br />
<xsd:element name="Project" type="xsd:string" /><br />
<xsd:element name="Identifier" type="xsd:string" /> <br />
<xsd:element name="BuildWorkspaceName" type="xsd:string" /><br />
<xsd:element name="BuildConfiguration" type="BuildConfigurationType" minOccurs="0" maxOccurs="unbounded" /> <br />
</xsd:sequence><br />
</xsd:complexType><br />
</xsd:schema><br />
</pre></div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/Build_Vocabulary/Schema&diff=12776ALF/Build Vocabulary/Schema2006-10-05T00:08:35Z<p>Alf tbuss.yahoo.com: /* Build Vocabulary Schema */</p>
<hr />
<div>http://meta.wikimedia.org/wiki/Help:Editing<br />
== Build Vocabulary Schema ==<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8" ?><br />
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"<br />
xmlns="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
xmlns:tns="http://www.eclipse.org/alf/schema/alfcommonvocabulary/v0.00"<br />
targetNamespace="http://www.eclipse.org/alf/schema/buildvocabulary/v0.00"<br />
elementFormDefault="qualified" attributeFormDefault="unqualified"><br />
<xsd:annotation><br />
<xsd:documentation><br />
WARNING! PRELIMINARY FOR COMMENT ONLY<br />
Copyright Notice The material in this document is Copyright<br />
(c) Catalyst Systems Corporation and others, 2005,2006 Terms and<br />
Conditions: The Eclipse Foundation makes available all<br />
content in this document ("Content"). Unless otherwise<br />
indicated below, the Content is provided to you under the<br />
terms and conditions of the Eclipse Public License Version<br />
1.0 ("EPL"). A copy of the EPL is available at<br />
http://www.eclipse.org/legal/epl-v10.html. For purposes of<br />
the EPL, "Program" will mean the Content. If you did not<br />
receive this Content directly from the Eclipse Foundation,<br />
the Content is being redistributed by another party<br />
("Redistributor") and different terms and conditions may<br />
apply to your use of any object code in the Content. Check<br />
the Redistributor's license that was provided with the<br />
Content. If you did not receive any such license, contact<br />
the Redistributor. Unless otherwise indicated below, the<br />
terms and conditions of the EPL still apply to the Content.<br />
</xsd:documentation><br />
</xsd:annotation><br />
<br />
<xsd:complexType name="ReportTypeType"><br />
<xsd:sequence><br />
<xsd:element name="ReportType" type="xsd:string" /><br />
<xsd:element name="Report" type="xsd:string" /><br />
</xsd:sequence> <br />
</xsd:complexType> <br />
<br />
<xsd:complexType name="BuildResultsType"><br />
<xsd:sequence><br />
<xsd:element name="BuildLog" type="xsd:string" /><br />
<xsd:element name="ReturnCode" type="xsd:integer" /><br />
<xsd:element name="StepReturnCodes" type="xsd:integer" /><br />
<xsd:element name="Reports" type="ReportTypeType" minOccurs="0" maxOccurs="unbounded"/> <br />
<xsd:element name="BuiltTargetList" type="xsd:string" minOccurs="0" maxOccurs="unbounded" /><br />
<xsd:element name="FailedTargetList" type="xsd:string" minOccurs="0" maxOccurs="unbounded" /><br />
<xsd:element name="FailedSourceList" type="xsd:string" minOccurs="0" maxOccurs="unbounded" /><br />
</xsd:sequence> <br />
</xsd:complexType><br />
<br />
<xsd:complexType name="BuildPropertyType"><br />
<xsd:sequence><br />
<xsd:element name="BuildPropertyName" type="xsd:string" /> <br />
<xsd:element name="Target" type="xsd:string" /><br />
<xsd:element name="Clean" type="xsd:boolean" /><br />
<xsd:element name="All" type="xsd:boolean" /><br />
<xsd:element name="ForceFullBuild" type="xsd:boolean" /><br />
<xsd:element name="Debug" type="xsd:boolean" /> <br />
<xsd:element name="Release" type="xsd:boolean" /> <br />
<xsd:element name="BuildAsVersion" type="xsd:string" /><br />
<xsd:element name="BuildLabel" type="xsd:string" /><br />
<xsd:element name="BuildNumber" type="xsd:string" /> <br />
</xsd:sequence><br />
</xsd:complexType><br />
<br />
<xsd:complexType name="BuildConfigurationType"><br />
<xsd:sequence><br />
<xsd:element name="BuildConfigurationName" type="xsd:string" /><br />
<xsd:element name="BuildProperty" type="BuildProperyType" minOccurs="0" maxOccurs="unbounded" /> <br />
</xsd:sequence><br />
</xsd:complexType><br />
<br />
<xsd:complexType name="BuildWorkspaceType"><br />
<xsd:sequence><br />
<xsd:element name="Project" type="xsd:string" /><br />
<xsd:element name="Identifier" type="xsd:string" /> <br />
<xsd:element name="BuildWorkspaceName" type="xsd:string" /><br />
<xsd:element name="BuildConfiguration" type="BuildConfigurationType" minOccurs="0" maxOccurs="unbounded" /> <br />
</xsd:sequence><br />
</xsd:complexType><br />
</xsd:schema><br />
</pre></div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/Build_Vocabulary&diff=12775ALF/Build Vocabulary2006-10-05T00:08:13Z<p>Alf tbuss.yahoo.com: </p>
<hr />
<div>[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
== Introduction ==<br />
The Build Vocabulary focuses on the translation of source code into binary format. This<br />
translation occurs through the use of compilers and linkers. Build tools call the compilers and<br />
linkers and are not compilers or linkers themselves.<br />
<br />
== Assumptions ==<br />
The Build Vocabulary will not be responsible for checking out code or determining the correct source<br />
code to include in the Build. The ALF Service flow should be setup so that the pre and post steps are<br />
handled by ALF. The Build Vocabulary will interact with<br />
the other vocabularies such as SCM, Problem Tracking and Requirements gathering to obtain information<br />
that should be included in the build results, i.e. the runnable binaries.<br />
<br />
== Objects ==<br />
=== Build ===<br />
The compile and link process. <br />
<br />
=== Project ===<br />
Name of the items to be built.<br />
<br />
=== Identifier ===<br />
Name of Vendor Tool project specific identifier.<br />
<br />
=== Build Workspace ===<br />
A Build Workspace corresponds to the SCM Workspace.<br />
<br />
The Build Workspace would be identified by a Project + Identifier. For example, Project: Hello World<br />
+ "Version 1".<br />
<br />
=== Build Configuration ===<br />
A Build Configuration is a pre-defined way a Build will run.<br />
<br />
Within a Build Workspace there would be 0-N Build Configurations.<br />
<br />
=== Build Properties ===<br />
A Build Property is an option to the Build Engine.<br />
<br />
A Build Configuration would contain 0-N, Build Properties.<br />
<br />
=== Build Property ===<br />
<br />
==== Target ====<br />
Target - item to be built, ie. helloworld.jar<br />
<br />
==== clean ====<br />
clean - remove all Targets and Intermediate Targets in the Build Workspace<br />
<br />
==== all ====<br />
all - represents all Targets<br />
<br />
==== ForceFullBuild ====<br />
Force full build - indicate to the Build Engine to build regardless of timestamp or versions.<br />
<br />
==== debug ====<br />
debug - indicate to the Build Engine to perform a build using debug compile options<br />
<br />
==== release ====<br />
release - indicate to the Build Engine to perform a build using release compile options<br />
<br />
==== BuildAsVersion ====<br />
BuildAsVersion - version of the target to create, ie. helloworld-1.4.3.jar where 1.4.3 is the BuildAsVersion.<br />
<br />
==== BuildLabel ====<br />
BuildLabel - label used to indicate the Build or SCM label, ie. "Nightly Build"<br />
<br />
==== BuildNumber ====<br />
BuildNumber - number of the build, ie Build 327<br />
<br />
=== BuildResults ===<br />
<br />
==== BuildLog ====<br />
* File or http pointer to step output <br />
* 0-N occurrences<br />
* Type: String<br />
<br />
==== ReturnCode ====<br />
* Over all SUCESS or FAILURE of the Build<br />
* Type: Integer (SUCESS = 1, FAILURE = 0)<br />
<br />
==== StepReturnCode ====<br />
* Individual Step return codes<br />
* 0-N occurrences<br />
* Type: Integer<br />
<br />
==== Reports ==== <br />
* ReportType <br />
* File or http pointer to Build Reports<br />
* 0-N occurrences<br />
* Type: Dictionary - ReportType (Key, String) BuildReport (Value, URL)<br />
<br />
==== BuiltTargetList ====<br />
* List of Targets that where built<br />
* 0-N occurrences<br />
* Type: String<br />
<br />
==== FailedTargetList ====<br />
* List of Targets that where NOT built<br />
* 0-N occurrences<br />
* Type: String<br />
<br />
==== FailedSourceList ====<br />
* List of Source File that had errors<br />
* 0-N occurrences<br />
* Type: String<br />
<br />
== API == <br />
<br />
<pre><br />
BuildResults Build(SCM Workspace, ProjectName, BuildIdentifier, BuildConfiguration)<br />
</pre><br />
<br />
<pre><br />
Example: <br />
BuildResults br = Build("Hello Snapshot","Hello World","Version 1","DEBUG");<br />
</pre><br />
<br />
Notes:<br />
* SCM Workspace Type allows as to obtain the Client Machine and the SCM Root Dir<br />
* The ProjectName + BuildIdentifier will allow us to obtain the correct Build WorkSpace and then the BuildConfiguration will allow us to obtain the correct Build options within the Build Workspace.<br />
<br />
== Schema ==<br />
[[ALF/Build Vocabulary/Schema | Schema]]</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/architecture/ALF_Schemas_001&diff=12405ALF/architecture/ALF Schemas 0012006-10-03T05:14:12Z<p>Alf tbuss.yahoo.com: /* '''3. Clarify ProductCallbackURI'''. */</p>
<hr />
<div>__TOC__ <br />
[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
<br />
== Introduction ==<br />
'''ALF Event Manager Schemas and WSDL version 001'''<br />
<br />
We have been reviewing the ALF Event Schema and our recommendation is that if should be flattened and simplified. Here the details of our suggestions and reasoning so far. The proposed schema is just for illustration and should not <br />
be considered final. Please respond with any comments you may have and any other suggestions about way to streamline the ALF event Schema. <br />
<br />
Here are the details of the changes which have undergone some review and will be likely be adopted. These changes are refected in the Schema and WSDL below<br />
<br />
<br />
'''1. Eliminate a nesting level between BasicEventType and Event Data.'''<br />
<br />
This serves no particular purpose except to separate it from the Context Array which is not returned on an ACK. If we eliminate the Context Array as I suggest below then this distinction is no longer required.<br />
<br />
<br />
'''2. Eliminate the Object Array in favor of a single ObjectType.'''<br />
<br />
This is in BasicEventType. It seems to me that is very rare that we will encounter a situation where a tool cannot provide a single identity to use to call back for additional information. While the array and related "relationship" attribute may be potentially powerful it would seem better relegated to a potential common vocabulary type for vocabulary or tool specific event details. The only potential issue is that removing the array from the basic event also removes it from the consideration as part of an ALF event manager dispatch rule. Currently we only use the first object in the array. This seems a reasonable price to pay The array seems somewhat complex for that purpose due to its rather arbitrary nature and, if we find we are really missing it later we have the option of extending the Basic Event to include an array of this nature in addition to the primary object.<br />
<br />
<br />
'''3. Eliminate the Context Array'''<br />
<br />
We should also merge the current user details into the BasicEventType. The context array does not seem that useful to me. It just makes the current context harder to discern. Further, it does not seem to be desirable from a security standpoint to be passing around arrays of credentials. I don't see any particular programmatic use of this feature and a simple log or a relationship store would be a better method of tracing contexts after the event. Even if it is of some practical use, that use relies on the support to tools to return the context in full in an event. This seems unlikely except by the most avid of ALF participating tools rendering it useless in the foreseeable future.<br />
<br />
'''4.Eliminate "InitiatingFlow" and the "nesting" attribute'''<br />
<br />
This is an aspect of the Context. This does not provide much useful information and again relies on all participants to behave the ALF way in order for the nesting counter to accurate. Instead provide some preceding IDs ( see below) and rely on logging. I am unclear whether it would be useful to know if the event comes from a user interaction or a service flow. It would seem to me likely that that this can be inferred from the event type and event product information and not explicit flag is required. I am unclear what you would do with it in any case. Thus I would just eliminate it.<br />
<br />
<br />
'''5. Add "PrecedingEvent" and "PrecedingServiceFlow" to the Basic Event Type as nillable elements.'''<br />
<br />
If the event is generated in the directly by a service flow then the ServiceFlow will fill these, identifying itself and the event that initiated it. Optionally an ALF compliant service may take this data and return it in any event it generates. The Source elements can be used to distinguish the cases.<br />
<br />
<br />
'''6. Add a ALFEventNoACK element and associated Type.'''<br />
<br />
Async Service flows have this type. Unfortunately the Event Manager currently dispatches using ALFEventACK which is incorrect and confusing. (Note: this change and been subsumed by the name changes describe in 8. below)<br />
<br />
<br />
'''7. Eliminate the use of the "mixed" attribute.'''<br />
<br />
I believed the used of the attribute "mixed" is incorrect. This attribute means that and element can contain both content text and other elements. I don't think that is the intent. Its use here appears to be associated with the use of an attribute which is incorrect.<br />
<br />
<br />
'''8. "Clean up" or "Gratuitously change" some names.'''<br />
<br />
The purpose is to make things feel a bit more consistent and this is really our last chance to do so.<br />
<br />
The suggested changes are as follows:<br />
<br />
The schema file will be called ALFEventBase.xsd<br />
<br />
BasicEventType -> EventBaseType<br />
EventDetailsType -> EventDetailType<br />
ToolExtensionDataType -> EventExtensionType BasicEvent -> Base EventDetails -> Detail ToolExtensionData -> Extension<br />
<br />
ALFEventACKType -> ALFEventResponseType<br />
Note: The bool value is eliminated from this since there seems little point in a boolean that will always be true if it is succesfully received but otherwise not received.<br />
<br />
ALFEvent -> EventNotice<br />
ALFEventACK -> EventNoticeResponse<br />
Note: this is to conform with the WSDL "Document Literal Wrapped" convention<br />
<br />
The following messages are added for "synchronous events" <br />
EventNoticeWithReply<br />
EventNoticeWithReplyResponse<br />
<br />
The EventNoticeWithReply operations is added to the ALFEventManager service<br />
<br />
Some new ports and corresponding bindings are added to provide the base template for Service Flow services ALFServiceFlow ALFServiceFlowWithReply<br />
<br />
'''9. The Credential element should be typed "any".'''<br />
It is likely that the credential element will be expressed as XML. It may be more covenient to contain such an element as an XML structure rather than by having it encoded or encapsualted as CData. may the CredentialType "any" allows it to take any of these formats<br />
<br />
== Additional Changes ==<br />
Listed below are some other possible simplifications and name changes. These need some some further discussion/definition before we accept them.<br />
<br />
==='''1. Combine Detail and Extension to a single xs:any element perhaps called <payload>.'''===<br />
<br />
It is not clear to me there is an advantage in keeping these separate. If there is we need to make that clear. It would seem adequate to me that a tool would declare its event data and that it will either be a pure ALF vocab structure or it will be custom or it will be some combination. Forcing the division seems like it will just make it inconvenient for tools to declare their data and will mean either misuse or no use of the ALF vocabulary.<br />
<br />
==='''2. Eliminate the "required" attributes.'''===<br />
<br />
''alfEventVersion'' on EventBaseType (nee BasicEventType) I realise the intent is to inform the recipient that the event definition is derived froma particular verision and possibly this is useful a runtime since it would possibly allow use to handle incompatible versions. This seem somewhat unlikely at this level at which it works. Maybe it is cheap enough to make that enough but something bothers me about it and I suspect that it will never be used. It is something that can be added if we ever do need it but for now it's just extra crud someone has to set before sending the event that doesn't do anything. If we have it, it seem like the schema should define the exact value it must contain.<br />
<br />
''schemaLocation'' on EventDetailType (nee EventDetailsType) and EventExtensionType (nee ToolExtensionData) I realise these attributes are supposed to point to the schema for the contained data but I'm not sure what the point of these attributes really is from a practical perspective. It seems to me nothing at runtime will look at these and validate the element content so perhaps they are just gratuitous and unecessary. Possibly there is a clearer way to do this since we do need tools to declare their events. Possibly the schema attribute, if we have it, needs to be higher up in the event structure.<br />
<br />
==='''3. Clarify ProductCallbackURI'''.===<br />
<br />
Possibly Clarify ProductCallbackURI should be named Clarify ProductCallbackURL. I think ''Callback'' implies it must be an URL and not just a URI. I'm a bit unclear how this would be used. I think it may need some more definition to make it useful. Does it define a server, a service, an operation ??? If I was trying to design to it I would presumably need a WSDL which presumably would need to be defined as part of the event declaration.<br />
<br />
BPEL uses the WS Addressing schema allows assignment of an wsa.EndpointReference to a PartnerLink. This allows a service endpoint to be set dynamically. ie.<br />
<br />
The wsa namespace:<br />
<pre><br />
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing"<br />
</pre><br />
<br />
defines the endpoint reference as:<br />
<pre><br />
<wsa:EndpointReference><br />
<wsa:Address>anyURI</wsa:Address><br />
<wsa:ServiceName>tns:Service</wsa:ServiceName><br />
</wsa:EndpointReference><br />
</pre><br />
<br />
This may be a better type to choose for the ProductCallbackURI. Not that the operation is not included. It is not clear if an operation can be set dynamically in BPEL. Given that an operation is genrally tied to its in and out messages, setting the operation dynamically presents problems in the general case so it seems likely that this is not supported.<br />
<br />
==='''4. Eliminate the BaseEvent structure in the ALFEventResponse message.'''===<br />
<br />
Currently the event manager sends back the EventBase structure that it received. I'm not sure if there was a purpose to this. It seems unecessary to send the whole structure and other information might be useful also like an indication that the event matched to a service flow. Probably worth a discussion before we put it to bed.<br />
<br />
== Schema 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventBase_001.xsd | ALFEventBase_001.xsd]]<br />
<br />
== WSDL 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventManager_001.WSDL | ALFEventManager_001.WSDL]]</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/architecture/ALF_Schemas_001&diff=12404ALF/architecture/ALF Schemas 0012006-10-03T05:06:10Z<p>Alf tbuss.yahoo.com: /* '''3. Change ProductCallbackURI to ProductCallbackURL'''. */</p>
<hr />
<div>__TOC__ <br />
[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
<br />
== Introduction ==<br />
'''ALF Event Manager Schemas and WSDL version 001'''<br />
<br />
We have been reviewing the ALF Event Schema and our recommendation is that if should be flattened and simplified. Here the details of our suggestions and reasoning so far. The proposed schema is just for illustration and should not <br />
be considered final. Please respond with any comments you may have and any other suggestions about way to streamline the ALF event Schema. <br />
<br />
Here are the details of the changes which have undergone some review and will be likely be adopted. These changes are refected in the Schema and WSDL below<br />
<br />
<br />
'''1. Eliminate a nesting level between BasicEventType and Event Data.'''<br />
<br />
This serves no particular purpose except to separate it from the Context Array which is not returned on an ACK. If we eliminate the Context Array as I suggest below then this distinction is no longer required.<br />
<br />
<br />
'''2. Eliminate the Object Array in favor of a single ObjectType.'''<br />
<br />
This is in BasicEventType. It seems to me that is very rare that we will encounter a situation where a tool cannot provide a single identity to use to call back for additional information. While the array and related "relationship" attribute may be potentially powerful it would seem better relegated to a potential common vocabulary type for vocabulary or tool specific event details. The only potential issue is that removing the array from the basic event also removes it from the consideration as part of an ALF event manager dispatch rule. Currently we only use the first object in the array. This seems a reasonable price to pay The array seems somewhat complex for that purpose due to its rather arbitrary nature and, if we find we are really missing it later we have the option of extending the Basic Event to include an array of this nature in addition to the primary object.<br />
<br />
<br />
'''3. Eliminate the Context Array'''<br />
<br />
We should also merge the current user details into the BasicEventType. The context array does not seem that useful to me. It just makes the current context harder to discern. Further, it does not seem to be desirable from a security standpoint to be passing around arrays of credentials. I don't see any particular programmatic use of this feature and a simple log or a relationship store would be a better method of tracing contexts after the event. Even if it is of some practical use, that use relies on the support to tools to return the context in full in an event. This seems unlikely except by the most avid of ALF participating tools rendering it useless in the foreseeable future.<br />
<br />
'''4.Eliminate "InitiatingFlow" and the "nesting" attribute'''<br />
<br />
This is an aspect of the Context. This does not provide much useful information and again relies on all participants to behave the ALF way in order for the nesting counter to accurate. Instead provide some preceding IDs ( see below) and rely on logging. I am unclear whether it would be useful to know if the event comes from a user interaction or a service flow. It would seem to me likely that that this can be inferred from the event type and event product information and not explicit flag is required. I am unclear what you would do with it in any case. Thus I would just eliminate it.<br />
<br />
<br />
'''5. Add "PrecedingEvent" and "PrecedingServiceFlow" to the Basic Event Type as nillable elements.'''<br />
<br />
If the event is generated in the directly by a service flow then the ServiceFlow will fill these, identifying itself and the event that initiated it. Optionally an ALF compliant service may take this data and return it in any event it generates. The Source elements can be used to distinguish the cases.<br />
<br />
<br />
'''6. Add a ALFEventNoACK element and associated Type.'''<br />
<br />
Async Service flows have this type. Unfortunately the Event Manager currently dispatches using ALFEventACK which is incorrect and confusing. (Note: this change and been subsumed by the name changes describe in 8. below)<br />
<br />
<br />
'''7. Eliminate the use of the "mixed" attribute.'''<br />
<br />
I believed the used of the attribute "mixed" is incorrect. This attribute means that and element can contain both content text and other elements. I don't think that is the intent. Its use here appears to be associated with the use of an attribute which is incorrect.<br />
<br />
<br />
'''8. "Clean up" or "Gratuitously change" some names.'''<br />
<br />
The purpose is to make things feel a bit more consistent and this is really our last chance to do so.<br />
<br />
The suggested changes are as follows:<br />
<br />
The schema file will be called ALFEventBase.xsd<br />
<br />
BasicEventType -> EventBaseType<br />
EventDetailsType -> EventDetailType<br />
ToolExtensionDataType -> EventExtensionType BasicEvent -> Base EventDetails -> Detail ToolExtensionData -> Extension<br />
<br />
ALFEventACKType -> ALFEventResponseType<br />
Note: The bool value is eliminated from this since there seems little point in a boolean that will always be true if it is succesfully received but otherwise not received.<br />
<br />
ALFEvent -> EventNotice<br />
ALFEventACK -> EventNoticeResponse<br />
Note: this is to conform with the WSDL "Document Literal Wrapped" convention<br />
<br />
The following messages are added for "synchronous events" <br />
EventNoticeWithReply<br />
EventNoticeWithReplyResponse<br />
<br />
The EventNoticeWithReply operations is added to the ALFEventManager service<br />
<br />
Some new ports and corresponding bindings are added to provide the base template for Service Flow services ALFServiceFlow ALFServiceFlowWithReply<br />
<br />
'''9. The Credential element should be typed "any".'''<br />
It is likely that the credential element will be expressed as XML. It may be more covenient to contain such an element as an XML structure rather than by having it encoded or encapsualted as CData. may the CredentialType "any" allows it to take any of these formats<br />
<br />
== Additional Changes ==<br />
Listed below are some other possible simplifications and name changes. These need some some further discussion/definition before we accept them.<br />
<br />
==='''1. Combine Detail and Extension to a single xs:any element perhaps called <payload>.'''===<br />
<br />
It is not clear to me there is an advantage in keeping these separate. If there is we need to make that clear. It would seem adequate to me that a tool would declare its event data and that it will either be a pure ALF vocab structure or it will be custom or it will be some combination. Forcing the division seems like it will just make it inconvenient for tools to declare their data and will mean either misuse or no use of the ALF vocabulary.<br />
<br />
==='''2. Eliminate the "required" attributes.'''===<br />
<br />
''alfEventVersion'' on EventBaseType (nee BasicEventType) I realise the intent is to inform the recipient that the event definition is derived froma particular verision and possibly this is useful a runtime since it would possibly allow use to handle incompatible versions. This seem somewhat unlikely at this level at which it works. Maybe it is cheap enough to make that enough but something bothers me about it and I suspect that it will never be used. It is something that can be added if we ever do need it but for now it's just extra crud someone has to set before sending the event that doesn't do anything. If we have it, it seem like the schema should define the exact value it must contain.<br />
<br />
''schemaLocation'' on EventDetailType (nee EventDetailsType) and EventExtensionType (nee ToolExtensionData) I realise these attributes are supposed to point to the schema for the contained data but I'm not sure what the point of these attributes really is from a practical perspective. It seems to me nothing at runtime will look at these and validate the element content so perhaps they are just gratuitous and unecessary. Possibly there is a clearer way to do this since we do need tools to declare their events. Possibly the schema attribute, if we have it, needs to be higher up in the event structure.<br />
<br />
==='''3. Clarify ProductCallbackURI'''.===<br />
<br />
I think ''Callback'' implies it must be an URL and not just a URI. I'm a bit unclear how this would be used. I think it may need some more definition to make it useful. Does it define a server, a service, an operation ??? If I was trying to design to it I would presumably need a WSDL which presumably would need to be defined as part of the event declaration.<br />
<br />
On further research it seems that a common practice in BPEL is to use the WS Adressing endpoint reference. ie<br />
<br />
from the wsa namespace<br />
<pre><br />
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing"<br />
</pre><br />
<br />
the endpoint reference has the form:<br />
<pre><br />
<wsa:EndpointReference><br />
<wsa:Address>anyURI</wsa:Address><br />
<wsa:ServiceName>tns:Service</wsa:ServiceName><br />
</wsa:EndpointReference><br />
</pre><br />
<br />
BPEL allows assignment of an wsa.EndpointReference to a PartnerLink which allows a service endpoint to be set dynamically.<br />
<br />
==='''4. Eliminate the BaseEvent structure in the ALFEventResponse message.'''===<br />
<br />
Currently the event manager sends back the EventBase structure that it received. I'm not sure if there was a purpose to this. It seems unecessary to send the whole structure and other information might be useful also like an indication that the event matched to a service flow. Probably worth a discussion before we put it to bed.<br />
<br />
== Schema 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventBase_001.xsd | ALFEventBase_001.xsd]]<br />
<br />
== WSDL 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventManager_001.WSDL | ALFEventManager_001.WSDL]]</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/architecture/ALF_Schemas_001&diff=12403ALF/architecture/ALF Schemas 0012006-10-03T05:05:02Z<p>Alf tbuss.yahoo.com: /* '''3. Change ProductCallbackURI to ProductCallbackURL'''. */</p>
<hr />
<div>__TOC__ <br />
[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
<br />
== Introduction ==<br />
'''ALF Event Manager Schemas and WSDL version 001'''<br />
<br />
We have been reviewing the ALF Event Schema and our recommendation is that if should be flattened and simplified. Here the details of our suggestions and reasoning so far. The proposed schema is just for illustration and should not <br />
be considered final. Please respond with any comments you may have and any other suggestions about way to streamline the ALF event Schema. <br />
<br />
Here are the details of the changes which have undergone some review and will be likely be adopted. These changes are refected in the Schema and WSDL below<br />
<br />
<br />
'''1. Eliminate a nesting level between BasicEventType and Event Data.'''<br />
<br />
This serves no particular purpose except to separate it from the Context Array which is not returned on an ACK. If we eliminate the Context Array as I suggest below then this distinction is no longer required.<br />
<br />
<br />
'''2. Eliminate the Object Array in favor of a single ObjectType.'''<br />
<br />
This is in BasicEventType. It seems to me that is very rare that we will encounter a situation where a tool cannot provide a single identity to use to call back for additional information. While the array and related "relationship" attribute may be potentially powerful it would seem better relegated to a potential common vocabulary type for vocabulary or tool specific event details. The only potential issue is that removing the array from the basic event also removes it from the consideration as part of an ALF event manager dispatch rule. Currently we only use the first object in the array. This seems a reasonable price to pay The array seems somewhat complex for that purpose due to its rather arbitrary nature and, if we find we are really missing it later we have the option of extending the Basic Event to include an array of this nature in addition to the primary object.<br />
<br />
<br />
'''3. Eliminate the Context Array'''<br />
<br />
We should also merge the current user details into the BasicEventType. The context array does not seem that useful to me. It just makes the current context harder to discern. Further, it does not seem to be desirable from a security standpoint to be passing around arrays of credentials. I don't see any particular programmatic use of this feature and a simple log or a relationship store would be a better method of tracing contexts after the event. Even if it is of some practical use, that use relies on the support to tools to return the context in full in an event. This seems unlikely except by the most avid of ALF participating tools rendering it useless in the foreseeable future.<br />
<br />
'''4.Eliminate "InitiatingFlow" and the "nesting" attribute'''<br />
<br />
This is an aspect of the Context. This does not provide much useful information and again relies on all participants to behave the ALF way in order for the nesting counter to accurate. Instead provide some preceding IDs ( see below) and rely on logging. I am unclear whether it would be useful to know if the event comes from a user interaction or a service flow. It would seem to me likely that that this can be inferred from the event type and event product information and not explicit flag is required. I am unclear what you would do with it in any case. Thus I would just eliminate it.<br />
<br />
<br />
'''5. Add "PrecedingEvent" and "PrecedingServiceFlow" to the Basic Event Type as nillable elements.'''<br />
<br />
If the event is generated in the directly by a service flow then the ServiceFlow will fill these, identifying itself and the event that initiated it. Optionally an ALF compliant service may take this data and return it in any event it generates. The Source elements can be used to distinguish the cases.<br />
<br />
<br />
'''6. Add a ALFEventNoACK element and associated Type.'''<br />
<br />
Async Service flows have this type. Unfortunately the Event Manager currently dispatches using ALFEventACK which is incorrect and confusing. (Note: this change and been subsumed by the name changes describe in 8. below)<br />
<br />
<br />
'''7. Eliminate the use of the "mixed" attribute.'''<br />
<br />
I believed the used of the attribute "mixed" is incorrect. This attribute means that and element can contain both content text and other elements. I don't think that is the intent. Its use here appears to be associated with the use of an attribute which is incorrect.<br />
<br />
<br />
'''8. "Clean up" or "Gratuitously change" some names.'''<br />
<br />
The purpose is to make things feel a bit more consistent and this is really our last chance to do so.<br />
<br />
The suggested changes are as follows:<br />
<br />
The schema file will be called ALFEventBase.xsd<br />
<br />
BasicEventType -> EventBaseType<br />
EventDetailsType -> EventDetailType<br />
ToolExtensionDataType -> EventExtensionType BasicEvent -> Base EventDetails -> Detail ToolExtensionData -> Extension<br />
<br />
ALFEventACKType -> ALFEventResponseType<br />
Note: The bool value is eliminated from this since there seems little point in a boolean that will always be true if it is succesfully received but otherwise not received.<br />
<br />
ALFEvent -> EventNotice<br />
ALFEventACK -> EventNoticeResponse<br />
Note: this is to conform with the WSDL "Document Literal Wrapped" convention<br />
<br />
The following messages are added for "synchronous events" <br />
EventNoticeWithReply<br />
EventNoticeWithReplyResponse<br />
<br />
The EventNoticeWithReply operations is added to the ALFEventManager service<br />
<br />
Some new ports and corresponding bindings are added to provide the base template for Service Flow services ALFServiceFlow ALFServiceFlowWithReply<br />
<br />
'''9. The Credential element should be typed "any".'''<br />
It is likely that the credential element will be expressed as XML. It may be more covenient to contain such an element as an XML structure rather than by having it encoded or encapsualted as CData. may the CredentialType "any" allows it to take any of these formats<br />
<br />
== Additional Changes ==<br />
Listed below are some other possible simplifications and name changes. These need some some further discussion/definition before we accept them.<br />
<br />
==='''1. Combine Detail and Extension to a single xs:any element perhaps called <payload>.'''===<br />
<br />
It is not clear to me there is an advantage in keeping these separate. If there is we need to make that clear. It would seem adequate to me that a tool would declare its event data and that it will either be a pure ALF vocab structure or it will be custom or it will be some combination. Forcing the division seems like it will just make it inconvenient for tools to declare their data and will mean either misuse or no use of the ALF vocabulary.<br />
<br />
==='''2. Eliminate the "required" attributes.'''===<br />
<br />
''alfEventVersion'' on EventBaseType (nee BasicEventType) I realise the intent is to inform the recipient that the event definition is derived froma particular verision and possibly this is useful a runtime since it would possibly allow use to handle incompatible versions. This seem somewhat unlikely at this level at which it works. Maybe it is cheap enough to make that enough but something bothers me about it and I suspect that it will never be used. It is something that can be added if we ever do need it but for now it's just extra crud someone has to set before sending the event that doesn't do anything. If we have it, it seem like the schema should define the exact value it must contain.<br />
<br />
''schemaLocation'' on EventDetailType (nee EventDetailsType) and EventExtensionType (nee ToolExtensionData) I realise these attributes are supposed to point to the schema for the contained data but I'm not sure what the point of these attributes really is from a practical perspective. It seems to me nothing at runtime will look at these and validate the element content so perhaps they are just gratuitous and unecessary. Possibly there is a clearer way to do this since we do need tools to declare their events. Possibly the schema attribute, if we have it, needs to be higher up in the event structure.<br />
<br />
==='''3. Change ProductCallbackURI to ProductCallbackURL'''.===<br />
<br />
I think ''Callback'' implies it must be an URL and not just a URI. I'm a bit unclear how this would be used. I think it may need some more definition to make it useful. Does it define a server, a service, an operation ??? If I was trying to design to it I would presumably need a WSDL which presumably would need to be defined as part of the event declaration.<br />
<br />
On further research it seems that a common practice in BPEL is to use the WS Adressing endpoint reference. ie<br />
<br />
from the wsa namespace<br />
<pre><br />
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing"<br />
</pre><br />
<br />
the endpoint reference has the form:<br />
<pre><br />
<wsa:EndpointReference><br />
<wsa:Address>anyURI</wsa:Address><br />
<wsa:ServiceName>tns:Service</wsa:ServiceName><br />
</wsa:EndpointReference><br />
</pre><br />
<br />
BPEL allows assignment of an wsa.EndpointReference to a PartnerLink which allows a service endpoint to be set dynamically.<br />
<br />
==='''4. Eliminate the BaseEvent structure in the ALFEventResponse message.'''===<br />
<br />
Currently the event manager sends back the EventBase structure that it received. I'm not sure if there was a purpose to this. It seems unecessary to send the whole structure and other information might be useful also like an indication that the event matched to a service flow. Probably worth a discussion before we put it to bed.<br />
<br />
== Schema 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventBase_001.xsd | ALFEventBase_001.xsd]]<br />
<br />
== WSDL 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventManager_001.WSDL | ALFEventManager_001.WSDL]]</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/architecture/ALF_Schemas_001&diff=12399ALF/architecture/ALF Schemas 0012006-10-03T02:52:33Z<p>Alf tbuss.yahoo.com: /* '''3. Change ProductCallbackURI to ProductCallbackURL'''. */</p>
<hr />
<div>__TOC__ <br />
[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
<br />
== Introduction ==<br />
'''ALF Event Manager Schemas and WSDL version 001'''<br />
<br />
We have been reviewing the ALF Event Schema and our recommendation is that if should be flattened and simplified. Here the details of our suggestions and reasoning so far. The proposed schema is just for illustration and should not <br />
be considered final. Please respond with any comments you may have and any other suggestions about way to streamline the ALF event Schema. <br />
<br />
Here are the details of the changes which have undergone some review and will be likely be adopted. These changes are refected in the Schema and WSDL below<br />
<br />
<br />
'''1. Eliminate a nesting level between BasicEventType and Event Data.'''<br />
<br />
This serves no particular purpose except to separate it from the Context Array which is not returned on an ACK. If we eliminate the Context Array as I suggest below then this distinction is no longer required.<br />
<br />
<br />
'''2. Eliminate the Object Array in favor of a single ObjectType.'''<br />
<br />
This is in BasicEventType. It seems to me that is very rare that we will encounter a situation where a tool cannot provide a single identity to use to call back for additional information. While the array and related "relationship" attribute may be potentially powerful it would seem better relegated to a potential common vocabulary type for vocabulary or tool specific event details. The only potential issue is that removing the array from the basic event also removes it from the consideration as part of an ALF event manager dispatch rule. Currently we only use the first object in the array. This seems a reasonable price to pay The array seems somewhat complex for that purpose due to its rather arbitrary nature and, if we find we are really missing it later we have the option of extending the Basic Event to include an array of this nature in addition to the primary object.<br />
<br />
<br />
'''3. Eliminate the Context Array'''<br />
<br />
We should also merge the current user details into the BasicEventType. The context array does not seem that useful to me. It just makes the current context harder to discern. Further, it does not seem to be desirable from a security standpoint to be passing around arrays of credentials. I don't see any particular programmatic use of this feature and a simple log or a relationship store would be a better method of tracing contexts after the event. Even if it is of some practical use, that use relies on the support to tools to return the context in full in an event. This seems unlikely except by the most avid of ALF participating tools rendering it useless in the foreseeable future.<br />
<br />
'''4.Eliminate "InitiatingFlow" and the "nesting" attribute'''<br />
<br />
This is an aspect of the Context. This does not provide much useful information and again relies on all participants to behave the ALF way in order for the nesting counter to accurate. Instead provide some preceding IDs ( see below) and rely on logging. I am unclear whether it would be useful to know if the event comes from a user interaction or a service flow. It would seem to me likely that that this can be inferred from the event type and event product information and not explicit flag is required. I am unclear what you would do with it in any case. Thus I would just eliminate it.<br />
<br />
<br />
'''5. Add "PrecedingEvent" and "PrecedingServiceFlow" to the Basic Event Type as nillable elements.'''<br />
<br />
If the event is generated in the directly by a service flow then the ServiceFlow will fill these, identifying itself and the event that initiated it. Optionally an ALF compliant service may take this data and return it in any event it generates. The Source elements can be used to distinguish the cases.<br />
<br />
<br />
'''6. Add a ALFEventNoACK element and associated Type.'''<br />
<br />
Async Service flows have this type. Unfortunately the Event Manager currently dispatches using ALFEventACK which is incorrect and confusing. (Note: this change and been subsumed by the name changes describe in 8. below)<br />
<br />
<br />
'''7. Eliminate the use of the "mixed" attribute.'''<br />
<br />
I believed the used of the attribute "mixed" is incorrect. This attribute means that and element can contain both content text and other elements. I don't think that is the intent. Its use here appears to be associated with the use of an attribute which is incorrect.<br />
<br />
<br />
'''8. "Clean up" or "Gratuitously change" some names.'''<br />
<br />
The purpose is to make things feel a bit more consistent and this is really our last chance to do so.<br />
<br />
The suggested changes are as follows:<br />
<br />
The schema file will be called ALFEventBase.xsd<br />
<br />
BasicEventType -> EventBaseType<br />
EventDetailsType -> EventDetailType<br />
ToolExtensionDataType -> EventExtensionType BasicEvent -> Base EventDetails -> Detail ToolExtensionData -> Extension<br />
<br />
ALFEventACKType -> ALFEventResponseType<br />
Note: The bool value is eliminated from this since there seems little point in a boolean that will always be true if it is succesfully received but otherwise not received.<br />
<br />
ALFEvent -> EventNotice<br />
ALFEventACK -> EventNoticeResponse<br />
Note: this is to conform with the WSDL "Document Literal Wrapped" convention<br />
<br />
The following messages are added for "synchronous events" <br />
EventNoticeWithReply<br />
EventNoticeWithReplyResponse<br />
<br />
The EventNoticeWithReply operations is added to the ALFEventManager service<br />
<br />
Some new ports and corresponding bindings are added to provide the base template for Service Flow services ALFServiceFlow ALFServiceFlowWithReply<br />
<br />
'''9. The Credential element should be typed "any".'''<br />
It is likely that the credential element will be expressed as XML. It may be more covenient to contain such an element as an XML structure rather than by having it encoded or encapsualted as CData. may the CredentialType "any" allows it to take any of these formats<br />
<br />
== Additional Changes ==<br />
Listed below are some other possible simplifications and name changes. These need some some further discussion/definition before we accept them.<br />
<br />
==='''1. Combine Detail and Extension to a single xs:any element perhaps called <payload>.'''===<br />
<br />
It is not clear to me there is an advantage in keeping these separate. If there is we need to make that clear. It would seem adequate to me that a tool would declare its event data and that it will either be a pure ALF vocab structure or it will be custom or it will be some combination. Forcing the division seems like it will just make it inconvenient for tools to declare their data and will mean either misuse or no use of the ALF vocabulary.<br />
<br />
==='''2. Eliminate the "required" attributes.'''===<br />
<br />
''alfEventVersion'' on EventBaseType (nee BasicEventType) I realise the intent is to inform the recipient that the event definition is derived froma particular verision and possibly this is useful a runtime since it would possibly allow use to handle incompatible versions. This seem somewhat unlikely at this level at which it works. Maybe it is cheap enough to make that enough but something bothers me about it and I suspect that it will never be used. It is something that can be added if we ever do need it but for now it's just extra crud someone has to set before sending the event that doesn't do anything. If we have it, it seem like the schema should define the exact value it must contain.<br />
<br />
''schemaLocation'' on EventDetailType (nee EventDetailsType) and EventExtensionType (nee ToolExtensionData) I realise these attributes are supposed to point to the schema for the contained data but I'm not sure what the point of these attributes really is from a practical perspective. It seems to me nothing at runtime will look at these and validate the element content so perhaps they are just gratuitous and unecessary. Possibly there is a clearer way to do this since we do need tools to declare their events. Possibly the schema attribute, if we have it, needs to be higher up in the event structure.<br />
<br />
==='''3. Change ProductCallbackURI to ProductCallbackURL'''.===<br />
<br />
I think ''Callback'' implies it must be an URL and not just a URI. I'm a bit unclear how this would be used. I think it may need some more definition to make it useful. Does it define a server, a service, an operation ??? If I was trying to design to it I would presumably need a WSDL which presumably would need to be defined as part of the event declaration.<br />
<br />
On further research it seems that a common practice in BPEL is to use the WS Adressing endpoint reference. ie<br />
<br />
from the wsa namespace<br />
<pre><br />
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing"<br />
</pre><br />
<br />
the endpoint reference has the form:<br />
<pre><br />
<wsa:EndpointReference><br />
<wsa:Address>anyURI</wsa:Address><br />
<wsa:ServiceName>tns:Service</wsa:ServiceName><br />
</wsa:EndpointReference><br />
</pre><br />
<br />
==='''4. Eliminate the BaseEvent structure in the ALFEventResponse message.'''===<br />
<br />
Currently the event manager sends back the EventBase structure that it received. I'm not sure if there was a purpose to this. It seems unecessary to send the whole structure and other information might be useful also like an indication that the event matched to a service flow. Probably worth a discussion before we put it to bed.<br />
<br />
== Schema 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventBase_001.xsd | ALFEventBase_001.xsd]]<br />
<br />
== WSDL 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventManager_001.WSDL | ALFEventManager_001.WSDL]]</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/architecture/ALF_Schemas_001&diff=12397ALF/architecture/ALF Schemas 0012006-10-03T02:19:14Z<p>Alf tbuss.yahoo.com: /* Additional Changes */</p>
<hr />
<div>__TOC__ <br />
[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
<br />
== Introduction ==<br />
'''ALF Event Manager Schemas and WSDL version 001'''<br />
<br />
We have been reviewing the ALF Event Schema and our recommendation is that if should be flattened and simplified. Here the details of our suggestions and reasoning so far. The proposed schema is just for illustration and should not <br />
be considered final. Please respond with any comments you may have and any other suggestions about way to streamline the ALF event Schema. <br />
<br />
Here are the details of the changes which have undergone some review and will be likely be adopted. These changes are refected in the Schema and WSDL below<br />
<br />
<br />
'''1. Eliminate a nesting level between BasicEventType and Event Data.'''<br />
<br />
This serves no particular purpose except to separate it from the Context Array which is not returned on an ACK. If we eliminate the Context Array as I suggest below then this distinction is no longer required.<br />
<br />
<br />
'''2. Eliminate the Object Array in favor of a single ObjectType.'''<br />
<br />
This is in BasicEventType. It seems to me that is very rare that we will encounter a situation where a tool cannot provide a single identity to use to call back for additional information. While the array and related "relationship" attribute may be potentially powerful it would seem better relegated to a potential common vocabulary type for vocabulary or tool specific event details. The only potential issue is that removing the array from the basic event also removes it from the consideration as part of an ALF event manager dispatch rule. Currently we only use the first object in the array. This seems a reasonable price to pay The array seems somewhat complex for that purpose due to its rather arbitrary nature and, if we find we are really missing it later we have the option of extending the Basic Event to include an array of this nature in addition to the primary object.<br />
<br />
<br />
'''3. Eliminate the Context Array'''<br />
<br />
We should also merge the current user details into the BasicEventType. The context array does not seem that useful to me. It just makes the current context harder to discern. Further, it does not seem to be desirable from a security standpoint to be passing around arrays of credentials. I don't see any particular programmatic use of this feature and a simple log or a relationship store would be a better method of tracing contexts after the event. Even if it is of some practical use, that use relies on the support to tools to return the context in full in an event. This seems unlikely except by the most avid of ALF participating tools rendering it useless in the foreseeable future.<br />
<br />
'''4.Eliminate "InitiatingFlow" and the "nesting" attribute'''<br />
<br />
This is an aspect of the Context. This does not provide much useful information and again relies on all participants to behave the ALF way in order for the nesting counter to accurate. Instead provide some preceding IDs ( see below) and rely on logging. I am unclear whether it would be useful to know if the event comes from a user interaction or a service flow. It would seem to me likely that that this can be inferred from the event type and event product information and not explicit flag is required. I am unclear what you would do with it in any case. Thus I would just eliminate it.<br />
<br />
<br />
'''5. Add "PrecedingEvent" and "PrecedingServiceFlow" to the Basic Event Type as nillable elements.'''<br />
<br />
If the event is generated in the directly by a service flow then the ServiceFlow will fill these, identifying itself and the event that initiated it. Optionally an ALF compliant service may take this data and return it in any event it generates. The Source elements can be used to distinguish the cases.<br />
<br />
<br />
'''6. Add a ALFEventNoACK element and associated Type.'''<br />
<br />
Async Service flows have this type. Unfortunately the Event Manager currently dispatches using ALFEventACK which is incorrect and confusing. (Note: this change and been subsumed by the name changes describe in 8. below)<br />
<br />
<br />
'''7. Eliminate the use of the "mixed" attribute.'''<br />
<br />
I believed the used of the attribute "mixed" is incorrect. This attribute means that and element can contain both content text and other elements. I don't think that is the intent. Its use here appears to be associated with the use of an attribute which is incorrect.<br />
<br />
<br />
'''8. "Clean up" or "Gratuitously change" some names.'''<br />
<br />
The purpose is to make things feel a bit more consistent and this is really our last chance to do so.<br />
<br />
The suggested changes are as follows:<br />
<br />
The schema file will be called ALFEventBase.xsd<br />
<br />
BasicEventType -> EventBaseType<br />
EventDetailsType -> EventDetailType<br />
ToolExtensionDataType -> EventExtensionType BasicEvent -> Base EventDetails -> Detail ToolExtensionData -> Extension<br />
<br />
ALFEventACKType -> ALFEventResponseType<br />
Note: The bool value is eliminated from this since there seems little point in a boolean that will always be true if it is succesfully received but otherwise not received.<br />
<br />
ALFEvent -> EventNotice<br />
ALFEventACK -> EventNoticeResponse<br />
Note: this is to conform with the WSDL "Document Literal Wrapped" convention<br />
<br />
The following messages are added for "synchronous events" <br />
EventNoticeWithReply<br />
EventNoticeWithReplyResponse<br />
<br />
The EventNoticeWithReply operations is added to the ALFEventManager service<br />
<br />
Some new ports and corresponding bindings are added to provide the base template for Service Flow services ALFServiceFlow ALFServiceFlowWithReply<br />
<br />
'''9. The Credential element should be typed "any".'''<br />
It is likely that the credential element will be expressed as XML. It may be more covenient to contain such an element as an XML structure rather than by having it encoded or encapsualted as CData. may the CredentialType "any" allows it to take any of these formats<br />
<br />
== Additional Changes ==<br />
Listed below are some other possible simplifications and name changes. These need some some further discussion/definition before we accept them.<br />
<br />
==='''1. Combine Detail and Extension to a single xs:any element perhaps called <payload>.'''===<br />
<br />
It is not clear to me there is an advantage in keeping these separate. If there is we need to make that clear. It would seem adequate to me that a tool would declare its event data and that it will either be a pure ALF vocab structure or it will be custom or it will be some combination. Forcing the division seems like it will just make it inconvenient for tools to declare their data and will mean either misuse or no use of the ALF vocabulary.<br />
<br />
==='''2. Eliminate the "required" attributes.'''===<br />
<br />
''alfEventVersion'' on EventBaseType (nee BasicEventType) I realise the intent is to inform the recipient that the event definition is derived froma particular verision and possibly this is useful a runtime since it would possibly allow use to handle incompatible versions. This seem somewhat unlikely at this level at which it works. Maybe it is cheap enough to make that enough but something bothers me about it and I suspect that it will never be used. It is something that can be added if we ever do need it but for now it's just extra crud someone has to set before sending the event that doesn't do anything. If we have it, it seem like the schema should define the exact value it must contain.<br />
<br />
''schemaLocation'' on EventDetailType (nee EventDetailsType) and EventExtensionType (nee ToolExtensionData) I realise these attributes are supposed to point to the schema for the contained data but I'm not sure what the point of these attributes really is from a practical perspective. It seems to me nothing at runtime will look at these and validate the element content so perhaps they are just gratuitous and unecessary. Possibly there is a clearer way to do this since we do need tools to declare their events. Possibly the schema attribute, if we have it, needs to be higher up in the event structure.<br />
<br />
==='''3. Change ProductCallbackURI to ProductCallbackURL'''.===<br />
<br />
I think ''Callback'' implies it must be an URL and not just a URI. I'm a bit unclear how this would be used. I think it may need some more definition to make it useful. Does it define a server, a service, an operation ??? If I was trying to design to it I would presumably need a WSDL which presumably would need to be defined as part of the event declaration.<br />
<br />
==='''4. Eliminate the BaseEvent structure in the ALFEventResponse message.'''===<br />
<br />
Currently the event manager sends back the EventBase structure that it received. I'm not sure if there was a purpose to this. It seems unecessary to send the whole structure and other information might be useful also like an indication that the event matched to a service flow. Probably worth a discussion before we put it to bed.<br />
<br />
== Schema 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventBase_001.xsd | ALFEventBase_001.xsd]]<br />
<br />
== WSDL 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventManager_001.WSDL | ALFEventManager_001.WSDL]]</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/architecture/ALF_Schemas_001&diff=11964ALF/architecture/ALF Schemas 0012006-09-27T20:44:03Z<p>Alf tbuss.yahoo.com: /* WSDL 001 */</p>
<hr />
<div>__TOC__ <br />
[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
<br />
== Introduction ==<br />
'''ALF Event Manager Schemas and WSDL version 001'''<br />
<br />
We have been reviewing the ALF Event Schema and our recommendation is that if should be flattened and simplified. Here the details of our suggestions and reasoning so far. The proposed schema is just for illustration and should not <br />
be considered final. Please respond with any comments you may have and any other suggestions about way to streamline the ALF event Schema. <br />
<br />
Here are the details of the changes which have undergone some review and will be likely be adopted. These changes are refected in the Schema and WSDL below<br />
<br />
<br />
'''1. Eliminate a nesting level between BasicEventType and Event Data.'''<br />
<br />
This serves no particular purpose except to separate it from the Context Array which is not returned on an ACK. If we eliminate the Context Array as I suggest below then this distinction is no longer required.<br />
<br />
<br />
'''2. Eliminate the Object Array in favor of a single ObjectType.'''<br />
<br />
This is in BasicEventType. It seems to me that is very rare that we will encounter a situation where a tool cannot provide a single identity to use to call back for additional information. While the array and related "relationship" attribute may be potentially powerful it would seem better relegated to a potential common vocabulary type for vocabulary or tool specific event details. The only potential issue is that removing the array from the basic event also removes it from the consideration as part of an ALF event manager dispatch rule. Currently we only use the first object in the array. This seems a reasonable price to pay The array seems somewhat complex for that purpose due to its rather arbitrary nature and, if we find we are really missing it later we have the option of extending the Basic Event to include an array of this nature in addition to the primary object.<br />
<br />
<br />
'''3. Eliminate the Context Array'''<br />
<br />
We should also merge the current user details into the BasicEventType. The context array does not seem that useful to me. It just makes the current context harder to discern. Further, it does not seem to be desirable from a security standpoint to be passing around arrays of credentials. I don't see any particular programmatic use of this feature and a simple log or a relationship store would be a better method of tracing contexts after the event. Even if it is of some practical use, that use relies on the support to tools to return the context in full in an event. This seems unlikely except by the most avid of ALF participating tools rendering it useless in the foreseeable future.<br />
<br />
'''4.Eliminate "InitiatingFlow" and the "nesting" attribute'''<br />
<br />
This is an aspect of the Context. This does not provide much useful information and again relies on all participants to behave the ALF way in order for the nesting counter to accurate. Instead provide some preceding IDs ( see below) and rely on logging. I am unclear whether it would be useful to know if the event comes from a user interaction or a service flow. It would seem to me likely that that this can be inferred from the event type and event product information and not explicit flag is required. I am unclear what you would do with it in any case. Thus I would just eliminate it.<br />
<br />
<br />
'''5. Add "PrecedingEvent" and "PrecedingServiceFlow" to the Basic Event Type as nillable elements.'''<br />
<br />
If the event is generated in the directly by a service flow then the ServiceFlow will fill these, identifying itself and the event that initiated it. Optionally an ALF compliant service may take this data and return it in any event it generates. The Source elements can be used to distinguish the cases.<br />
<br />
<br />
'''6. Add a ALFEventNoACK element and associated Type.'''<br />
<br />
Async Service flows have this type. Unfortunately the Event Manager currently dispatches using ALFEventACK which is incorrect and confusing. (Note: this change and been subsumed by the name changes describe in 8. below)<br />
<br />
<br />
'''7. Eliminate the use of the "mixed" attribute.'''<br />
<br />
I believed the used of the attribute "mixed" is incorrect. This attribute means that and element can contain both content text and other elements. I don't think that is the intent. Its use here appears to be associated with the use of an attribute which is incorrect.<br />
<br />
<br />
'''8. "Clean up" or "Gratuitously change" some names.'''<br />
<br />
The purpose is to make things feel a bit more consistent and this is really our last chance to do so.<br />
<br />
The suggested changes are as follows:<br />
<br />
The schema file will be called ALFEventBase.xsd<br />
<br />
BasicEventType -> EventBaseType<br />
EventDetailsType -> EventDetailType<br />
ToolExtensionDataType -> EventExtensionType BasicEvent -> Base EventDetails -> Detail ToolExtensionData -> Extension<br />
<br />
ALFEventACKType -> ALFEventResponseType<br />
Note: The bool value is eliminated from this since there seems little point in a boolean that will always be true if it is succesfully received but otherwise not received.<br />
<br />
ALFEvent -> EventNotice<br />
ALFEventACK -> EventNoticeResponse<br />
Note: this is to conform with the WSDL "Document Literal Wrapped" convention<br />
<br />
The following messages are added for "synchronous events" <br />
EventNoticeWithReply<br />
EventNoticeWithReplyResponse<br />
<br />
The EventNoticeWithReply operations is added to the ALFEventManager service<br />
<br />
Some new ports and corresponding bindings are added to provide the base template for Service Flow services ALFServiceFlow ALFServiceFlowWithReply<br />
<br />
'''9. The Credential element should be typed "any".'''<br />
It is likely that the credential element will be expressed as XML. It may be more covenient to contain such an element as an XML structure rather than by having it encoded or encapsualted as CData. may the CredentialType "any" allows it to take any of these formats<br />
<br />
== Additional Changes ==<br />
Listed below are some other possible simplifications and name changes. These need some some further discussion/definition before we accept them.<br />
<br />
'''1. Combine Detail and Extension to a single xs:any element perhaps called <payload>.'''<br />
<br />
It is not clear to me there is an advantage in keeping these separate. If there is we need to make that clear. It would seem adequate to me that a tool would declare its event data and that it will either be a pure ALF vocab structure or it will be custom or it will be some combination. Forcing the division seems like it will just make it inconvenient for tools to declare their data and will mean either misuse or no use of the ALF vocabulary.<br />
<br />
'''2. Eliminate the "required" attributes.'''<br />
<br />
''alfEventVersion'' on EventBaseType (nee BasicEventType) I realise the intent is to inform the recipient that the event definition is derived froma particular verision and possibly this is useful a runtime since it would possibly allow use to handle incompatible versions. This seem somewhat unlikely at this level at which it works. Maybe it is cheap enough to make that enough but something bothers me about it and I suspect that it will never be used. It is something that can be added if we ever do need it but for now it's just extra crud someone has to set before sending the event that doesn't do anything. If we have it, it seem like the schema should define the exact value it must contain.<br />
<br />
''schemaLocation'' on EventDetailType (nee EventDetailsType) and EventExtensionType (nee ToolExtensionData) I realise these attributes are supposed to point to the schema for the contained data but I'm not sure what the point of these attributes really is from a practical perspective. It seems to me nothing at runtime will look at these and validate the element content so perhaps they are just gratuitous and unecessary. Possibly there is a clearer way to do this since we do need tools to declare their events. Possibly the schema attribute, if we have it, needs to be higher up in the event structure.<br />
<br />
'''3. Change ProductCallbackURI to ProductCallbackURL'''.<br />
<br />
I think ''Callback'' implies it must be an URL and not just a URI. I'm a bit unclear how this would be used. I think it may need some more definition to make it useful. Does it define a server, a service, an operation ??? If I was trying to design to it I would presumably need a WSDL which presumably would need to be defined as part of the event declaration.<br />
<br />
'''4. Eliminate the BaseEvent structure in the ALFEventResponse message.'''<br />
<br />
Currently the event manager sends back the EventBase structure that it received. I'm not sure if there was a purpose to this. It seems unecessary to send the whole structure and other information might be useful also like an indication that the event matched to a service flow. Probably worth a discussion before we put it to bed.<br />
<br />
== Schema 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventBase_001.xsd | ALFEventBase_001.xsd]]<br />
<br />
== WSDL 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventManager_001.WSDL | ALFEventManager_001.WSDL]]</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/architecture/ALF_Schemas/ALFEventManager_001.WSDL&diff=11963ALF/architecture/ALF Schemas/ALFEventManager 001.WSDL2006-09-27T20:43:45Z<p>Alf tbuss.yahoo.com: </p>
<hr />
<div>== ALFEventManager_001.WSDL ==<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<wsdl:definitions name="ALFEventManager"<br />
targetNamespace="http://www.eclipse.org/alf/XMLSchema/Events.wsdl"<br />
xmlns:tns="http://www.eclipse.org/alf/XMLSchema/Events.wsdl"<br />
xmlns:evt="http://www.eclipse.org/alf/XMLSchema/Events.xsd"<br />
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"<br />
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"<br />
xmlns:xsd="http://www.w3.org/2001/XMLSchema"<br />
xmlns:xs="http://www.w3.org/2001/XMLSchema"<br />
><br />
<br />
<wsdl:documentation><br />
WARNING: PRELIMINARY VERSION DO NOT USE<br />
<br />
Copyright Notice<br />
The material in this document is Copyright (c) Serena Software, Inc. and others, 2005<br />
Terms and Conditions:<br />
The Eclipse Foundation makes available all content in this document ("Content").<br />
Unless otherwise indicated below, the Content is provided to you under the terms<br />
and conditions of the Eclipse Public License Version 1.0 ("EPL").<br />
A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html.<br />
For purposes of the EPL, "Program" will mean the Content.<br />
If you did not receive this Content directly from the Eclipse Foundation, the<br />
Content is being redistributed by another party ("Redistributor") and different<br />
terms and conditions may apply to your use of any object code in the Content.<br />
Check the Redistributor's license that was provided with the Content.<br />
If you did not receive any such license, contact the Redistributor.<br />
Unless otherwise indicated below, the terms and conditions of the EPL still apply to the Content.<br />
</wsdl:documentation><br />
<br />
<!-- ALF EventManager WSDL --> <br />
<wsdl:types><br />
<xsd:schema elementFormDefault="qualified" targetNamespace="http://www.eclipse.org/alf/XMLSchema/Events.xsd"<br />
xmlns:evt="http://www.eclipse.org/alf/XMLSchema/Events.xsd"<br />
xmlns="http://www.eclipse.org/alf/XMLSchema/Events.xsd"><br />
<xsd:include schemaLocation="ALFEventBase_001.xsd" /><br />
</xsd:schema><br />
</wsdl:types><br />
<br />
<wsdl:message name="EventNotice"><br />
<wsdl:part name="parameters" element="evt:EventNotice" /><br />
</wsdl:message><br />
<br />
<wsdl:message name="EventNoticeResponse"><br />
<wsdl:part name="parameters" element="evt:EventNoticeResponse" /><br />
</wsdl:message><br />
<br />
<wsdl:portType name="ALFEventManager"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:EventNotice"/><br />
<wsdl:output message="tns:EventNoticeResponse"/><br />
</wsdl:operation><br />
<wsdl:operation name="EventNoticeWithReply"><br />
<wsdl:input message="tns:EventNoticeWithReply"/><br />
<wsdl:output message="tns:EventNoticeWithReplyResponse"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
<wsdl:portType name="ALFServiceFlow"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:EventNotice"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
<wsdl:portType name="ALFServiceFlowWithReply"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:EventNotice"/><br />
<wsdl:output message="tns:EventNoticeResponse"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
<wsdl:binding name="ALFEventManagerSOAP" type="tns:ALFEventManager"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal"/><br />
</wsdl:output><br />
</wsdl:operation><br />
<wsdl:operation name="EventNoticeWithReply"><br />
<soap:operation soapAction="EventNoticeWithReply"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal"/><br />
</wsdl:output><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
<wsdl:binding name="ALFServiceFlowSOAP" type="tns:ALFServiceFlow"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
<wsdl:binding name="ALFServiceFlowWithReplySOAP" type="tns:ALFServiceFlowWithResponse"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal"/><br />
</wsdl:output><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
<!-- Example service location --><br />
<wsdl:service name="ALFEventManager"><br />
<wsdl:port binding="tns:ALFEventManagerSOAP" name="ALFEventManagerSOAP"><br />
<soap:address location="http://localhost:8080/alfeventmgr/services/ALFEventManager"/><br />
</wsdl:port><br />
</wsdl:service><br />
<br />
</wsdl:definitions><br />
</pre></div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/architecture/ALF_Schemas_001&diff=11962ALF/architecture/ALF Schemas 0012006-09-27T20:43:18Z<p>Alf tbuss.yahoo.com: /* WSDL 001 */</p>
<hr />
<div>__TOC__ <br />
[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
<br />
== Introduction ==<br />
'''ALF Event Manager Schemas and WSDL version 001'''<br />
<br />
We have been reviewing the ALF Event Schema and our recommendation is that if should be flattened and simplified. Here the details of our suggestions and reasoning so far. The proposed schema is just for illustration and should not <br />
be considered final. Please respond with any comments you may have and any other suggestions about way to streamline the ALF event Schema. <br />
<br />
Here are the details of the changes which have undergone some review and will be likely be adopted. These changes are refected in the Schema and WSDL below<br />
<br />
<br />
'''1. Eliminate a nesting level between BasicEventType and Event Data.'''<br />
<br />
This serves no particular purpose except to separate it from the Context Array which is not returned on an ACK. If we eliminate the Context Array as I suggest below then this distinction is no longer required.<br />
<br />
<br />
'''2. Eliminate the Object Array in favor of a single ObjectType.'''<br />
<br />
This is in BasicEventType. It seems to me that is very rare that we will encounter a situation where a tool cannot provide a single identity to use to call back for additional information. While the array and related "relationship" attribute may be potentially powerful it would seem better relegated to a potential common vocabulary type for vocabulary or tool specific event details. The only potential issue is that removing the array from the basic event also removes it from the consideration as part of an ALF event manager dispatch rule. Currently we only use the first object in the array. This seems a reasonable price to pay The array seems somewhat complex for that purpose due to its rather arbitrary nature and, if we find we are really missing it later we have the option of extending the Basic Event to include an array of this nature in addition to the primary object.<br />
<br />
<br />
'''3. Eliminate the Context Array'''<br />
<br />
We should also merge the current user details into the BasicEventType. The context array does not seem that useful to me. It just makes the current context harder to discern. Further, it does not seem to be desirable from a security standpoint to be passing around arrays of credentials. I don't see any particular programmatic use of this feature and a simple log or a relationship store would be a better method of tracing contexts after the event. Even if it is of some practical use, that use relies on the support to tools to return the context in full in an event. This seems unlikely except by the most avid of ALF participating tools rendering it useless in the foreseeable future.<br />
<br />
'''4.Eliminate "InitiatingFlow" and the "nesting" attribute'''<br />
<br />
This is an aspect of the Context. This does not provide much useful information and again relies on all participants to behave the ALF way in order for the nesting counter to accurate. Instead provide some preceding IDs ( see below) and rely on logging. I am unclear whether it would be useful to know if the event comes from a user interaction or a service flow. It would seem to me likely that that this can be inferred from the event type and event product information and not explicit flag is required. I am unclear what you would do with it in any case. Thus I would just eliminate it.<br />
<br />
<br />
'''5. Add "PrecedingEvent" and "PrecedingServiceFlow" to the Basic Event Type as nillable elements.'''<br />
<br />
If the event is generated in the directly by a service flow then the ServiceFlow will fill these, identifying itself and the event that initiated it. Optionally an ALF compliant service may take this data and return it in any event it generates. The Source elements can be used to distinguish the cases.<br />
<br />
<br />
'''6. Add a ALFEventNoACK element and associated Type.'''<br />
<br />
Async Service flows have this type. Unfortunately the Event Manager currently dispatches using ALFEventACK which is incorrect and confusing. (Note: this change and been subsumed by the name changes describe in 8. below)<br />
<br />
<br />
'''7. Eliminate the use of the "mixed" attribute.'''<br />
<br />
I believed the used of the attribute "mixed" is incorrect. This attribute means that and element can contain both content text and other elements. I don't think that is the intent. Its use here appears to be associated with the use of an attribute which is incorrect.<br />
<br />
<br />
'''8. "Clean up" or "Gratuitously change" some names.'''<br />
<br />
The purpose is to make things feel a bit more consistent and this is really our last chance to do so.<br />
<br />
The suggested changes are as follows:<br />
<br />
The schema file will be called ALFEventBase.xsd<br />
<br />
BasicEventType -> EventBaseType<br />
EventDetailsType -> EventDetailType<br />
ToolExtensionDataType -> EventExtensionType BasicEvent -> Base EventDetails -> Detail ToolExtensionData -> Extension<br />
<br />
ALFEventACKType -> ALFEventResponseType<br />
Note: The bool value is eliminated from this since there seems little point in a boolean that will always be true if it is succesfully received but otherwise not received.<br />
<br />
ALFEvent -> EventNotice<br />
ALFEventACK -> EventNoticeResponse<br />
Note: this is to conform with the WSDL "Document Literal Wrapped" convention<br />
<br />
The following messages are added for "synchronous events" <br />
EventNoticeWithReply<br />
EventNoticeWithReplyResponse<br />
<br />
The EventNoticeWithReply operations is added to the ALFEventManager service<br />
<br />
Some new ports and corresponding bindings are added to provide the base template for Service Flow services ALFServiceFlow ALFServiceFlowWithReply<br />
<br />
'''9. The Credential element should be typed "any".'''<br />
It is likely that the credential element will be expressed as XML. It may be more covenient to contain such an element as an XML structure rather than by having it encoded or encapsualted as CData. may the CredentialType "any" allows it to take any of these formats<br />
<br />
== Additional Changes ==<br />
Listed below are some other possible simplifications and name changes. These need some some further discussion/definition before we accept them.<br />
<br />
'''1. Combine Detail and Extension to a single xs:any element perhaps called <payload>.'''<br />
<br />
It is not clear to me there is an advantage in keeping these separate. If there is we need to make that clear. It would seem adequate to me that a tool would declare its event data and that it will either be a pure ALF vocab structure or it will be custom or it will be some combination. Forcing the division seems like it will just make it inconvenient for tools to declare their data and will mean either misuse or no use of the ALF vocabulary.<br />
<br />
'''2. Eliminate the "required" attributes.'''<br />
<br />
''alfEventVersion'' on EventBaseType (nee BasicEventType) I realise the intent is to inform the recipient that the event definition is derived froma particular verision and possibly this is useful a runtime since it would possibly allow use to handle incompatible versions. This seem somewhat unlikely at this level at which it works. Maybe it is cheap enough to make that enough but something bothers me about it and I suspect that it will never be used. It is something that can be added if we ever do need it but for now it's just extra crud someone has to set before sending the event that doesn't do anything. If we have it, it seem like the schema should define the exact value it must contain.<br />
<br />
''schemaLocation'' on EventDetailType (nee EventDetailsType) and EventExtensionType (nee ToolExtensionData) I realise these attributes are supposed to point to the schema for the contained data but I'm not sure what the point of these attributes really is from a practical perspective. It seems to me nothing at runtime will look at these and validate the element content so perhaps they are just gratuitous and unecessary. Possibly there is a clearer way to do this since we do need tools to declare their events. Possibly the schema attribute, if we have it, needs to be higher up in the event structure.<br />
<br />
'''3. Change ProductCallbackURI to ProductCallbackURL'''.<br />
<br />
I think ''Callback'' implies it must be an URL and not just a URI. I'm a bit unclear how this would be used. I think it may need some more definition to make it useful. Does it define a server, a service, an operation ??? If I was trying to design to it I would presumably need a WSDL which presumably would need to be defined as part of the event declaration.<br />
<br />
'''4. Eliminate the BaseEvent structure in the ALFEventResponse message.'''<br />
<br />
Currently the event manager sends back the EventBase structure that it received. I'm not sure if there was a purpose to this. It seems unecessary to send the whole structure and other information might be useful also like an indication that the event matched to a service flow. Probably worth a discussion before we put it to bed.<br />
<br />
== Schema 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventBase_001.xsd | ALFEventBase_001.xsd]]<br />
<br />
== WSDL 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventManager_001.WSDL | ALFEventManager_001.WSDL]]<br />
ALFEventManager_001.WSDL<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<wsdl:definitions name="ALFEventManager"<br />
targetNamespace="http://www.eclipse.org/alf/XMLSchema/Events.wsdl"<br />
xmlns:tns="http://www.eclipse.org/alf/XMLSchema/Events.wsdl"<br />
xmlns:evt="http://www.eclipse.org/alf/XMLSchema/Events.xsd"<br />
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"<br />
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"<br />
xmlns:xsd="http://www.w3.org/2001/XMLSchema"<br />
xmlns:xs="http://www.w3.org/2001/XMLSchema"<br />
><br />
<br />
<wsdl:documentation><br />
WARNING: PRELIMINARY VERSION DO NOT USE<br />
<br />
Copyright Notice<br />
The material in this document is Copyright (c) Serena Software, Inc. and others, 2005<br />
Terms and Conditions:<br />
The Eclipse Foundation makes available all content in this document ("Content").<br />
Unless otherwise indicated below, the Content is provided to you under the terms<br />
and conditions of the Eclipse Public License Version 1.0 ("EPL").<br />
A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html.<br />
For purposes of the EPL, "Program" will mean the Content.<br />
If you did not receive this Content directly from the Eclipse Foundation, the<br />
Content is being redistributed by another party ("Redistributor") and different<br />
terms and conditions may apply to your use of any object code in the Content.<br />
Check the Redistributor's license that was provided with the Content.<br />
If you did not receive any such license, contact the Redistributor.<br />
Unless otherwise indicated below, the terms and conditions of the EPL still apply to the Content.<br />
</wsdl:documentation><br />
<br />
<!-- ALF EventManager WSDL --> <br />
<wsdl:types><br />
<xsd:schema elementFormDefault="qualified" targetNamespace="http://www.eclipse.org/alf/XMLSchema/Events.xsd"<br />
xmlns:evt="http://www.eclipse.org/alf/XMLSchema/Events.xsd"<br />
xmlns="http://www.eclipse.org/alf/XMLSchema/Events.xsd"><br />
<xsd:include schemaLocation="ALFEventBase_001.xsd" /><br />
</xsd:schema><br />
</wsdl:types><br />
<br />
<wsdl:message name="EventNotice"><br />
<wsdl:part name="parameters" element="evt:EventNotice" /><br />
</wsdl:message><br />
<br />
<wsdl:message name="EventNoticeResponse"><br />
<wsdl:part name="parameters" element="evt:EventNoticeResponse" /><br />
</wsdl:message><br />
<br />
<wsdl:portType name="ALFEventManager"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:EventNotice"/><br />
<wsdl:output message="tns:EventNoticeResponse"/><br />
</wsdl:operation><br />
<wsdl:operation name="EventNoticeWithReply"><br />
<wsdl:input message="tns:EventNoticeWithReply"/><br />
<wsdl:output message="tns:EventNoticeWithReplyResponse"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
<wsdl:portType name="ALFServiceFlow"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:EventNotice"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
<wsdl:portType name="ALFServiceFlowWithReply"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:EventNotice"/><br />
<wsdl:output message="tns:EventNoticeResponse"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
<wsdl:binding name="ALFEventManagerSOAP" type="tns:ALFEventManager"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal"/><br />
</wsdl:output><br />
</wsdl:operation><br />
<wsdl:operation name="EventNoticeWithReply"><br />
<soap:operation soapAction="EventNoticeWithReply"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal"/><br />
</wsdl:output><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
<wsdl:binding name="ALFServiceFlowSOAP" type="tns:ALFServiceFlow"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
<wsdl:binding name="ALFServiceFlowWithReplySOAP" type="tns:ALFServiceFlowWithResponse"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal"/><br />
</wsdl:output><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
<!-- Example service location --><br />
<wsdl:service name="ALFEventManager"><br />
<wsdl:port binding="tns:ALFEventManagerSOAP" name="ALFEventManagerSOAP"><br />
<soap:address location="http://localhost:8080/alfeventmgr/services/ALFEventManager"/><br />
</wsdl:port><br />
</wsdl:service><br />
<br />
</wsdl:definitions><br />
</pre></div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/architecture/ALF_Schemas_001&diff=11961ALF/architecture/ALF Schemas 0012006-09-27T20:42:22Z<p>Alf tbuss.yahoo.com: /* Schema 001 */</p>
<hr />
<div>__TOC__ <br />
[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
<br />
== Introduction ==<br />
'''ALF Event Manager Schemas and WSDL version 001'''<br />
<br />
We have been reviewing the ALF Event Schema and our recommendation is that if should be flattened and simplified. Here the details of our suggestions and reasoning so far. The proposed schema is just for illustration and should not <br />
be considered final. Please respond with any comments you may have and any other suggestions about way to streamline the ALF event Schema. <br />
<br />
Here are the details of the changes which have undergone some review and will be likely be adopted. These changes are refected in the Schema and WSDL below<br />
<br />
<br />
'''1. Eliminate a nesting level between BasicEventType and Event Data.'''<br />
<br />
This serves no particular purpose except to separate it from the Context Array which is not returned on an ACK. If we eliminate the Context Array as I suggest below then this distinction is no longer required.<br />
<br />
<br />
'''2. Eliminate the Object Array in favor of a single ObjectType.'''<br />
<br />
This is in BasicEventType. It seems to me that is very rare that we will encounter a situation where a tool cannot provide a single identity to use to call back for additional information. While the array and related "relationship" attribute may be potentially powerful it would seem better relegated to a potential common vocabulary type for vocabulary or tool specific event details. The only potential issue is that removing the array from the basic event also removes it from the consideration as part of an ALF event manager dispatch rule. Currently we only use the first object in the array. This seems a reasonable price to pay The array seems somewhat complex for that purpose due to its rather arbitrary nature and, if we find we are really missing it later we have the option of extending the Basic Event to include an array of this nature in addition to the primary object.<br />
<br />
<br />
'''3. Eliminate the Context Array'''<br />
<br />
We should also merge the current user details into the BasicEventType. The context array does not seem that useful to me. It just makes the current context harder to discern. Further, it does not seem to be desirable from a security standpoint to be passing around arrays of credentials. I don't see any particular programmatic use of this feature and a simple log or a relationship store would be a better method of tracing contexts after the event. Even if it is of some practical use, that use relies on the support to tools to return the context in full in an event. This seems unlikely except by the most avid of ALF participating tools rendering it useless in the foreseeable future.<br />
<br />
'''4.Eliminate "InitiatingFlow" and the "nesting" attribute'''<br />
<br />
This is an aspect of the Context. This does not provide much useful information and again relies on all participants to behave the ALF way in order for the nesting counter to accurate. Instead provide some preceding IDs ( see below) and rely on logging. I am unclear whether it would be useful to know if the event comes from a user interaction or a service flow. It would seem to me likely that that this can be inferred from the event type and event product information and not explicit flag is required. I am unclear what you would do with it in any case. Thus I would just eliminate it.<br />
<br />
<br />
'''5. Add "PrecedingEvent" and "PrecedingServiceFlow" to the Basic Event Type as nillable elements.'''<br />
<br />
If the event is generated in the directly by a service flow then the ServiceFlow will fill these, identifying itself and the event that initiated it. Optionally an ALF compliant service may take this data and return it in any event it generates. The Source elements can be used to distinguish the cases.<br />
<br />
<br />
'''6. Add a ALFEventNoACK element and associated Type.'''<br />
<br />
Async Service flows have this type. Unfortunately the Event Manager currently dispatches using ALFEventACK which is incorrect and confusing. (Note: this change and been subsumed by the name changes describe in 8. below)<br />
<br />
<br />
'''7. Eliminate the use of the "mixed" attribute.'''<br />
<br />
I believed the used of the attribute "mixed" is incorrect. This attribute means that and element can contain both content text and other elements. I don't think that is the intent. Its use here appears to be associated with the use of an attribute which is incorrect.<br />
<br />
<br />
'''8. "Clean up" or "Gratuitously change" some names.'''<br />
<br />
The purpose is to make things feel a bit more consistent and this is really our last chance to do so.<br />
<br />
The suggested changes are as follows:<br />
<br />
The schema file will be called ALFEventBase.xsd<br />
<br />
BasicEventType -> EventBaseType<br />
EventDetailsType -> EventDetailType<br />
ToolExtensionDataType -> EventExtensionType BasicEvent -> Base EventDetails -> Detail ToolExtensionData -> Extension<br />
<br />
ALFEventACKType -> ALFEventResponseType<br />
Note: The bool value is eliminated from this since there seems little point in a boolean that will always be true if it is succesfully received but otherwise not received.<br />
<br />
ALFEvent -> EventNotice<br />
ALFEventACK -> EventNoticeResponse<br />
Note: this is to conform with the WSDL "Document Literal Wrapped" convention<br />
<br />
The following messages are added for "synchronous events" <br />
EventNoticeWithReply<br />
EventNoticeWithReplyResponse<br />
<br />
The EventNoticeWithReply operations is added to the ALFEventManager service<br />
<br />
Some new ports and corresponding bindings are added to provide the base template for Service Flow services ALFServiceFlow ALFServiceFlowWithReply<br />
<br />
'''9. The Credential element should be typed "any".'''<br />
It is likely that the credential element will be expressed as XML. It may be more covenient to contain such an element as an XML structure rather than by having it encoded or encapsualted as CData. may the CredentialType "any" allows it to take any of these formats<br />
<br />
== Additional Changes ==<br />
Listed below are some other possible simplifications and name changes. These need some some further discussion/definition before we accept them.<br />
<br />
'''1. Combine Detail and Extension to a single xs:any element perhaps called <payload>.'''<br />
<br />
It is not clear to me there is an advantage in keeping these separate. If there is we need to make that clear. It would seem adequate to me that a tool would declare its event data and that it will either be a pure ALF vocab structure or it will be custom or it will be some combination. Forcing the division seems like it will just make it inconvenient for tools to declare their data and will mean either misuse or no use of the ALF vocabulary.<br />
<br />
'''2. Eliminate the "required" attributes.'''<br />
<br />
''alfEventVersion'' on EventBaseType (nee BasicEventType) I realise the intent is to inform the recipient that the event definition is derived froma particular verision and possibly this is useful a runtime since it would possibly allow use to handle incompatible versions. This seem somewhat unlikely at this level at which it works. Maybe it is cheap enough to make that enough but something bothers me about it and I suspect that it will never be used. It is something that can be added if we ever do need it but for now it's just extra crud someone has to set before sending the event that doesn't do anything. If we have it, it seem like the schema should define the exact value it must contain.<br />
<br />
''schemaLocation'' on EventDetailType (nee EventDetailsType) and EventExtensionType (nee ToolExtensionData) I realise these attributes are supposed to point to the schema for the contained data but I'm not sure what the point of these attributes really is from a practical perspective. It seems to me nothing at runtime will look at these and validate the element content so perhaps they are just gratuitous and unecessary. Possibly there is a clearer way to do this since we do need tools to declare their events. Possibly the schema attribute, if we have it, needs to be higher up in the event structure.<br />
<br />
'''3. Change ProductCallbackURI to ProductCallbackURL'''.<br />
<br />
I think ''Callback'' implies it must be an URL and not just a URI. I'm a bit unclear how this would be used. I think it may need some more definition to make it useful. Does it define a server, a service, an operation ??? If I was trying to design to it I would presumably need a WSDL which presumably would need to be defined as part of the event declaration.<br />
<br />
'''4. Eliminate the BaseEvent structure in the ALFEventResponse message.'''<br />
<br />
Currently the event manager sends back the EventBase structure that it received. I'm not sure if there was a purpose to this. It seems unecessary to send the whole structure and other information might be useful also like an indication that the event matched to a service flow. Probably worth a discussion before we put it to bed.<br />
<br />
== Schema 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventBase_001.xsd | ALFEventBase_001.xsd]]<br />
<br />
== WSDL 001 ==<br />
ALFEventManager_001.WSDL<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<wsdl:definitions name="ALFEventManager"<br />
targetNamespace="http://www.eclipse.org/alf/XMLSchema/Events.wsdl"<br />
xmlns:tns="http://www.eclipse.org/alf/XMLSchema/Events.wsdl"<br />
xmlns:evt="http://www.eclipse.org/alf/XMLSchema/Events.xsd"<br />
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"<br />
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"<br />
xmlns:xsd="http://www.w3.org/2001/XMLSchema"<br />
xmlns:xs="http://www.w3.org/2001/XMLSchema"<br />
><br />
<br />
<wsdl:documentation><br />
WARNING: PRELIMINARY VERSION DO NOT USE<br />
<br />
Copyright Notice<br />
The material in this document is Copyright (c) Serena Software, Inc. and others, 2005<br />
Terms and Conditions:<br />
The Eclipse Foundation makes available all content in this document ("Content").<br />
Unless otherwise indicated below, the Content is provided to you under the terms<br />
and conditions of the Eclipse Public License Version 1.0 ("EPL").<br />
A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html.<br />
For purposes of the EPL, "Program" will mean the Content.<br />
If you did not receive this Content directly from the Eclipse Foundation, the<br />
Content is being redistributed by another party ("Redistributor") and different<br />
terms and conditions may apply to your use of any object code in the Content.<br />
Check the Redistributor's license that was provided with the Content.<br />
If you did not receive any such license, contact the Redistributor.<br />
Unless otherwise indicated below, the terms and conditions of the EPL still apply to the Content.<br />
</wsdl:documentation><br />
<br />
<!-- ALF EventManager WSDL --> <br />
<wsdl:types><br />
<xsd:schema elementFormDefault="qualified" targetNamespace="http://www.eclipse.org/alf/XMLSchema/Events.xsd"<br />
xmlns:evt="http://www.eclipse.org/alf/XMLSchema/Events.xsd"<br />
xmlns="http://www.eclipse.org/alf/XMLSchema/Events.xsd"><br />
<xsd:include schemaLocation="ALFEventBase_001.xsd" /><br />
</xsd:schema><br />
</wsdl:types><br />
<br />
<wsdl:message name="EventNotice"><br />
<wsdl:part name="parameters" element="evt:EventNotice" /><br />
</wsdl:message><br />
<br />
<wsdl:message name="EventNoticeResponse"><br />
<wsdl:part name="parameters" element="evt:EventNoticeResponse" /><br />
</wsdl:message><br />
<br />
<wsdl:portType name="ALFEventManager"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:EventNotice"/><br />
<wsdl:output message="tns:EventNoticeResponse"/><br />
</wsdl:operation><br />
<wsdl:operation name="EventNoticeWithReply"><br />
<wsdl:input message="tns:EventNoticeWithReply"/><br />
<wsdl:output message="tns:EventNoticeWithReplyResponse"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
<wsdl:portType name="ALFServiceFlow"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:EventNotice"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
<wsdl:portType name="ALFServiceFlowWithReply"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:EventNotice"/><br />
<wsdl:output message="tns:EventNoticeResponse"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
<wsdl:binding name="ALFEventManagerSOAP" type="tns:ALFEventManager"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal"/><br />
</wsdl:output><br />
</wsdl:operation><br />
<wsdl:operation name="EventNoticeWithReply"><br />
<soap:operation soapAction="EventNoticeWithReply"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal"/><br />
</wsdl:output><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
<wsdl:binding name="ALFServiceFlowSOAP" type="tns:ALFServiceFlow"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
<wsdl:binding name="ALFServiceFlowWithReplySOAP" type="tns:ALFServiceFlowWithResponse"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal"/><br />
</wsdl:output><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
<!-- Example service location --><br />
<wsdl:service name="ALFEventManager"><br />
<wsdl:port binding="tns:ALFEventManagerSOAP" name="ALFEventManagerSOAP"><br />
<soap:address location="http://localhost:8080/alfeventmgr/services/ALFEventManager"/><br />
</wsdl:port><br />
</wsdl:service><br />
<br />
</wsdl:definitions><br />
</pre></div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/architecture/ALF_Schemas/ALFEventBase_001.xsd&diff=11960ALF/architecture/ALF Schemas/ALFEventBase 001.xsd2006-09-27T20:41:52Z<p>Alf tbuss.yahoo.com: </p>
<hr />
<div>== ALFEventBase_001.xsd ==<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<xs:schema <br />
xmlns:xs="http://www.w3.org/2001/XMLSchema" <br />
xmlns:evt="http://www.eclipse.org/alf/XMLSchema/Events.xsd" <br />
xmlns="http://www.eclipse.org/alf/XMLSchema/Events.xsd" <br />
targetNamespace="http://www.eclipse.org/alf/XMLSchema/Events.xsd" <br />
elementFormDefault="qualified" <br />
attributeFormDefault="unqualified"><br />
<xs:annotation><br />
<xs:documentation><br />
WARNING: PRELIMINARY VERSION<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:annotation><br />
<xs:documentation><br />
Copyright Notice<br />
The material in this document is Copyright (c) Serena Software, Inc. and others, 2005<br />
Terms and Conditions:<br />
The Eclipse Foundation makes available all content in this document ("Content").<br />
Unless otherwise indicated below, the Content is provided to you under the terms<br />
and conditions of the Eclipse Public License Version 1.0 ("EPL").<br />
A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html.<br />
For purposes of the EPL, "Program" will mean the Content.<br />
If you did not receive this Content directly from the Eclipse Foundation, the<br />
Content is being redistributed by another party ("Redistributor") and different<br />
terms and conditions may apply to your use of any object code in the Content.<br />
Check the Redistributor's license that was provided with the Content.<br />
If you did not receive any such license, contact the Redistributor.<br />
Unless otherwise indicated below, the terms and conditions of the EPL still apply to the Content.<br />
</xs:documentation><br />
</xs:annotation><br />
<!-- Begin EventBaseTypes --><br />
<xs:complexType name="EventBaseType"><br />
<xs:annotation><br />
<xs:documentation><br />
EventBaseType is a container for that portion of an ALF Event that is<br />
inspected by the ALF EventManager.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:sequence><br />
<xs:element name="EventID" type="EventIDType"/><br />
<xs:element name="Timestamp" type="TimestampType"/><br />
<xs:element name="EventType" type="EventTypeType"/><br />
<xs:element name="Object" type="ObjectDataType"/><br />
<xs:element name="Source" type="SourceType"/><br />
<xs:element name="PredecedingEvent" type="EventIDType" nillable="true"/><br />
<xs:element name="ApplicationName" type="ApplicationNameType" nillable="true"/><br />
<xs:element name="Environment" type="EnvironmentType" nillable="true"/><br />
<xs:element name="User" type="UserType"/><br />
</xs:sequence><br />
<xs:attribute name="alfEventVersion" type="xs:string" use="required"/><br />
</xs:complexType><br />
<xs:simpleType name="EventIDType"><br />
<xs:annotation><br />
<xs:documentation><br />
A UUID that uniquely identifies the Event instance.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"><br />
<xs:maxLength value="36"/><br />
</xs:restriction><br />
</xs:simpleType><br />
<xs:simpleType name="TimestampType"><br />
<xs:annotation><br />
<xs:documentation><br />
The date and timestamp when the EventManager received the Event.<br />
This element may be left empty by the event emitter, in which case,<br />
the Event Manager will supply a value.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:dateTime"/><br />
</xs:simpleType><br />
<xs:simpleType name="EventTypeType"><br />
<xs:annotation><br />
<xs:documentation><br />
A string indicating the type of event. EventType designates the verb.<br />
That is what action happened to the Objects that triggered the event.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<!-- ============= Array of Objects that triggered the event ============= --><br />
<xs:complexType name="ObjectDataType"><br />
<xs:annotation><br />
<xs:documentation><br />
A container for the identification of the objects that the tool was operating on.<br />
The purpose of the Object element is to identify the entity<br />
that was being operated on and which caused the event.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:sequence><br />
<xs:element name="ObjectType" type="ObjectTypeType"/><br />
<xs:element name="ObjectId" type="ObjectIdType"/><br />
</xs:sequence><br />
</xs:complexType><br />
<xs:simpleType name="ObjectIdType"><br />
<xs:annotation><br />
<xs:documentation><br />
An ObjectId identifies the entity or relationship that changed within a tool.<br />
The identifier must be unique for a particular instance of the source tool.<br />
The format of this element will not be standardized by ALF.<br />
The primary purpose is to allow subsequent ServiceFlows to uniquely identify<br />
(and perhaps access) the object that triggered the event.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<xs:simpleType name="ObjectTypeType"><br />
<xs:annotation><br />
<xs:documentation><br />
The type of entity involved. Note that the word entity is taken in<br />
its broadest sense, referring to whatever artifact a tool was operating on.<br />
For example, for a data modeling tool, an E-R relationship is a type of<br />
entity (i.e., and ObjectType) to ALF. The following are Object types enumerated by ALF:<br />
Business Activity<br />
Business Entity<br />
Business Process<br />
Individual<br />
Organization<br />
Oganizational Unit<br />
Role<br />
Use Case<br />
Business Location<br />
Entity<br />
Relationship<br />
System<br />
Model<br />
Source code<br />
Database<br />
Table<br />
Column<br />
File<br />
Folder<br />
Application<br />
Host<br />
Network<br />
Protocol<br />
Build<br />
Test<br />
Test Plan<br />
Test Result<br />
Workflow Item<br />
Requirement<br />
Request<br />
Issue<br />
Version<br />
Configuration<br />
Baseline<br />
Project<br />
Package<br />
Business Realm<br />
Logical Realm<br />
Physical Design Realm<br />
System Implementation Realm<br />
System Operations Realm<br />
Cross-Realm Infrastructure<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<!-- ============= The source (i.e, tool or product) that emitted the event ============= --><br />
<xs:complexType name="SourceType"><br />
<xs:annotation><br />
<xs:documentation><br />
A Source element is a container type that describes the source of the event.<br />
ProductCallbackURI is optional for tools that don't provide a listener to<br />
accept the callback from a tool or serviceflow at a later time.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:sequence><br />
<xs:element name="Product" type="ProductType"/><br />
<xs:element name="ProductVersion" type="ProductVersionType"/><br />
<xs:element name="ProductInstance" type="ProductInstanceType"/><br />
<xs:element name="ProductCallbackURI" type="ProductCallbackURIType" nillable="true" minOccurs="0"/><br />
</xs:sequence><br />
</xs:complexType><br />
<xs:simpleType name="ProductType"><br />
<xs:annotation><br />
<xs:documentation><br />
A descriptive name for the tool (i.e., program) that emitted the Event. Note that<br />
this is a datatype for a Product element.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<xs:simpleType name="ProductCallbackURIType"><br />
<xs:annotation><br />
<xs:documentation><br />
The web service endpoint for tools that support callbacks from<br />
ServiceFlows for additional information.<br />
The element content is optional for transient tools that may not be running<br />
at a later time, and so cannot accept a callback.<br />
Constantly running (server) tools that support callbacks should supply a URI.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<xs:simpleType name="ProductInstanceType"><br />
<xs:annotation><br />
<xs:documentation><br />
A unique string identifying the instance of the tool.<br />
This is useful when there may be multiple instances of a product working<br />
within an instance of ALF.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<xs:simpleType name="ProductVersionType"><br />
<xs:annotation><br />
<xs:documentation><br />
The release version of the product, such as 5.06<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<!-- ====== The user (or userid) providing the context when the event occurred ======= --><br />
<xs:complexType name="UserType"><br />
<xs:annotation><br />
<xs:documentation><br />
A container for elements that identify the end user and his/her credentials.<br />
Note on possible future change: As the ALF Security work is progressing, we may eliminate<br />
the Credentials element here and move it to the SOAP Header.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:sequence><br />
<xs:element name="CommonName" type="CommonNameType" nillable="true"/><br />
<xs:element name="LoginID" type="LoginIDType"/><br />
<xs:element name="Credentials" type="CredentialsType" nillable="true"/><br />
</xs:sequence><br />
</xs:complexType><br />
<xs:simpleType name="CommonNameType"><br />
<xs:annotation><br />
<xs:documentation><br />
The first name and surname name of the user. The exact format may<br />
vary from locale to locale.<br />
If the emitting tool does not know this information, the element is optional.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<xs:simpleType name="LoginIDType"><br />
<xs:annotation><br />
<xs:documentation><br />
The ID of the user when they authenticated to the tool that emitted the event.<br />
For tools running under the control of a ServiceFlow, the LoginID will be the<br />
user id presented by the ServiceFlow.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<xs:complexType name="CredentialsType"><br />
<xs:annotation><br />
<xs:documentation><br />
A Credentials element contains the security credentials that may be passed among<br />
tools that operate as part of a ServiceFlow.<br />
ALF SSO leverages WS-Security which passes credential information as part ot hte SOAP header. <br />
When ALF SSO is use this Credential element should be unecessary and will be nilled<br />
When ALF SSO is not being used or there are mixed security methods, the credential field may be used to pass a security credential <br />
through the event to the service flow.<br />
If present this element may be encrypted.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:sequence><br />
<xs:any/><br />
</xs:sequence><br />
</xs:complexType><br />
<xs:simpleType name="ApplicationNameType"><br />
<xs:annotation><br />
<xs:documentation><br />
The name of the ALF application to which this event belongs. Depending on the emitting tool, events may or may not be associated with an ALF application.<br />
If the emitting tool has the information available then it can provide the ALF ApplicationName as an additional information to distinguish the event.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<xs:simpleType name="EnvironmentType"><br />
<xs:annotation><br />
<xs:documentation><br />
The name of the environment in which this event is bing raised. This element will be set by the ALF Event manager from its installation configuration.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<xs:complexType name="EventDetailType"><br />
<xs:annotation><br />
<xs:documentation><br />
This element conveys the detailed information about the object that triggered the event,<br />
for example about a file that was checked into a configuration management tool.<br />
For the purposes of the EventBase, this element will be of type xs:any.<br />
The structure of this portion of the message will be specified by XML Schemas developed<br />
by the ALF Vocabulary Committees.<br />
This area will be passed through by the EventManager, and will not be examined by the<br />
Event Manager.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:sequence><br />
<xs:any/><br />
</xs:sequence><br />
<xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/><br />
</xs:complexType><br />
<xs:complexType name="EventExtensionType"><br />
<xs:annotation><br />
<xs:documentation><br />
This element conveys the detailed information that is tool-specific and goes beyond the<br />
information defined by the ALF Vocabularies.<br />
For the purposes of the EventBase, this element will be of type xs:any.<br />
The concrete structure of this portion of the message will be defined by concrete schemas that<br />
include XML Schemas defining the tool-specific structure.<br />
This area will be passed through by the EventManager, and will not be examined by the Event Manager.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:sequence><br />
<xs:any/><br />
</xs:sequence><br />
<xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/><br />
</xs:complexType><br />
<!-- End EventBaseTypes --><br />
<!-- BEGIN ALFEvent --><br />
<xs:complexType name="ALFEventType"><br />
<xs:sequence><br />
<xs:element name="Base" type="EventBaseType"/><br />
<xs:element name="Detail" type="EventDetailType"/><br />
<xs:element name="Extension" type="EventExtensionType"/><br />
</xs:sequence><br />
<xs:attribute name="version" type="xs:string" use="required"/><br />
</xs:complexType><br />
<xs:complexType name="ALFEventResponseType"><br />
<xs:sequence><br />
<xs:element name="Base" type="EventBaseType"/><br />
</xs:sequence><br />
</xs:complexType><br />
<xs:complexType name="ALFEventWithReplyResponseType"><br />
<xs:sequence><br />
<xs:element name="Base" type="EventBaseType"/><br />
<xs:any/><br />
</xs:sequence><br />
</xs:complexType><br />
<!-- END ALFEvent --><br />
<!-- Event Notice --><br />
<xs:element name="EventNotice" type="ALFEventType"/><br />
<xs:element name="EventNoticeResponse" type="ALFEventResponseType"/><br />
<xs:element name="EventNoticeWithReply" type="ALFEventType"/><br />
<xs:element name="EventNoticeWithReplyResponse" type="ALFEventWithReplyResponseType"/><br />
</xs:schema><br />
<br />
</pre></div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/architecture/ALF_Schemas_001&diff=11959ALF/architecture/ALF Schemas 0012006-09-27T20:40:53Z<p>Alf tbuss.yahoo.com: /* Schema 001 */</p>
<hr />
<div>__TOC__ <br />
[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
<br />
== Introduction ==<br />
'''ALF Event Manager Schemas and WSDL version 001'''<br />
<br />
We have been reviewing the ALF Event Schema and our recommendation is that if should be flattened and simplified. Here the details of our suggestions and reasoning so far. The proposed schema is just for illustration and should not <br />
be considered final. Please respond with any comments you may have and any other suggestions about way to streamline the ALF event Schema. <br />
<br />
Here are the details of the changes which have undergone some review and will be likely be adopted. These changes are refected in the Schema and WSDL below<br />
<br />
<br />
'''1. Eliminate a nesting level between BasicEventType and Event Data.'''<br />
<br />
This serves no particular purpose except to separate it from the Context Array which is not returned on an ACK. If we eliminate the Context Array as I suggest below then this distinction is no longer required.<br />
<br />
<br />
'''2. Eliminate the Object Array in favor of a single ObjectType.'''<br />
<br />
This is in BasicEventType. It seems to me that is very rare that we will encounter a situation where a tool cannot provide a single identity to use to call back for additional information. While the array and related "relationship" attribute may be potentially powerful it would seem better relegated to a potential common vocabulary type for vocabulary or tool specific event details. The only potential issue is that removing the array from the basic event also removes it from the consideration as part of an ALF event manager dispatch rule. Currently we only use the first object in the array. This seems a reasonable price to pay The array seems somewhat complex for that purpose due to its rather arbitrary nature and, if we find we are really missing it later we have the option of extending the Basic Event to include an array of this nature in addition to the primary object.<br />
<br />
<br />
'''3. Eliminate the Context Array'''<br />
<br />
We should also merge the current user details into the BasicEventType. The context array does not seem that useful to me. It just makes the current context harder to discern. Further, it does not seem to be desirable from a security standpoint to be passing around arrays of credentials. I don't see any particular programmatic use of this feature and a simple log or a relationship store would be a better method of tracing contexts after the event. Even if it is of some practical use, that use relies on the support to tools to return the context in full in an event. This seems unlikely except by the most avid of ALF participating tools rendering it useless in the foreseeable future.<br />
<br />
'''4.Eliminate "InitiatingFlow" and the "nesting" attribute'''<br />
<br />
This is an aspect of the Context. This does not provide much useful information and again relies on all participants to behave the ALF way in order for the nesting counter to accurate. Instead provide some preceding IDs ( see below) and rely on logging. I am unclear whether it would be useful to know if the event comes from a user interaction or a service flow. It would seem to me likely that that this can be inferred from the event type and event product information and not explicit flag is required. I am unclear what you would do with it in any case. Thus I would just eliminate it.<br />
<br />
<br />
'''5. Add "PrecedingEvent" and "PrecedingServiceFlow" to the Basic Event Type as nillable elements.'''<br />
<br />
If the event is generated in the directly by a service flow then the ServiceFlow will fill these, identifying itself and the event that initiated it. Optionally an ALF compliant service may take this data and return it in any event it generates. The Source elements can be used to distinguish the cases.<br />
<br />
<br />
'''6. Add a ALFEventNoACK element and associated Type.'''<br />
<br />
Async Service flows have this type. Unfortunately the Event Manager currently dispatches using ALFEventACK which is incorrect and confusing. (Note: this change and been subsumed by the name changes describe in 8. below)<br />
<br />
<br />
'''7. Eliminate the use of the "mixed" attribute.'''<br />
<br />
I believed the used of the attribute "mixed" is incorrect. This attribute means that and element can contain both content text and other elements. I don't think that is the intent. Its use here appears to be associated with the use of an attribute which is incorrect.<br />
<br />
<br />
'''8. "Clean up" or "Gratuitously change" some names.'''<br />
<br />
The purpose is to make things feel a bit more consistent and this is really our last chance to do so.<br />
<br />
The suggested changes are as follows:<br />
<br />
The schema file will be called ALFEventBase.xsd<br />
<br />
BasicEventType -> EventBaseType<br />
EventDetailsType -> EventDetailType<br />
ToolExtensionDataType -> EventExtensionType BasicEvent -> Base EventDetails -> Detail ToolExtensionData -> Extension<br />
<br />
ALFEventACKType -> ALFEventResponseType<br />
Note: The bool value is eliminated from this since there seems little point in a boolean that will always be true if it is succesfully received but otherwise not received.<br />
<br />
ALFEvent -> EventNotice<br />
ALFEventACK -> EventNoticeResponse<br />
Note: this is to conform with the WSDL "Document Literal Wrapped" convention<br />
<br />
The following messages are added for "synchronous events" <br />
EventNoticeWithReply<br />
EventNoticeWithReplyResponse<br />
<br />
The EventNoticeWithReply operations is added to the ALFEventManager service<br />
<br />
Some new ports and corresponding bindings are added to provide the base template for Service Flow services ALFServiceFlow ALFServiceFlowWithReply<br />
<br />
'''9. The Credential element should be typed "any".'''<br />
It is likely that the credential element will be expressed as XML. It may be more covenient to contain such an element as an XML structure rather than by having it encoded or encapsualted as CData. may the CredentialType "any" allows it to take any of these formats<br />
<br />
== Additional Changes ==<br />
Listed below are some other possible simplifications and name changes. These need some some further discussion/definition before we accept them.<br />
<br />
'''1. Combine Detail and Extension to a single xs:any element perhaps called <payload>.'''<br />
<br />
It is not clear to me there is an advantage in keeping these separate. If there is we need to make that clear. It would seem adequate to me that a tool would declare its event data and that it will either be a pure ALF vocab structure or it will be custom or it will be some combination. Forcing the division seems like it will just make it inconvenient for tools to declare their data and will mean either misuse or no use of the ALF vocabulary.<br />
<br />
'''2. Eliminate the "required" attributes.'''<br />
<br />
''alfEventVersion'' on EventBaseType (nee BasicEventType) I realise the intent is to inform the recipient that the event definition is derived froma particular verision and possibly this is useful a runtime since it would possibly allow use to handle incompatible versions. This seem somewhat unlikely at this level at which it works. Maybe it is cheap enough to make that enough but something bothers me about it and I suspect that it will never be used. It is something that can be added if we ever do need it but for now it's just extra crud someone has to set before sending the event that doesn't do anything. If we have it, it seem like the schema should define the exact value it must contain.<br />
<br />
''schemaLocation'' on EventDetailType (nee EventDetailsType) and EventExtensionType (nee ToolExtensionData) I realise these attributes are supposed to point to the schema for the contained data but I'm not sure what the point of these attributes really is from a practical perspective. It seems to me nothing at runtime will look at these and validate the element content so perhaps they are just gratuitous and unecessary. Possibly there is a clearer way to do this since we do need tools to declare their events. Possibly the schema attribute, if we have it, needs to be higher up in the event structure.<br />
<br />
'''3. Change ProductCallbackURI to ProductCallbackURL'''.<br />
<br />
I think ''Callback'' implies it must be an URL and not just a URI. I'm a bit unclear how this would be used. I think it may need some more definition to make it useful. Does it define a server, a service, an operation ??? If I was trying to design to it I would presumably need a WSDL which presumably would need to be defined as part of the event declaration.<br />
<br />
'''4. Eliminate the BaseEvent structure in the ALFEventResponse message.'''<br />
<br />
Currently the event manager sends back the EventBase structure that it received. I'm not sure if there was a purpose to this. It seems unecessary to send the whole structure and other information might be useful also like an indication that the event matched to a service flow. Probably worth a discussion before we put it to bed.<br />
<br />
== Schema 001 ==<br />
[[ALF/architecture/ALF_Schemas/ALFEventBase_001.xsd | ALFEventBase_001.xsd]]<br />
ALFEventBase_001.xsd<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<xs:schema <br />
xmlns:xs="http://www.w3.org/2001/XMLSchema" <br />
xmlns:evt="http://www.eclipse.org/alf/XMLSchema/Events.xsd" <br />
xmlns="http://www.eclipse.org/alf/XMLSchema/Events.xsd" <br />
targetNamespace="http://www.eclipse.org/alf/XMLSchema/Events.xsd" <br />
elementFormDefault="qualified" <br />
attributeFormDefault="unqualified"><br />
<xs:annotation><br />
<xs:documentation><br />
WARNING: PRELIMINARY VERSION<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:annotation><br />
<xs:documentation><br />
Copyright Notice<br />
The material in this document is Copyright (c) Serena Software, Inc. and others, 2005<br />
Terms and Conditions:<br />
The Eclipse Foundation makes available all content in this document ("Content").<br />
Unless otherwise indicated below, the Content is provided to you under the terms<br />
and conditions of the Eclipse Public License Version 1.0 ("EPL").<br />
A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html.<br />
For purposes of the EPL, "Program" will mean the Content.<br />
If you did not receive this Content directly from the Eclipse Foundation, the<br />
Content is being redistributed by another party ("Redistributor") and different<br />
terms and conditions may apply to your use of any object code in the Content.<br />
Check the Redistributor's license that was provided with the Content.<br />
If you did not receive any such license, contact the Redistributor.<br />
Unless otherwise indicated below, the terms and conditions of the EPL still apply to the Content.<br />
</xs:documentation><br />
</xs:annotation><br />
<!-- Begin EventBaseTypes --><br />
<xs:complexType name="EventBaseType"><br />
<xs:annotation><br />
<xs:documentation><br />
EventBaseType is a container for that portion of an ALF Event that is<br />
inspected by the ALF EventManager.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:sequence><br />
<xs:element name="EventID" type="EventIDType"/><br />
<xs:element name="Timestamp" type="TimestampType"/><br />
<xs:element name="EventType" type="EventTypeType"/><br />
<xs:element name="Object" type="ObjectDataType"/><br />
<xs:element name="Source" type="SourceType"/><br />
<xs:element name="PredecedingEvent" type="EventIDType" nillable="true"/><br />
<xs:element name="ApplicationName" type="ApplicationNameType" nillable="true"/><br />
<xs:element name="Environment" type="EnvironmentType" nillable="true"/><br />
<xs:element name="User" type="UserType"/><br />
</xs:sequence><br />
<xs:attribute name="alfEventVersion" type="xs:string" use="required"/><br />
</xs:complexType><br />
<xs:simpleType name="EventIDType"><br />
<xs:annotation><br />
<xs:documentation><br />
A UUID that uniquely identifies the Event instance.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"><br />
<xs:maxLength value="36"/><br />
</xs:restriction><br />
</xs:simpleType><br />
<xs:simpleType name="TimestampType"><br />
<xs:annotation><br />
<xs:documentation><br />
The date and timestamp when the EventManager received the Event.<br />
This element may be left empty by the event emitter, in which case,<br />
the Event Manager will supply a value.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:dateTime"/><br />
</xs:simpleType><br />
<xs:simpleType name="EventTypeType"><br />
<xs:annotation><br />
<xs:documentation><br />
A string indicating the type of event. EventType designates the verb.<br />
That is what action happened to the Objects that triggered the event.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<!-- ============= Array of Objects that triggered the event ============= --><br />
<xs:complexType name="ObjectDataType"><br />
<xs:annotation><br />
<xs:documentation><br />
A container for the identification of the objects that the tool was operating on.<br />
The purpose of the Object element is to identify the entity<br />
that was being operated on and which caused the event.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:sequence><br />
<xs:element name="ObjectType" type="ObjectTypeType"/><br />
<xs:element name="ObjectId" type="ObjectIdType"/><br />
</xs:sequence><br />
</xs:complexType><br />
<xs:simpleType name="ObjectIdType"><br />
<xs:annotation><br />
<xs:documentation><br />
An ObjectId identifies the entity or relationship that changed within a tool.<br />
The identifier must be unique for a particular instance of the source tool.<br />
The format of this element will not be standardized by ALF.<br />
The primary purpose is to allow subsequent ServiceFlows to uniquely identify<br />
(and perhaps access) the object that triggered the event.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<xs:simpleType name="ObjectTypeType"><br />
<xs:annotation><br />
<xs:documentation><br />
The type of entity involved. Note that the word entity is taken in<br />
its broadest sense, referring to whatever artifact a tool was operating on.<br />
For example, for a data modeling tool, an E-R relationship is a type of<br />
entity (i.e., and ObjectType) to ALF. The following are Object types enumerated by ALF:<br />
Business Activity<br />
Business Entity<br />
Business Process<br />
Individual<br />
Organization<br />
Oganizational Unit<br />
Role<br />
Use Case<br />
Business Location<br />
Entity<br />
Relationship<br />
System<br />
Model<br />
Source code<br />
Database<br />
Table<br />
Column<br />
File<br />
Folder<br />
Application<br />
Host<br />
Network<br />
Protocol<br />
Build<br />
Test<br />
Test Plan<br />
Test Result<br />
Workflow Item<br />
Requirement<br />
Request<br />
Issue<br />
Version<br />
Configuration<br />
Baseline<br />
Project<br />
Package<br />
Business Realm<br />
Logical Realm<br />
Physical Design Realm<br />
System Implementation Realm<br />
System Operations Realm<br />
Cross-Realm Infrastructure<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<!-- ============= The source (i.e, tool or product) that emitted the event ============= --><br />
<xs:complexType name="SourceType"><br />
<xs:annotation><br />
<xs:documentation><br />
A Source element is a container type that describes the source of the event.<br />
ProductCallbackURI is optional for tools that don't provide a listener to<br />
accept the callback from a tool or serviceflow at a later time.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:sequence><br />
<xs:element name="Product" type="ProductType"/><br />
<xs:element name="ProductVersion" type="ProductVersionType"/><br />
<xs:element name="ProductInstance" type="ProductInstanceType"/><br />
<xs:element name="ProductCallbackURI" type="ProductCallbackURIType" nillable="true" minOccurs="0"/><br />
</xs:sequence><br />
</xs:complexType><br />
<xs:simpleType name="ProductType"><br />
<xs:annotation><br />
<xs:documentation><br />
A descriptive name for the tool (i.e., program) that emitted the Event. Note that<br />
this is a datatype for a Product element.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<xs:simpleType name="ProductCallbackURIType"><br />
<xs:annotation><br />
<xs:documentation><br />
The web service endpoint for tools that support callbacks from<br />
ServiceFlows for additional information.<br />
The element content is optional for transient tools that may not be running<br />
at a later time, and so cannot accept a callback.<br />
Constantly running (server) tools that support callbacks should supply a URI.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<xs:simpleType name="ProductInstanceType"><br />
<xs:annotation><br />
<xs:documentation><br />
A unique string identifying the instance of the tool.<br />
This is useful when there may be multiple instances of a product working<br />
within an instance of ALF.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<xs:simpleType name="ProductVersionType"><br />
<xs:annotation><br />
<xs:documentation><br />
The release version of the product, such as 5.06<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<!-- ====== The user (or userid) providing the context when the event occurred ======= --><br />
<xs:complexType name="UserType"><br />
<xs:annotation><br />
<xs:documentation><br />
A container for elements that identify the end user and his/her credentials.<br />
Note on possible future change: As the ALF Security work is progressing, we may eliminate<br />
the Credentials element here and move it to the SOAP Header.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:sequence><br />
<xs:element name="CommonName" type="CommonNameType" nillable="true"/><br />
<xs:element name="LoginID" type="LoginIDType"/><br />
<xs:element name="Credentials" type="CredentialsType" nillable="true"/><br />
</xs:sequence><br />
</xs:complexType><br />
<xs:simpleType name="CommonNameType"><br />
<xs:annotation><br />
<xs:documentation><br />
The first name and surname name of the user. The exact format may<br />
vary from locale to locale.<br />
If the emitting tool does not know this information, the element is optional.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<xs:simpleType name="LoginIDType"><br />
<xs:annotation><br />
<xs:documentation><br />
The ID of the user when they authenticated to the tool that emitted the event.<br />
For tools running under the control of a ServiceFlow, the LoginID will be the<br />
user id presented by the ServiceFlow.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<xs:complexType name="CredentialsType"><br />
<xs:annotation><br />
<xs:documentation><br />
A Credentials element contains the security credentials that may be passed among<br />
tools that operate as part of a ServiceFlow.<br />
ALF SSO leverages WS-Security which passes credential information as part ot hte SOAP header. <br />
When ALF SSO is use this Credential element should be unecessary and will be nilled<br />
When ALF SSO is not being used or there are mixed security methods, the credential field may be used to pass a security credential <br />
through the event to the service flow.<br />
If present this element may be encrypted.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:sequence><br />
<xs:any/><br />
</xs:sequence><br />
</xs:complexType><br />
<xs:simpleType name="ApplicationNameType"><br />
<xs:annotation><br />
<xs:documentation><br />
The name of the ALF application to which this event belongs. Depending on the emitting tool, events may or may not be associated with an ALF application.<br />
If the emitting tool has the information available then it can provide the ALF ApplicationName as an additional information to distinguish the event.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<xs:simpleType name="EnvironmentType"><br />
<xs:annotation><br />
<xs:documentation><br />
The name of the environment in which this event is bing raised. This element will be set by the ALF Event manager from its installation configuration.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:restriction base="xs:string"/><br />
</xs:simpleType><br />
<xs:complexType name="EventDetailType"><br />
<xs:annotation><br />
<xs:documentation><br />
This element conveys the detailed information about the object that triggered the event,<br />
for example about a file that was checked into a configuration management tool.<br />
For the purposes of the EventBase, this element will be of type xs:any.<br />
The structure of this portion of the message will be specified by XML Schemas developed<br />
by the ALF Vocabulary Committees.<br />
This area will be passed through by the EventManager, and will not be examined by the<br />
Event Manager.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:sequence><br />
<xs:any/><br />
</xs:sequence><br />
<xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/><br />
</xs:complexType><br />
<xs:complexType name="EventExtensionType"><br />
<xs:annotation><br />
<xs:documentation><br />
This element conveys the detailed information that is tool-specific and goes beyond the<br />
information defined by the ALF Vocabularies.<br />
For the purposes of the EventBase, this element will be of type xs:any.<br />
The concrete structure of this portion of the message will be defined by concrete schemas that<br />
include XML Schemas defining the tool-specific structure.<br />
This area will be passed through by the EventManager, and will not be examined by the Event Manager.<br />
</xs:documentation><br />
</xs:annotation><br />
<xs:sequence><br />
<xs:any/><br />
</xs:sequence><br />
<xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/><br />
</xs:complexType><br />
<!-- End EventBaseTypes --><br />
<!-- BEGIN ALFEvent --><br />
<xs:complexType name="ALFEventType"><br />
<xs:sequence><br />
<xs:element name="Base" type="EventBaseType"/><br />
<xs:element name="Detail" type="EventDetailType"/><br />
<xs:element name="Extension" type="EventExtensionType"/><br />
</xs:sequence><br />
<xs:attribute name="version" type="xs:string" use="required"/><br />
</xs:complexType><br />
<xs:complexType name="ALFEventResponseType"><br />
<xs:sequence><br />
<xs:element name="Base" type="EventBaseType"/><br />
</xs:sequence><br />
</xs:complexType><br />
<xs:complexType name="ALFEventWithReplyResponseType"><br />
<xs:sequence><br />
<xs:element name="Base" type="EventBaseType"/><br />
<xs:any/><br />
</xs:sequence><br />
</xs:complexType><br />
<!-- END ALFEvent --><br />
<!-- Event Notice --><br />
<xs:element name="EventNotice" type="ALFEventType"/><br />
<xs:element name="EventNoticeResponse" type="ALFEventResponseType"/><br />
<xs:element name="EventNoticeWithReply" type="ALFEventType"/><br />
<xs:element name="EventNoticeWithReplyResponse" type="ALFEventWithReplyResponseType"/><br />
</xs:schema><br />
<br />
</pre><br />
<br />
== WSDL 001 ==<br />
ALFEventManager_001.WSDL<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<wsdl:definitions name="ALFEventManager"<br />
targetNamespace="http://www.eclipse.org/alf/XMLSchema/Events.wsdl"<br />
xmlns:tns="http://www.eclipse.org/alf/XMLSchema/Events.wsdl"<br />
xmlns:evt="http://www.eclipse.org/alf/XMLSchema/Events.xsd"<br />
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"<br />
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"<br />
xmlns:xsd="http://www.w3.org/2001/XMLSchema"<br />
xmlns:xs="http://www.w3.org/2001/XMLSchema"<br />
><br />
<br />
<wsdl:documentation><br />
WARNING: PRELIMINARY VERSION DO NOT USE<br />
<br />
Copyright Notice<br />
The material in this document is Copyright (c) Serena Software, Inc. and others, 2005<br />
Terms and Conditions:<br />
The Eclipse Foundation makes available all content in this document ("Content").<br />
Unless otherwise indicated below, the Content is provided to you under the terms<br />
and conditions of the Eclipse Public License Version 1.0 ("EPL").<br />
A copy of the EPL is available at http://www.eclipse.org/legal/epl-v10.html.<br />
For purposes of the EPL, "Program" will mean the Content.<br />
If you did not receive this Content directly from the Eclipse Foundation, the<br />
Content is being redistributed by another party ("Redistributor") and different<br />
terms and conditions may apply to your use of any object code in the Content.<br />
Check the Redistributor's license that was provided with the Content.<br />
If you did not receive any such license, contact the Redistributor.<br />
Unless otherwise indicated below, the terms and conditions of the EPL still apply to the Content.<br />
</wsdl:documentation><br />
<br />
<!-- ALF EventManager WSDL --> <br />
<wsdl:types><br />
<xsd:schema elementFormDefault="qualified" targetNamespace="http://www.eclipse.org/alf/XMLSchema/Events.xsd"<br />
xmlns:evt="http://www.eclipse.org/alf/XMLSchema/Events.xsd"<br />
xmlns="http://www.eclipse.org/alf/XMLSchema/Events.xsd"><br />
<xsd:include schemaLocation="ALFEventBase_001.xsd" /><br />
</xsd:schema><br />
</wsdl:types><br />
<br />
<wsdl:message name="EventNotice"><br />
<wsdl:part name="parameters" element="evt:EventNotice" /><br />
</wsdl:message><br />
<br />
<wsdl:message name="EventNoticeResponse"><br />
<wsdl:part name="parameters" element="evt:EventNoticeResponse" /><br />
</wsdl:message><br />
<br />
<wsdl:portType name="ALFEventManager"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:EventNotice"/><br />
<wsdl:output message="tns:EventNoticeResponse"/><br />
</wsdl:operation><br />
<wsdl:operation name="EventNoticeWithReply"><br />
<wsdl:input message="tns:EventNoticeWithReply"/><br />
<wsdl:output message="tns:EventNoticeWithReplyResponse"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
<wsdl:portType name="ALFServiceFlow"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:EventNotice"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
<wsdl:portType name="ALFServiceFlowWithReply"><br />
<wsdl:operation name="EventNotice"><br />
<wsdl:input message="tns:EventNotice"/><br />
<wsdl:output message="tns:EventNoticeResponse"/><br />
</wsdl:operation><br />
</wsdl:portType><br />
<br />
<wsdl:binding name="ALFEventManagerSOAP" type="tns:ALFEventManager"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal"/><br />
</wsdl:output><br />
</wsdl:operation><br />
<wsdl:operation name="EventNoticeWithReply"><br />
<soap:operation soapAction="EventNoticeWithReply"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal"/><br />
</wsdl:output><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
<wsdl:binding name="ALFServiceFlowSOAP" type="tns:ALFServiceFlow"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
<wsdl:binding name="ALFServiceFlowWithReplySOAP" type="tns:ALFServiceFlowWithResponse"><br />
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/><br />
<wsdl:operation name="EventNotice"><br />
<soap:operation soapAction="EventNotice"/><br />
<wsdl:input><br />
<soap:body use="literal"/><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal"/><br />
</wsdl:output><br />
</wsdl:operation><br />
</wsdl:binding><br />
<br />
<!-- Example service location --><br />
<wsdl:service name="ALFEventManager"><br />
<wsdl:port binding="tns:ALFEventManagerSOAP" name="ALFEventManagerSOAP"><br />
<soap:address location="http://localhost:8080/alfeventmgr/services/ALFEventManager"/><br />
</wsdl:port><br />
</wsdl:service><br />
<br />
</wsdl:definitions><br />
</pre></div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/Vocabularies/SCM_Vocabulary/Schema&diff=11958ALF/Vocabularies/SCM Vocabulary/Schema2006-09-27T20:34:35Z<p>Alf tbuss.yahoo.com: /* SCM Vocabulary Schema */</p>
<hr />
<div>[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
== SCM Vocabulary Schema ==<br />
see also [[ALF/Vocabularies/SCM Vocabulary/WSDL | WSDL]]<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8" ?><br />
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"<br />
xmlns="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
xmlns:tns="http://www.eclipse.org/alf/schema/alfcommonvocabulary/v0.00"<br />
targetNamespace="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
elementFormDefault="qualified" attributeFormDefault="unqualified"><br />
<xsd:annotation><br />
<xsd:documentation><br />
WARNING! PRELIMINARY FOR COMMENT ONLY<br />
Copyright Notice The material in this document is Copyright<br />
(c) Serena Software, Inc. and others, 2005,2006 Terms and<br />
Conditions: The Eclipse Foundation makes available all<br />
content in this document ("Content"). Unless otherwise<br />
indicated below, the Content is provided to you under the<br />
terms and conditions of the Eclipse Public License Version<br />
1.0 ("EPL"). A copy of the EPL is available at<br />
http://www.eclipse.org/legal/epl-v10.html. For purposes of<br />
the EPL, "Program" will mean the Content. If you did not<br />
receive this Content directly from the Eclipse Foundation,<br />
the Content is being redistributed by another party<br />
("Redistributor") and different terms and conditions may<br />
apply to your use of any object code in the Content. Check<br />
the Redistributor's license that was provided with the<br />
Content. If you did not receive any such license, contact<br />
the Redistributor. Unless otherwise indicated below, the<br />
terms and conditions of the EPL still apply to the Content.<br />
</xsd:documentation><br />
</xsd:annotation><br />
<xsd:simpleType name="UserIDType"><br />
<xsd:restriction base="xsd:string" /><br />
</xsd:simpleType><br />
<xsd:simpleType name="TimestampType"><br />
<xsd:restriction base="xsd:string" /><br />
</xsd:simpleType><br />
<xsd:complexType name="LabelType"><br />
<xsd:sequence><br />
<xsd:element name="LabelID" type="xsd:string" /><br />
<xsd:element name="LabelName" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="LabelCollectionType"><br />
<xsd:sequence><br />
<xsd:element name="Label" type="LabelType" minOccurs="0"<br />
maxOccurs="unbounded" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="LockType"><br />
<xsd:sequence><br />
<xsd:element name="LockID" type="xsd:string" /><br />
<xsd:element name="ElementVersionID" type="xsd:string" /><br />
<xsd:element name="LockTimestamp" type="TimestampType" /><br />
<xsd:element name="LockComment" type="xsd:string" /><br />
<xsd:element name="LockUser" type="UserIDType" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="LockCollectionType"><br />
<xsd:sequence><br />
<xsd:element name="Lock" type="LockType" minOccurs="0"<br />
maxOccurs="unbounded" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="ContentType"><br />
<xsd:sequence><br />
<xsd:element name="Path" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="ElementType"><br />
<xsd:sequence><br />
<xsd:element name="ElementID" type="xsd:string" /><br />
<xsd:element name="ElementName" type="xsd:string" /><br />
<xsd:element name="OwnerUser" type="UserIDType" /><br />
<xsd:element name="ElementDatatype" type="xsd:string" /><br />
<xsd:element name="CreationTimestamp" type="TimestampType" /><br />
<xsd:element name="CreationComment" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="ElementVersionType"><br />
<xsd:sequence><br />
<xsd:element name="ElementVersionID" type="xsd:string" /><br />
<xsd:element name="ElementVersionName" type="xsd:string" /><br />
<xsd:element name="ParentElementID" type="xsd:string" /><br />
<xsd:element name="AuthorUser" type="UserIDType" /><br />
<xsd:element name="Content" type="ContentType" /><br />
<xsd:element name="VersionTimestamp" type="TimestampType" /><br />
<xsd:element name="VersionComment" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="ElementVersionCollectionType"><br />
<xsd:sequence><br />
<xsd:element name="ElementVersion" type="ElementVersionType"<br />
minOccurs="0" maxOccurs="unbounded" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="VersionCollectionType"><br />
<xsd:sequence><br />
<xsd:element name="VersionCollectionID" type="xsd:string" /><br />
<xsd:element name="VersionCollectionName" type="xsd:string" /><br />
<xsd:element name="OwnerUser" type="UserIDType" /><br />
<xsd:element name="CreationTimestamp" type="TimestampType" /><br />
<xsd:element name="CreationComment" type="xsd:string" /><br />
<xsd:element name="Versions"<br />
type="ElementVersionCollectionType" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="ChangeSetType"><br />
<xsd:complexContent><br />
<xsd:extension base="VersionCollectionType" /><br />
</xsd:complexContent><br />
</xsd:complexType><br />
<xsd:complexType name="BaselineType"><br />
<xsd:complexContent><br />
<xsd:extension base="VersionCollectionType" /><br />
</xsd:complexContent><br />
</xsd:complexType><br />
<xsd:complexType name="RevisionIdentifierType"><br />
<xsd:sequence><br />
<xsd:element name="Name" type="xsd:string" /><br />
<xsd:element name="Description" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="BranchType"><br />
<xsd:sequence><br />
<xsd:element name="BranchID" type="xsd:string" /><br />
<xsd:element name="BranchName" type="xsd:string" /><br />
<xsd:element name="CreationTimestamp" type="TimestampType" /><br />
<xsd:element name="CreationComment" type="xsd:string" /><br />
<xsd:element name="StreamParentID" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="BranchCollectionType"><br />
<xsd:sequence><br />
<xsd:element name="Branch" type="BranchType" minOccurs="0"<br />
maxOccurs="unbounded" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="RevisionsType"><br />
<xsd:sequence><br />
<xsd:element name="ElementVersionID" type="xsd:string" /><br />
<xsd:element name="ElementVersionName" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="WorkspaceType"><br />
<xsd:sequence><br />
<xsd:element name="WorkspaceName" type="xsd:string" /><br />
<xsd:element name="WorkspaceID" type="xsd:string" /><br />
<xsd:element name="ConfigurationSpec" type="xsd:string" /><br />
<xsd:element name="OwnerID" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="VersionableObjectType"><br />
<xsd:sequence><br />
<xsd:element name="VersionableObjectName" type="xsd:string" /><br />
<xsd:element name="VersionableObjectID" type="xsd:string" /><br />
<xsd:element name="ConfigurationSpec" type="xsd:string" /><br />
<xsd:element name="ElementID" type="xsd:string" /><br />
<xsd:element name="RevisionIdentifier"<br />
type="RevisionIdentifierType" /><br />
<xsd:element name="CreationTimestamp" type="TimestampType" /><br />
<xsd:element name="LastModifiedTimestamp"<br />
type="TimestampType" /><br />
<xsd:element name="FolderID" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="FolderType"><br />
<xsd:complexContent><br />
<xsd:extension base="VersionableObjectType"><br />
<xsd:sequence><br />
<xsd:element name="LocalPath" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:extension><br />
</xsd:complexContent><br />
</xsd:complexType><br />
<xsd:complexType name="FileType"><br />
<xsd:complexContent><br />
<xsd:extension base="VersionableObjectType"><br />
<xsd:sequence><br />
<xsd:element name="Filename" /><br />
</xsd:sequence><br />
</xsd:extension><br />
</xsd:complexContent><br />
</xsd:complexType><br />
</xsd:schema><br />
</pre></div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/Vocabularies/SCM_Vocabulary/WSDL&diff=11957ALF/Vocabularies/SCM Vocabulary/WSDL2006-09-27T20:33:25Z<p>Alf tbuss.yahoo.com: </p>
<hr />
<div>[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
== SCM Vocabulary WSDL ==<br />
see also [[ALF/Vocabularies/SCM Vocabulary/Schema | Schema]]<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8" ?><br />
<wsdl:definitions name="ALFSCM"<br />
targetNamespace="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
xmlns:tns="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"<br />
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"<br />
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><br />
<wsdl:documentation><br />
WARNING! PRELIMINARY FOR COMMENT ONLY<br />
Copyright Notice The material in this document is Copyright (c)<br />
Serena Software, Inc. and others, 2005, 2006 Terms and<br />
Conditions: The Eclipse Foundation makes available all content<br />
in this document ("Content"). Unless otherwise indicated below,<br />
the Content is provided to you under the terms and conditions of<br />
the Eclipse Public License Version 1.0 ("EPL"). A copy of the<br />
EPL is available at http://www.eclipse.org/legal/epl-v10.html.<br />
For purposes of the EPL, "Program" will mean the Content. If you<br />
did not receive this Content directly from the Eclipse<br />
Foundation, the Content is being redistributed by another party<br />
("Redistributor") and different terms and conditions may apply<br />
to your use of any object code in the Content. Check the<br />
Redistributor's license that was provided with the Content. If<br />
you did not receive any such license, contact the Redistributor.<br />
Unless otherwise indicated below, the terms and conditions of<br />
the EPL still apply to the Content.<br />
</wsdl:documentation><br />
<!-- ALF SCM WSDL <br />
--><br />
<wsdl:types><br />
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"<br />
targetNamespace="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
xmlns:tns="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
elementFormDefault="qualified" attributeFormDefault="unqualified"><br />
<xsd:include schemaLocation="ALFSCM.xsd" /><br />
<xsd:complexType name="PromoteRequestType"><br />
<xsd:sequence><br />
<xsd:element name="fromBranchID" type="xsd:string" /><br />
<xsd:element name="toBranchID" type="xsd:string" /><br />
<xsd:element name="elementVersionList"<br />
type="ElementVersionCollectionType" nillable="true" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="PromoteResponseType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:element name="promoteRequest"<br />
type="PromoteRequestType" /><br />
<xsd:element name="promoteResponse"<br />
type="PromoteResponseType" /><br />
<xsd:complexType name="CreateBaselineRequestType"><br />
<xsd:sequence><br />
<xsd:element name="baselineName" type="xsd:string" /><br />
<xsd:element name="branchID" type="xsd:string" /><br />
<xsd:element name="configurationID"<br />
type="xsd:string" nillable="true" /><br />
<xsd:element name="otherOptions" type="xsd:string"<br />
nillable="true" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="CreateBaselineResponseType"><br />
<xsd:sequence><br />
<xsd:element name="baselineID" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:element name="createBaselineRequest"<br />
type="CreateBaselineRequestType" /><br />
<xsd:element name="createBaselineResponse"<br />
type="CreateBaselineResponseType" /><br />
<xsd:complexType name="CreateBranchRequestType"><br />
<xsd:sequence><br />
<xsd:element name="branchName" type="xsd:string" /><br />
<xsd:element name="parentBranchID"<br />
type="xsd:string" /><br />
<xsd:element name="timeBasis" type="TimestampType"<br />
nillable="true" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="CreateBranchResponseType"><br />
<xsd:sequence><br />
<xsd:element name="branchID" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:element name="createBranchRequest"<br />
type="CreateBranchRequestType" /><br />
<xsd:element name="createBranchResponse"<br />
type="CreateBranchResponseType" /><br />
<xsd:complexType name="RemoveAssetsRequestType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:complexType name="RemoveAssetsResponseType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:element name="removeAssetsRequest"<br />
type="RemoveAssetsRequestType" /><br />
<xsd:element name="removeAssetsResponse"<br />
type="RemoveAssetsResponseType" /><br />
<xsd:complexType name="IntentToModifyRequestType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:complexType name="IntentToModifyResponseType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:element name="intentToModifyRequest"<br />
type="IntentToModifyRequestType" /><br />
<xsd:element name="intentToModifyResponse"<br />
type="IntentToModifyResponseType" /><br />
<xsd:complexType name="updateWorkspaceRequestType"><br />
<xsd:sequence><br />
<xsd:element name="baselineID" type="xsd:string" /><br />
<xsd:element name="branchID" type="xsd:string" /><br />
<xsd:element name="configurationID"<br />
type="xsd:string" /><br />
<xsd:element name="options" type="xsd:string" /><br />
<xsd:element name="otherOptions" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="updateWorkspaceResponseType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:element name="updateWorkspaceRequest"<br />
type="updateWorkspaceRequestType" /><br />
<xsd:element name="updateWorkspaceResponse"<br />
type="updateWorkspaceResponseType" /><br />
<xsd:complexType name="createNewVersionsRequestType"><br />
<xsd:sequence><br />
<xsd:element name="branchID" type="xsd:string" /><br />
<xsd:element name="elementVersionList"<br />
type="ElementVersionCollectionType" /><br />
<xsd:element name="otherOptions" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="createNewVersionsResponseType"><br />
<xsd:sequence><br />
<xsd:element name="elementVersionList"<br />
type="ElementVersionCollectionType" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:element name="createNewVersionsRequest"<br />
type="createNewVersionsRequestType" /><br />
<xsd:element name="createNewVersionsResponse"<br />
type="createNewVersionsResponseType" /><br />
</xsd:schema><br />
</wsdl:types><br />
<wsdl:message name="PromoteRequest"><br />
<wsdl:part name="parameters" element="tns:promoteRequest" /><br />
</wsdl:message><br />
<wsdl:message name="PromoteResponse"><br />
<wsdl:part name="parameters" element="tns:promoteResponse" /><br />
</wsdl:message><br />
<wsdl:message name="CreateBaselineRequest"><br />
<wsdl:part name="parameters"<br />
element="tns:createBaselineRequest" /><br />
</wsdl:message><br />
<wsdl:message name="CreateBaselineResponse"><br />
<wsdl:part name="parameters"<br />
element="tns:createBaselineResponse" /><br />
</wsdl:message><br />
<wsdl:message name="CreateBranchRequest"><br />
<wsdl:part name="parameters" element="tns:createBranchRequest" /><br />
</wsdl:message><br />
<wsdl:message name="CreateBranchResponse"><br />
<wsdl:part name="parameters" element="tns:createBranchResponse" /><br />
</wsdl:message><br />
<wsdl:message name="RemoveAssetsRequest"><br />
<wsdl:part name="parameters" element="tns:removeAssetsRequest" /><br />
</wsdl:message><br />
<wsdl:message name="RemoveAssetsResponse"><br />
<wsdl:part name="parameters" element="tns:removeAssetsResponse" /><br />
</wsdl:message><br />
<wsdl:message name="IntentToModifyRequest"><br />
<wsdl:part name="parameters"<br />
element="tns:intentToModifyRequest" /><br />
</wsdl:message><br />
<wsdl:message name="IntentToModifyResponse"><br />
<wsdl:part name="parameters"<br />
element="tns:intentToModifyResponse" /><br />
</wsdl:message><br />
<wsdl:message name="UpdateWorkspaceRequest"><br />
<wsdl:part name="parameters"<br />
element="tns:updateWorkspaceRequest" /><br />
</wsdl:message><br />
<wsdl:message name="UpdateWorkspaceResponse"><br />
<wsdl:part name="parameters"<br />
element="tns:updateWorkspaceResponse" /><br />
</wsdl:message><br />
<wsdl:portType name="SCMServer"><br />
<wsdl:operation name="promote"><br />
<wsdl:input message="tns:PromoteRequest" /><br />
<wsdl:output message="tns:PromoteResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="createBaseline"><br />
<wsdl:input message="tns:CreateBaselineRequest" /><br />
<wsdl:output message="tns:CreateBaselineResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="createBranch"><br />
<wsdl:input message="tns:CreateBranchRequest" /><br />
<wsdl:output message="tns:CreateBranchResponse" /><br />
</wsdl:operation><br />
</wsdl:portType><br />
<wsdl:portType name="SCMWorkspace"><br />
<wsdl:operation name="createWorkspace"><br />
<wsdl:input message="tns:createWorkspaceRequest" /><br />
<wsdl:output message="tns:createWorkspaceResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="modifyWorkspace"><br />
<wsdl:input message="tns:modifyWorkspaceRequest" /><br />
<wsdl:output message="tns:modifyWorkspaceResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="removeWorkspace"><br />
<wsdl:input message="tns:removeWorkspaceRequest" /><br />
<wsdl:output message="tns:removeWorkspaceResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="addAssets"><br />
<wsdl:input message="tns:addAssetsRequest" /><br />
<wsdl:output message="tns:addAssetsResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="removeAssets"><br />
<wsdl:input message="tns:RemoveAssetsRequest" /><br />
<wsdl:output message="tns:RemoveAssetsResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="intentToModify"><br />
<wsdl:input message="tns:intentToModifyRequest" /><br />
<wsdl:output message="tns:intentToModifyResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="updateWorkspace"><br />
<wsdl:input message="tns:UpdateWorkspaceRequest" /><br />
<wsdl:output message="tns:UpdateWorkspaceResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="createNewVersions"><br />
<wsdl:input message="tns:CreateNewVersionsRequest" /><br />
<wsdl:output message="tns:CreateNewVersionsResponse" /><br />
</wsdl:operation><br />
</wsdl:portType><br />
<wsdl:binding name="ALFSCMSOAP" type="tns:ALFSCM"><br />
<soap:binding style="document"<br />
transport="http://schemas.xmlsoap.org/soap/http" /><br />
<wsdl:operation name="promote"><br />
<soap:operation soapAction="" /><br />
<wsdl:input><br />
<soap:body use="literal" /><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal" /><br />
</wsdl:output><br />
</wsdl:operation><br />
</wsdl:binding><br />
<wsdl:service name="ALFSCMServer"><br />
<wsdl:port binding="tns:ALFSCMSOAP" name="ALFSCMSOAP"><br />
<soap:address location="http://localhost:8080/ALFSCMServer" /><br />
</wsdl:port><br />
</wsdl:service><br />
<wsdl:service name="ALFSCMWorkspace"><br />
<wsdl:port binding="tns:ALFSCMSOAP" name="ALFSCMSOAP"><br />
<soap:address<br />
location="http://localhost:8080/ALFSCMWorkspace" /><br />
</wsdl:port><br />
</wsdl:service><br />
</wsdl:definitions><br />
</pre></div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/Vocabularies/SCM_Vocabulary/Schema&diff=11956ALF/Vocabularies/SCM Vocabulary/Schema2006-09-27T20:33:01Z<p>Alf tbuss.yahoo.com: </p>
<hr />
<div>[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
== SCM Vocabulary Schema ==<br />
see also [[ALF/Vocabularies/SCM Vocabulary/WSDL | WSDL]]<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8" ?><br />
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"<br />
xmlns="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
xmlns:tns="http://www.eclipse.org/alf/schema/alfcommonvocabulary/v0.00"<br />
targetNamespace="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
elementFormDefault="qualified" attributeFormDefault="unqualified"><br />
<xsd:annotation><br />
<xsd:documentation><br />
Copyright Notice The material in this document is Copyright<br />
(c) Serena Software, Inc. and others, 2005,2006 Terms and<br />
Conditions: The Eclipse Foundation makes available all<br />
content in this document ("Content"). Unless otherwise<br />
indicated below, the Content is provided to you under the<br />
terms and conditions of the Eclipse Public License Version<br />
1.0 ("EPL"). A copy of the EPL is available at<br />
http://www.eclipse.org/legal/epl-v10.html. For purposes of<br />
the EPL, "Program" will mean the Content. If you did not<br />
receive this Content directly from the Eclipse Foundation,<br />
the Content is being redistributed by another party<br />
("Redistributor") and different terms and conditions may<br />
apply to your use of any object code in the Content. Check<br />
the Redistributor's license that was provided with the<br />
Content. If you did not receive any such license, contact<br />
the Redistributor. Unless otherwise indicated below, the<br />
terms and conditions of the EPL still apply to the Content.<br />
</xsd:documentation><br />
</xsd:annotation><br />
<xsd:simpleType name="UserIDType"><br />
<xsd:restriction base="xsd:string" /><br />
</xsd:simpleType><br />
<xsd:simpleType name="TimestampType"><br />
<xsd:restriction base="xsd:string" /><br />
</xsd:simpleType><br />
<xsd:complexType name="LabelType"><br />
<xsd:sequence><br />
<xsd:element name="LabelID" type="xsd:string" /><br />
<xsd:element name="LabelName" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="LabelCollectionType"><br />
<xsd:sequence><br />
<xsd:element name="Label" type="LabelType" minOccurs="0"<br />
maxOccurs="unbounded" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="LockType"><br />
<xsd:sequence><br />
<xsd:element name="LockID" type="xsd:string" /><br />
<xsd:element name="ElementVersionID" type="xsd:string" /><br />
<xsd:element name="LockTimestamp" type="TimestampType" /><br />
<xsd:element name="LockComment" type="xsd:string" /><br />
<xsd:element name="LockUser" type="UserIDType" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="LockCollectionType"><br />
<xsd:sequence><br />
<xsd:element name="Lock" type="LockType" minOccurs="0"<br />
maxOccurs="unbounded" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="ContentType"><br />
<xsd:sequence><br />
<xsd:element name="Path" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="ElementType"><br />
<xsd:sequence><br />
<xsd:element name="ElementID" type="xsd:string" /><br />
<xsd:element name="ElementName" type="xsd:string" /><br />
<xsd:element name="OwnerUser" type="UserIDType" /><br />
<xsd:element name="ElementDatatype" type="xsd:string" /><br />
<xsd:element name="CreationTimestamp" type="TimestampType" /><br />
<xsd:element name="CreationComment" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="ElementVersionType"><br />
<xsd:sequence><br />
<xsd:element name="ElementVersionID" type="xsd:string" /><br />
<xsd:element name="ElementVersionName" type="xsd:string" /><br />
<xsd:element name="ParentElementID" type="xsd:string" /><br />
<xsd:element name="AuthorUser" type="UserIDType" /><br />
<xsd:element name="Content" type="ContentType" /><br />
<xsd:element name="VersionTimestamp" type="TimestampType" /><br />
<xsd:element name="VersionComment" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="ElementVersionCollectionType"><br />
<xsd:sequence><br />
<xsd:element name="ElementVersion" type="ElementVersionType"<br />
minOccurs="0" maxOccurs="unbounded" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="VersionCollectionType"><br />
<xsd:sequence><br />
<xsd:element name="VersionCollectionID" type="xsd:string" /><br />
<xsd:element name="VersionCollectionName" type="xsd:string" /><br />
<xsd:element name="OwnerUser" type="UserIDType" /><br />
<xsd:element name="CreationTimestamp" type="TimestampType" /><br />
<xsd:element name="CreationComment" type="xsd:string" /><br />
<xsd:element name="Versions"<br />
type="ElementVersionCollectionType" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="ChangeSetType"><br />
<xsd:complexContent><br />
<xsd:extension base="VersionCollectionType" /><br />
</xsd:complexContent><br />
</xsd:complexType><br />
<xsd:complexType name="BaselineType"><br />
<xsd:complexContent><br />
<xsd:extension base="VersionCollectionType" /><br />
</xsd:complexContent><br />
</xsd:complexType><br />
<xsd:complexType name="RevisionIdentifierType"><br />
<xsd:sequence><br />
<xsd:element name="Name" type="xsd:string" /><br />
<xsd:element name="Description" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="BranchType"><br />
<xsd:sequence><br />
<xsd:element name="BranchID" type="xsd:string" /><br />
<xsd:element name="BranchName" type="xsd:string" /><br />
<xsd:element name="CreationTimestamp" type="TimestampType" /><br />
<xsd:element name="CreationComment" type="xsd:string" /><br />
<xsd:element name="StreamParentID" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="BranchCollectionType"><br />
<xsd:sequence><br />
<xsd:element name="Branch" type="BranchType" minOccurs="0"<br />
maxOccurs="unbounded" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="RevisionsType"><br />
<xsd:sequence><br />
<xsd:element name="ElementVersionID" type="xsd:string" /><br />
<xsd:element name="ElementVersionName" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="WorkspaceType"><br />
<xsd:sequence><br />
<xsd:element name="WorkspaceName" type="xsd:string" /><br />
<xsd:element name="WorkspaceID" type="xsd:string" /><br />
<xsd:element name="ConfigurationSpec" type="xsd:string" /><br />
<xsd:element name="OwnerID" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="VersionableObjectType"><br />
<xsd:sequence><br />
<xsd:element name="VersionableObjectName" type="xsd:string" /><br />
<xsd:element name="VersionableObjectID" type="xsd:string" /><br />
<xsd:element name="ConfigurationSpec" type="xsd:string" /><br />
<xsd:element name="ElementID" type="xsd:string" /><br />
<xsd:element name="RevisionIdentifier"<br />
type="RevisionIdentifierType" /><br />
<xsd:element name="CreationTimestamp" type="TimestampType" /><br />
<xsd:element name="LastModifiedTimestamp"<br />
type="TimestampType" /><br />
<xsd:element name="FolderID" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="FolderType"><br />
<xsd:complexContent><br />
<xsd:extension base="VersionableObjectType"><br />
<xsd:sequence><br />
<xsd:element name="LocalPath" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:extension><br />
</xsd:complexContent><br />
</xsd:complexType><br />
<xsd:complexType name="FileType"><br />
<xsd:complexContent><br />
<xsd:extension base="VersionableObjectType"><br />
<xsd:sequence><br />
<xsd:element name="Filename" /><br />
</xsd:sequence><br />
</xsd:extension><br />
</xsd:complexContent><br />
</xsd:complexType><br />
</xsd:schema><br />
</pre></div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/Vocabularies/SCM_Vocabulary/Schema&diff=11955ALF/Vocabularies/SCM Vocabulary/Schema2006-09-27T20:32:10Z<p>Alf tbuss.yahoo.com: </p>
<hr />
<div>[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
[[ALF/Vocabularies/SCM Vocabulary/WSDL | WSDL]]<br />
== SCM Vocabulary Schema ==<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8" ?><br />
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"<br />
xmlns="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
xmlns:tns="http://www.eclipse.org/alf/schema/alfcommonvocabulary/v0.00"<br />
targetNamespace="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
elementFormDefault="qualified" attributeFormDefault="unqualified"><br />
<xsd:annotation><br />
<xsd:documentation><br />
Copyright Notice The material in this document is Copyright<br />
(c) Serena Software, Inc. and others, 2005,2006 Terms and<br />
Conditions: The Eclipse Foundation makes available all<br />
content in this document ("Content"). Unless otherwise<br />
indicated below, the Content is provided to you under the<br />
terms and conditions of the Eclipse Public License Version<br />
1.0 ("EPL"). A copy of the EPL is available at<br />
http://www.eclipse.org/legal/epl-v10.html. For purposes of<br />
the EPL, "Program" will mean the Content. If you did not<br />
receive this Content directly from the Eclipse Foundation,<br />
the Content is being redistributed by another party<br />
("Redistributor") and different terms and conditions may<br />
apply to your use of any object code in the Content. Check<br />
the Redistributor's license that was provided with the<br />
Content. If you did not receive any such license, contact<br />
the Redistributor. Unless otherwise indicated below, the<br />
terms and conditions of the EPL still apply to the Content.<br />
</xsd:documentation><br />
</xsd:annotation><br />
<xsd:simpleType name="UserIDType"><br />
<xsd:restriction base="xsd:string" /><br />
</xsd:simpleType><br />
<xsd:simpleType name="TimestampType"><br />
<xsd:restriction base="xsd:string" /><br />
</xsd:simpleType><br />
<xsd:complexType name="LabelType"><br />
<xsd:sequence><br />
<xsd:element name="LabelID" type="xsd:string" /><br />
<xsd:element name="LabelName" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="LabelCollectionType"><br />
<xsd:sequence><br />
<xsd:element name="Label" type="LabelType" minOccurs="0"<br />
maxOccurs="unbounded" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="LockType"><br />
<xsd:sequence><br />
<xsd:element name="LockID" type="xsd:string" /><br />
<xsd:element name="ElementVersionID" type="xsd:string" /><br />
<xsd:element name="LockTimestamp" type="TimestampType" /><br />
<xsd:element name="LockComment" type="xsd:string" /><br />
<xsd:element name="LockUser" type="UserIDType" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="LockCollectionType"><br />
<xsd:sequence><br />
<xsd:element name="Lock" type="LockType" minOccurs="0"<br />
maxOccurs="unbounded" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="ContentType"><br />
<xsd:sequence><br />
<xsd:element name="Path" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="ElementType"><br />
<xsd:sequence><br />
<xsd:element name="ElementID" type="xsd:string" /><br />
<xsd:element name="ElementName" type="xsd:string" /><br />
<xsd:element name="OwnerUser" type="UserIDType" /><br />
<xsd:element name="ElementDatatype" type="xsd:string" /><br />
<xsd:element name="CreationTimestamp" type="TimestampType" /><br />
<xsd:element name="CreationComment" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="ElementVersionType"><br />
<xsd:sequence><br />
<xsd:element name="ElementVersionID" type="xsd:string" /><br />
<xsd:element name="ElementVersionName" type="xsd:string" /><br />
<xsd:element name="ParentElementID" type="xsd:string" /><br />
<xsd:element name="AuthorUser" type="UserIDType" /><br />
<xsd:element name="Content" type="ContentType" /><br />
<xsd:element name="VersionTimestamp" type="TimestampType" /><br />
<xsd:element name="VersionComment" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="ElementVersionCollectionType"><br />
<xsd:sequence><br />
<xsd:element name="ElementVersion" type="ElementVersionType"<br />
minOccurs="0" maxOccurs="unbounded" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="VersionCollectionType"><br />
<xsd:sequence><br />
<xsd:element name="VersionCollectionID" type="xsd:string" /><br />
<xsd:element name="VersionCollectionName" type="xsd:string" /><br />
<xsd:element name="OwnerUser" type="UserIDType" /><br />
<xsd:element name="CreationTimestamp" type="TimestampType" /><br />
<xsd:element name="CreationComment" type="xsd:string" /><br />
<xsd:element name="Versions"<br />
type="ElementVersionCollectionType" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="ChangeSetType"><br />
<xsd:complexContent><br />
<xsd:extension base="VersionCollectionType" /><br />
</xsd:complexContent><br />
</xsd:complexType><br />
<xsd:complexType name="BaselineType"><br />
<xsd:complexContent><br />
<xsd:extension base="VersionCollectionType" /><br />
</xsd:complexContent><br />
</xsd:complexType><br />
<xsd:complexType name="RevisionIdentifierType"><br />
<xsd:sequence><br />
<xsd:element name="Name" type="xsd:string" /><br />
<xsd:element name="Description" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="BranchType"><br />
<xsd:sequence><br />
<xsd:element name="BranchID" type="xsd:string" /><br />
<xsd:element name="BranchName" type="xsd:string" /><br />
<xsd:element name="CreationTimestamp" type="TimestampType" /><br />
<xsd:element name="CreationComment" type="xsd:string" /><br />
<xsd:element name="StreamParentID" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="BranchCollectionType"><br />
<xsd:sequence><br />
<xsd:element name="Branch" type="BranchType" minOccurs="0"<br />
maxOccurs="unbounded" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="RevisionsType"><br />
<xsd:sequence><br />
<xsd:element name="ElementVersionID" type="xsd:string" /><br />
<xsd:element name="ElementVersionName" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="WorkspaceType"><br />
<xsd:sequence><br />
<xsd:element name="WorkspaceName" type="xsd:string" /><br />
<xsd:element name="WorkspaceID" type="xsd:string" /><br />
<xsd:element name="ConfigurationSpec" type="xsd:string" /><br />
<xsd:element name="OwnerID" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="VersionableObjectType"><br />
<xsd:sequence><br />
<xsd:element name="VersionableObjectName" type="xsd:string" /><br />
<xsd:element name="VersionableObjectID" type="xsd:string" /><br />
<xsd:element name="ConfigurationSpec" type="xsd:string" /><br />
<xsd:element name="ElementID" type="xsd:string" /><br />
<xsd:element name="RevisionIdentifier"<br />
type="RevisionIdentifierType" /><br />
<xsd:element name="CreationTimestamp" type="TimestampType" /><br />
<xsd:element name="LastModifiedTimestamp"<br />
type="TimestampType" /><br />
<xsd:element name="FolderID" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="FolderType"><br />
<xsd:complexContent><br />
<xsd:extension base="VersionableObjectType"><br />
<xsd:sequence><br />
<xsd:element name="LocalPath" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:extension><br />
</xsd:complexContent><br />
</xsd:complexType><br />
<xsd:complexType name="FileType"><br />
<xsd:complexContent><br />
<xsd:extension base="VersionableObjectType"><br />
<xsd:sequence><br />
<xsd:element name="Filename" /><br />
</xsd:sequence><br />
</xsd:extension><br />
</xsd:complexContent><br />
</xsd:complexType><br />
</xsd:schema><br />
</pre></div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/Vocabularies/SCM_Vocabulary/WSDL&diff=11954ALF/Vocabularies/SCM Vocabulary/WSDL2006-09-27T20:31:15Z<p>Alf tbuss.yahoo.com: </p>
<hr />
<div>[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
[[ALF/Vocabularies/SCM Vocabulary/Schema | Schema]]<br />
== SCM Vocabulary WSDL ==<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8" ?><br />
<wsdl:definitions name="ALFSCM"<br />
targetNamespace="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
xmlns:tns="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"<br />
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"<br />
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><br />
<wsdl:documentation><br />
WARNING! PRELIMINARY FOR COMMENT ONLY<br />
Copyright Notice The material in this document is Copyright (c)<br />
Serena Software, Inc. and others, 2005, 2006 Terms and<br />
Conditions: The Eclipse Foundation makes available all content<br />
in this document ("Content"). Unless otherwise indicated below,<br />
the Content is provided to you under the terms and conditions of<br />
the Eclipse Public License Version 1.0 ("EPL"). A copy of the<br />
EPL is available at http://www.eclipse.org/legal/epl-v10.html.<br />
For purposes of the EPL, "Program" will mean the Content. If you<br />
did not receive this Content directly from the Eclipse<br />
Foundation, the Content is being redistributed by another party<br />
("Redistributor") and different terms and conditions may apply<br />
to your use of any object code in the Content. Check the<br />
Redistributor's license that was provided with the Content. If<br />
you did not receive any such license, contact the Redistributor.<br />
Unless otherwise indicated below, the terms and conditions of<br />
the EPL still apply to the Content.<br />
</wsdl:documentation><br />
<!-- ALF SCM WSDL <br />
--><br />
<wsdl:types><br />
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"<br />
targetNamespace="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
xmlns:tns="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
elementFormDefault="qualified" attributeFormDefault="unqualified"><br />
<xsd:include schemaLocation="ALFSCM.xsd" /><br />
<xsd:complexType name="PromoteRequestType"><br />
<xsd:sequence><br />
<xsd:element name="fromBranchID" type="xsd:string" /><br />
<xsd:element name="toBranchID" type="xsd:string" /><br />
<xsd:element name="elementVersionList"<br />
type="ElementVersionCollectionType" nillable="true" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="PromoteResponseType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:element name="promoteRequest"<br />
type="PromoteRequestType" /><br />
<xsd:element name="promoteResponse"<br />
type="PromoteResponseType" /><br />
<xsd:complexType name="CreateBaselineRequestType"><br />
<xsd:sequence><br />
<xsd:element name="baselineName" type="xsd:string" /><br />
<xsd:element name="branchID" type="xsd:string" /><br />
<xsd:element name="configurationID"<br />
type="xsd:string" nillable="true" /><br />
<xsd:element name="otherOptions" type="xsd:string"<br />
nillable="true" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="CreateBaselineResponseType"><br />
<xsd:sequence><br />
<xsd:element name="baselineID" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:element name="createBaselineRequest"<br />
type="CreateBaselineRequestType" /><br />
<xsd:element name="createBaselineResponse"<br />
type="CreateBaselineResponseType" /><br />
<xsd:complexType name="CreateBranchRequestType"><br />
<xsd:sequence><br />
<xsd:element name="branchName" type="xsd:string" /><br />
<xsd:element name="parentBranchID"<br />
type="xsd:string" /><br />
<xsd:element name="timeBasis" type="TimestampType"<br />
nillable="true" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="CreateBranchResponseType"><br />
<xsd:sequence><br />
<xsd:element name="branchID" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:element name="createBranchRequest"<br />
type="CreateBranchRequestType" /><br />
<xsd:element name="createBranchResponse"<br />
type="CreateBranchResponseType" /><br />
<xsd:complexType name="RemoveAssetsRequestType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:complexType name="RemoveAssetsResponseType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:element name="removeAssetsRequest"<br />
type="RemoveAssetsRequestType" /><br />
<xsd:element name="removeAssetsResponse"<br />
type="RemoveAssetsResponseType" /><br />
<xsd:complexType name="IntentToModifyRequestType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:complexType name="IntentToModifyResponseType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:element name="intentToModifyRequest"<br />
type="IntentToModifyRequestType" /><br />
<xsd:element name="intentToModifyResponse"<br />
type="IntentToModifyResponseType" /><br />
<xsd:complexType name="updateWorkspaceRequestType"><br />
<xsd:sequence><br />
<xsd:element name="baselineID" type="xsd:string" /><br />
<xsd:element name="branchID" type="xsd:string" /><br />
<xsd:element name="configurationID"<br />
type="xsd:string" /><br />
<xsd:element name="options" type="xsd:string" /><br />
<xsd:element name="otherOptions" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="updateWorkspaceResponseType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:element name="updateWorkspaceRequest"<br />
type="updateWorkspaceRequestType" /><br />
<xsd:element name="updateWorkspaceResponse"<br />
type="updateWorkspaceResponseType" /><br />
<xsd:complexType name="createNewVersionsRequestType"><br />
<xsd:sequence><br />
<xsd:element name="branchID" type="xsd:string" /><br />
<xsd:element name="elementVersionList"<br />
type="ElementVersionCollectionType" /><br />
<xsd:element name="otherOptions" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="createNewVersionsResponseType"><br />
<xsd:sequence><br />
<xsd:element name="elementVersionList"<br />
type="ElementVersionCollectionType" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:element name="createNewVersionsRequest"<br />
type="createNewVersionsRequestType" /><br />
<xsd:element name="createNewVersionsResponse"<br />
type="createNewVersionsResponseType" /><br />
</xsd:schema><br />
</wsdl:types><br />
<wsdl:message name="PromoteRequest"><br />
<wsdl:part name="parameters" element="tns:promoteRequest" /><br />
</wsdl:message><br />
<wsdl:message name="PromoteResponse"><br />
<wsdl:part name="parameters" element="tns:promoteResponse" /><br />
</wsdl:message><br />
<wsdl:message name="CreateBaselineRequest"><br />
<wsdl:part name="parameters"<br />
element="tns:createBaselineRequest" /><br />
</wsdl:message><br />
<wsdl:message name="CreateBaselineResponse"><br />
<wsdl:part name="parameters"<br />
element="tns:createBaselineResponse" /><br />
</wsdl:message><br />
<wsdl:message name="CreateBranchRequest"><br />
<wsdl:part name="parameters" element="tns:createBranchRequest" /><br />
</wsdl:message><br />
<wsdl:message name="CreateBranchResponse"><br />
<wsdl:part name="parameters" element="tns:createBranchResponse" /><br />
</wsdl:message><br />
<wsdl:message name="RemoveAssetsRequest"><br />
<wsdl:part name="parameters" element="tns:removeAssetsRequest" /><br />
</wsdl:message><br />
<wsdl:message name="RemoveAssetsResponse"><br />
<wsdl:part name="parameters" element="tns:removeAssetsResponse" /><br />
</wsdl:message><br />
<wsdl:message name="IntentToModifyRequest"><br />
<wsdl:part name="parameters"<br />
element="tns:intentToModifyRequest" /><br />
</wsdl:message><br />
<wsdl:message name="IntentToModifyResponse"><br />
<wsdl:part name="parameters"<br />
element="tns:intentToModifyResponse" /><br />
</wsdl:message><br />
<wsdl:message name="UpdateWorkspaceRequest"><br />
<wsdl:part name="parameters"<br />
element="tns:updateWorkspaceRequest" /><br />
</wsdl:message><br />
<wsdl:message name="UpdateWorkspaceResponse"><br />
<wsdl:part name="parameters"<br />
element="tns:updateWorkspaceResponse" /><br />
</wsdl:message><br />
<wsdl:portType name="SCMServer"><br />
<wsdl:operation name="promote"><br />
<wsdl:input message="tns:PromoteRequest" /><br />
<wsdl:output message="tns:PromoteResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="createBaseline"><br />
<wsdl:input message="tns:CreateBaselineRequest" /><br />
<wsdl:output message="tns:CreateBaselineResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="createBranch"><br />
<wsdl:input message="tns:CreateBranchRequest" /><br />
<wsdl:output message="tns:CreateBranchResponse" /><br />
</wsdl:operation><br />
</wsdl:portType><br />
<wsdl:portType name="SCMWorkspace"><br />
<wsdl:operation name="createWorkspace"><br />
<wsdl:input message="tns:createWorkspaceRequest" /><br />
<wsdl:output message="tns:createWorkspaceResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="modifyWorkspace"><br />
<wsdl:input message="tns:modifyWorkspaceRequest" /><br />
<wsdl:output message="tns:modifyWorkspaceResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="removeWorkspace"><br />
<wsdl:input message="tns:removeWorkspaceRequest" /><br />
<wsdl:output message="tns:removeWorkspaceResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="addAssets"><br />
<wsdl:input message="tns:addAssetsRequest" /><br />
<wsdl:output message="tns:addAssetsResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="removeAssets"><br />
<wsdl:input message="tns:RemoveAssetsRequest" /><br />
<wsdl:output message="tns:RemoveAssetsResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="intentToModify"><br />
<wsdl:input message="tns:intentToModifyRequest" /><br />
<wsdl:output message="tns:intentToModifyResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="updateWorkspace"><br />
<wsdl:input message="tns:UpdateWorkspaceRequest" /><br />
<wsdl:output message="tns:UpdateWorkspaceResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="createNewVersions"><br />
<wsdl:input message="tns:CreateNewVersionsRequest" /><br />
<wsdl:output message="tns:CreateNewVersionsResponse" /><br />
</wsdl:operation><br />
</wsdl:portType><br />
<wsdl:binding name="ALFSCMSOAP" type="tns:ALFSCM"><br />
<soap:binding style="document"<br />
transport="http://schemas.xmlsoap.org/soap/http" /><br />
<wsdl:operation name="promote"><br />
<soap:operation soapAction="" /><br />
<wsdl:input><br />
<soap:body use="literal" /><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal" /><br />
</wsdl:output><br />
</wsdl:operation><br />
</wsdl:binding><br />
<wsdl:service name="ALFSCMServer"><br />
<wsdl:port binding="tns:ALFSCMSOAP" name="ALFSCMSOAP"><br />
<soap:address location="http://localhost:8080/ALFSCMServer" /><br />
</wsdl:port><br />
</wsdl:service><br />
<wsdl:service name="ALFSCMWorkspace"><br />
<wsdl:port binding="tns:ALFSCMSOAP" name="ALFSCMSOAP"><br />
<soap:address<br />
location="http://localhost:8080/ALFSCMWorkspace" /><br />
</wsdl:port><br />
</wsdl:service><br />
</wsdl:definitions><br />
</pre></div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/Vocabularies/SCM_Vocabulary/WSDL&diff=11953ALF/Vocabularies/SCM Vocabulary/WSDL2006-09-27T20:30:28Z<p>Alf tbuss.yahoo.com: /* SCM Vocabulary WSDL */</p>
<hr />
<div>[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
== SCM Vocabulary WSDL ==<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8" ?><br />
<wsdl:definitions name="ALFSCM"<br />
targetNamespace="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
xmlns:tns="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"<br />
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"<br />
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><br />
<wsdl:documentation><br />
WARNING! PRELIMINARY FOR COMMENT ONLY<br />
Copyright Notice The material in this document is Copyright (c)<br />
Serena Software, Inc. and others, 2005, 2006 Terms and<br />
Conditions: The Eclipse Foundation makes available all content<br />
in this document ("Content"). Unless otherwise indicated below,<br />
the Content is provided to you under the terms and conditions of<br />
the Eclipse Public License Version 1.0 ("EPL"). A copy of the<br />
EPL is available at http://www.eclipse.org/legal/epl-v10.html.<br />
For purposes of the EPL, "Program" will mean the Content. If you<br />
did not receive this Content directly from the Eclipse<br />
Foundation, the Content is being redistributed by another party<br />
("Redistributor") and different terms and conditions may apply<br />
to your use of any object code in the Content. Check the<br />
Redistributor's license that was provided with the Content. If<br />
you did not receive any such license, contact the Redistributor.<br />
Unless otherwise indicated below, the terms and conditions of<br />
the EPL still apply to the Content.<br />
</wsdl:documentation><br />
<!-- ALF SCM WSDL <br />
--><br />
<wsdl:types><br />
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"<br />
targetNamespace="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
xmlns:tns="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
elementFormDefault="qualified" attributeFormDefault="unqualified"><br />
<xsd:include schemaLocation="ALFSCM.xsd" /><br />
<xsd:complexType name="PromoteRequestType"><br />
<xsd:sequence><br />
<xsd:element name="fromBranchID" type="xsd:string" /><br />
<xsd:element name="toBranchID" type="xsd:string" /><br />
<xsd:element name="elementVersionList"<br />
type="ElementVersionCollectionType" nillable="true" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="PromoteResponseType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:element name="promoteRequest"<br />
type="PromoteRequestType" /><br />
<xsd:element name="promoteResponse"<br />
type="PromoteResponseType" /><br />
<xsd:complexType name="CreateBaselineRequestType"><br />
<xsd:sequence><br />
<xsd:element name="baselineName" type="xsd:string" /><br />
<xsd:element name="branchID" type="xsd:string" /><br />
<xsd:element name="configurationID"<br />
type="xsd:string" nillable="true" /><br />
<xsd:element name="otherOptions" type="xsd:string"<br />
nillable="true" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="CreateBaselineResponseType"><br />
<xsd:sequence><br />
<xsd:element name="baselineID" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:element name="createBaselineRequest"<br />
type="CreateBaselineRequestType" /><br />
<xsd:element name="createBaselineResponse"<br />
type="CreateBaselineResponseType" /><br />
<xsd:complexType name="CreateBranchRequestType"><br />
<xsd:sequence><br />
<xsd:element name="branchName" type="xsd:string" /><br />
<xsd:element name="parentBranchID"<br />
type="xsd:string" /><br />
<xsd:element name="timeBasis" type="TimestampType"<br />
nillable="true" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="CreateBranchResponseType"><br />
<xsd:sequence><br />
<xsd:element name="branchID" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:element name="createBranchRequest"<br />
type="CreateBranchRequestType" /><br />
<xsd:element name="createBranchResponse"<br />
type="CreateBranchResponseType" /><br />
<xsd:complexType name="RemoveAssetsRequestType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:complexType name="RemoveAssetsResponseType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:element name="removeAssetsRequest"<br />
type="RemoveAssetsRequestType" /><br />
<xsd:element name="removeAssetsResponse"<br />
type="RemoveAssetsResponseType" /><br />
<xsd:complexType name="IntentToModifyRequestType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:complexType name="IntentToModifyResponseType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:element name="intentToModifyRequest"<br />
type="IntentToModifyRequestType" /><br />
<xsd:element name="intentToModifyResponse"<br />
type="IntentToModifyResponseType" /><br />
<xsd:complexType name="updateWorkspaceRequestType"><br />
<xsd:sequence><br />
<xsd:element name="baselineID" type="xsd:string" /><br />
<xsd:element name="branchID" type="xsd:string" /><br />
<xsd:element name="configurationID"<br />
type="xsd:string" /><br />
<xsd:element name="options" type="xsd:string" /><br />
<xsd:element name="otherOptions" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="updateWorkspaceResponseType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:element name="updateWorkspaceRequest"<br />
type="updateWorkspaceRequestType" /><br />
<xsd:element name="updateWorkspaceResponse"<br />
type="updateWorkspaceResponseType" /><br />
<xsd:complexType name="createNewVersionsRequestType"><br />
<xsd:sequence><br />
<xsd:element name="branchID" type="xsd:string" /><br />
<xsd:element name="elementVersionList"<br />
type="ElementVersionCollectionType" /><br />
<xsd:element name="otherOptions" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="createNewVersionsResponseType"><br />
<xsd:sequence><br />
<xsd:element name="elementVersionList"<br />
type="ElementVersionCollectionType" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:element name="createNewVersionsRequest"<br />
type="createNewVersionsRequestType" /><br />
<xsd:element name="createNewVersionsResponse"<br />
type="createNewVersionsResponseType" /><br />
</xsd:schema><br />
</wsdl:types><br />
<wsdl:message name="PromoteRequest"><br />
<wsdl:part name="parameters" element="tns:promoteRequest" /><br />
</wsdl:message><br />
<wsdl:message name="PromoteResponse"><br />
<wsdl:part name="parameters" element="tns:promoteResponse" /><br />
</wsdl:message><br />
<wsdl:message name="CreateBaselineRequest"><br />
<wsdl:part name="parameters"<br />
element="tns:createBaselineRequest" /><br />
</wsdl:message><br />
<wsdl:message name="CreateBaselineResponse"><br />
<wsdl:part name="parameters"<br />
element="tns:createBaselineResponse" /><br />
</wsdl:message><br />
<wsdl:message name="CreateBranchRequest"><br />
<wsdl:part name="parameters" element="tns:createBranchRequest" /><br />
</wsdl:message><br />
<wsdl:message name="CreateBranchResponse"><br />
<wsdl:part name="parameters" element="tns:createBranchResponse" /><br />
</wsdl:message><br />
<wsdl:message name="RemoveAssetsRequest"><br />
<wsdl:part name="parameters" element="tns:removeAssetsRequest" /><br />
</wsdl:message><br />
<wsdl:message name="RemoveAssetsResponse"><br />
<wsdl:part name="parameters" element="tns:removeAssetsResponse" /><br />
</wsdl:message><br />
<wsdl:message name="IntentToModifyRequest"><br />
<wsdl:part name="parameters"<br />
element="tns:intentToModifyRequest" /><br />
</wsdl:message><br />
<wsdl:message name="IntentToModifyResponse"><br />
<wsdl:part name="parameters"<br />
element="tns:intentToModifyResponse" /><br />
</wsdl:message><br />
<wsdl:message name="UpdateWorkspaceRequest"><br />
<wsdl:part name="parameters"<br />
element="tns:updateWorkspaceRequest" /><br />
</wsdl:message><br />
<wsdl:message name="UpdateWorkspaceResponse"><br />
<wsdl:part name="parameters"<br />
element="tns:updateWorkspaceResponse" /><br />
</wsdl:message><br />
<wsdl:portType name="SCMServer"><br />
<wsdl:operation name="promote"><br />
<wsdl:input message="tns:PromoteRequest" /><br />
<wsdl:output message="tns:PromoteResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="createBaseline"><br />
<wsdl:input message="tns:CreateBaselineRequest" /><br />
<wsdl:output message="tns:CreateBaselineResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="createBranch"><br />
<wsdl:input message="tns:CreateBranchRequest" /><br />
<wsdl:output message="tns:CreateBranchResponse" /><br />
</wsdl:operation><br />
</wsdl:portType><br />
<wsdl:portType name="SCMWorkspace"><br />
<wsdl:operation name="createWorkspace"><br />
<wsdl:input message="tns:createWorkspaceRequest" /><br />
<wsdl:output message="tns:createWorkspaceResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="modifyWorkspace"><br />
<wsdl:input message="tns:modifyWorkspaceRequest" /><br />
<wsdl:output message="tns:modifyWorkspaceResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="removeWorkspace"><br />
<wsdl:input message="tns:removeWorkspaceRequest" /><br />
<wsdl:output message="tns:removeWorkspaceResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="addAssets"><br />
<wsdl:input message="tns:addAssetsRequest" /><br />
<wsdl:output message="tns:addAssetsResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="removeAssets"><br />
<wsdl:input message="tns:RemoveAssetsRequest" /><br />
<wsdl:output message="tns:RemoveAssetsResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="intentToModify"><br />
<wsdl:input message="tns:intentToModifyRequest" /><br />
<wsdl:output message="tns:intentToModifyResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="updateWorkspace"><br />
<wsdl:input message="tns:UpdateWorkspaceRequest" /><br />
<wsdl:output message="tns:UpdateWorkspaceResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="createNewVersions"><br />
<wsdl:input message="tns:CreateNewVersionsRequest" /><br />
<wsdl:output message="tns:CreateNewVersionsResponse" /><br />
</wsdl:operation><br />
</wsdl:portType><br />
<wsdl:binding name="ALFSCMSOAP" type="tns:ALFSCM"><br />
<soap:binding style="document"<br />
transport="http://schemas.xmlsoap.org/soap/http" /><br />
<wsdl:operation name="promote"><br />
<soap:operation soapAction="" /><br />
<wsdl:input><br />
<soap:body use="literal" /><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal" /><br />
</wsdl:output><br />
</wsdl:operation><br />
</wsdl:binding><br />
<wsdl:service name="ALFSCMServer"><br />
<wsdl:port binding="tns:ALFSCMSOAP" name="ALFSCMSOAP"><br />
<soap:address location="http://localhost:8080/ALFSCMServer" /><br />
</wsdl:port><br />
</wsdl:service><br />
<wsdl:service name="ALFSCMWorkspace"><br />
<wsdl:port binding="tns:ALFSCMSOAP" name="ALFSCMSOAP"><br />
<soap:address<br />
location="http://localhost:8080/ALFSCMWorkspace" /><br />
</wsdl:port><br />
</wsdl:service><br />
</wsdl:definitions><br />
</pre></div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/CoreServices/AdminService&diff=11951ALF/CoreServices/AdminService2006-09-27T20:21:17Z<p>Alf tbuss.yahoo.com: </p>
<hr />
<div>[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
== ALF Applications ==<br />
=== Introduction ===<br />
An ALF application is a set of ALF events and Service Flows configured together with the intent of providing a coherent service. An ALF application can be expressed in an ALF Event Map.<br />
=== Building ===<br />
To build an ALF application it is necessary to construct an ALF Event Map expresses the relationships between the various ALF events and the Service Flows that are intended to run on those events. Typically the set of events and the Service Flow definitions will differ between applications. However, tools that participate in ALF cannot distinguish between ALF applications. This is left to the ALF event manager. The ALF event manager distinguishes between applications via the application name provided in the ALF Event Map<br />
=== Deployment ===<br />
To deploy an ALF application, an ALF Event Map for that application is provided to the ALF event manager. The ALF event manager loads the ALF event map and merges it into its runtime event dispatch table. The dispatch table entries are distinguished by the application name provided in the Event Map. This allows independent runtime control (pause resume etc) over each of applications deployed to the ALF event manager.<br />
An ALF event manager can host one or more ALF applications. ALF applications are distinguished by only by name. The ALF event manager does not manage versions. it is the responsibility of the deployment tool to keep track of application versions and how they are named and related. Generally this is not an issue since only one version of an application is deployed at once. Thus the deployment tool could choose to un-deploy the old version and re-deploy the new version using the same name.<br />
However, if it is desired to distinguish between versions of an application at runtime then the deployment tool must deploy these versions using different names. For example and application named “BuildAll” may have various versions over time. These may be distinguished using a naming convention that appends a version designator as in “BuildAll-1_0”, “BuildAll-1_5”, “BuildAll-2_0” etc. The ALF event manager sees these as separate applications and does not relate them in anyway. Any records generated by ALF will be correlated to the application name. If the application needs to correlate data between its various versions then either the various application versions must be deployed using the same name or the application design must provide its own mechanism to do so.<br />
=== Runtime ===<br />
ALF applications may overlap in their use of tool emitted Events and Service Flows. These entities are defined by the system configuration from the perspective of the ALF event manager. The event manager cannot implicitly distinguish them by application. If two or more applications share the same event to service flow mapping then the event manager must be able to distinguish between these cases when it is configured. In this case the event manager will treat each application’s event to service flow mapping as distinct. Where deployed applications share a common event to service flow mapping definition, it will dispatch the event once per application creating a new instance of the service flow for each application. This convention anticipates the use of separate BPEL servers per application. The separate service flow instances will be distinguished by the application identifier supplied by the event manager in the event.<br />
== ALF Event Manager Administration Service ==<br />
=== Introduction ===<br />
The ALF Event Manager has a number of runtime management controls that can be invoked via its Admin web service. These controls include<br />
• The ability to deploy and un-deploy an application event map.<br />
• The ability to pause and resume a deployed application.<br />
• The ability to retrieve a deployed application event map<br />
• The ability to report the current status of the deployed applications.<br />
• The ability to retrieve the content of the ALF Event Manager Logs<br />
=== Deploy ===<br />
''string deploy(string eventMap, bool startImmediately ) throws alfError.invalidApplicationName, alfError.invalidEventMap''<br />
<br />
<br />
The given application event map is send to the to the ALF event manager which merges it into the running event map. If “startImmediately” has the value “true” then the deployed application is immediately started and any events that match its definition are dispatched accordingly.<br />
<br />
<br />
Returns the application name from eventMap.<br />
<br />
<br />
If application named by the event map is already deployed the operation will throw alfError.invalidApplicationName .<br />
If the eventMap is invalid then the operation will throw alfError.invalidEventMap<br />
If no application name is specified in the eventMap then it is assumed to represent an application named “default”. In this case the current “default” application must be un-deployed before the new “default” application can be deployed.<br />
<br />
=== Un-deploy ===<br />
''void undeploy(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
<br />
The named application is paused (see Pause below) if it is not already in that state and then undeployed. The various event-service flow mappings are removed from the run event map.<br />
<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
<br />
=== Pause ===<br />
''void pause()''<br />
<br />
<br />
All events currently being dispatched are completed. All new event dispatching is stopped. Events received after a pause is requested are logged but will never be dispatched and may be considered lost.<br />
<br />
<br />
If the ALF Event manager is already paused this operation just returns without taking any action.<br />
<br />
<br />
Note: Should pausing queue events?<br />
<br />
=== Pause Application ===<br />
''void pause(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
All events currently being dispatched to the given application are completed. All event dispatching to the named application is stopped. Events received for the given application are logged but lost.<br />
<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
If an application is explicitly paused it must be explicitly resumed<br />
<br />
<br />
Note: Should pausing an application queue the events to that application?<br />
<br />
=== Resume ===<br />
''void resume()''<br />
<br />
Event dispatching is resumed to all applications that are not explicitly paused. If the ALF Event manager is not paused this operation just returns without taking any action.<br />
<br />
=== Resume Application ===<br />
''void resume(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
<br />
Event dispatching is resumed to the named application. If the application is not paused, this operation just returns without taking any action.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
<br />
=== Get Runtime EventMap ===<br />
''string GetEventMap(string)''<br />
<br />
<br />
The full runtime event map is returned as an XML string<br />
<br />
<br />
Note: Will this get too big for this operation to be practical?<br />
<br />
=== Get Application EventMap ===<br />
''string GetEventMap(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
The event map associated with the named application is returned as an xml formatted string.<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
<br />
=== Get Application Status ===<br />
''applicationStatus[] GetApplicationStatus()''<br />
<br />
An array of status structures for all the deployed applications is returned. The status structure contains, at least the application name, whether it is paused or running.<br />
<br />
Note: Should we extend this to include some minimal statistics? Fex Time deployed, time last resumed, number of events since past resume etc.<br />
<br />
=== Logging ===<br />
''string[] listLogNames()''<br />
<br />
The list of named logs stored by the ALF Event Manager is returned<br />
<br />
''string listLog(LogName) throws alfError.invalidLogName''<br />
<br />
The Content of the named log is returned as a string<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/CoreServices&diff=11950ALF/CoreServices2006-09-27T20:21:02Z<p>Alf tbuss.yahoo.com: </p>
<hr />
<div>[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
== Core Services ==<br />
<br />
{|<br />
|-<br />
| [[ALF/CoreServices/AdminService | AdminService]]<br />
| <br />
|}</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/CoreServices/AdminService&diff=11948ALF/CoreServices/AdminService2006-09-27T20:10:01Z<p>Alf tbuss.yahoo.com: /* Logging */</p>
<hr />
<div>== ALF Applications ==<br />
=== Introduction ===<br />
An ALF application is a set of ALF events and Service Flows configured together with the intent of providing a coherent service. An ALF application can be expressed in an ALF Event Map.<br />
=== Building ===<br />
To build an ALF application it is necessary to construct an ALF Event Map expresses the relationships between the various ALF events and the Service Flows that are intended to run on those events. Typically the set of events and the Service Flow definitions will differ between applications. However, tools that participate in ALF cannot distinguish between ALF applications. This is left to the ALF event manager. The ALF event manager distinguishes between applications via the application name provided in the ALF Event Map<br />
=== Deployment ===<br />
To deploy an ALF application, an ALF Event Map for that application is provided to the ALF event manager. The ALF event manager loads the ALF event map and merges it into its runtime event dispatch table. The dispatch table entries are distinguished by the application name provided in the Event Map. This allows independent runtime control (pause resume etc) over each of applications deployed to the ALF event manager.<br />
An ALF event manager can host one or more ALF applications. ALF applications are distinguished by only by name. The ALF event manager does not manage versions. it is the responsibility of the deployment tool to keep track of application versions and how they are named and related. Generally this is not an issue since only one version of an application is deployed at once. Thus the deployment tool could choose to un-deploy the old version and re-deploy the new version using the same name.<br />
However, if it is desired to distinguish between versions of an application at runtime then the deployment tool must deploy these versions using different names. For example and application named “BuildAll” may have various versions over time. These may be distinguished using a naming convention that appends a version designator as in “BuildAll-1_0”, “BuildAll-1_5”, “BuildAll-2_0” etc. The ALF event manager sees these as separate applications and does not relate them in anyway. Any records generated by ALF will be correlated to the application name. If the application needs to correlate data between its various versions then either the various application versions must be deployed using the same name or the application design must provide its own mechanism to do so.<br />
=== Runtime ===<br />
ALF applications may overlap in their use of tool emitted Events and Service Flows. These entities are defined by the system configuration from the perspective of the ALF event manager. The event manager cannot implicitly distinguish them by application. If two or more applications share the same event to service flow mapping then the event manager must be able to distinguish between these cases when it is configured. In this case the event manager will treat each application’s event to service flow mapping as distinct. Where deployed applications share a common event to service flow mapping definition, it will dispatch the event once per application creating a new instance of the service flow for each application. This convention anticipates the use of separate BPEL servers per application. The separate service flow instances will be distinguished by the application identifier supplied by the event manager in the event.<br />
== ALF Event Manager Administration Service ==<br />
=== Introduction ===<br />
The ALF Event Manager has a number of runtime management controls that can be invoked via its Admin web service. These controls include<br />
• The ability to deploy and un-deploy an application event map.<br />
• The ability to pause and resume a deployed application.<br />
• The ability to retrieve a deployed application event map<br />
• The ability to report the current status of the deployed applications.<br />
• The ability to retrieve the content of the ALF Event Manager Logs<br />
=== Deploy ===<br />
''string deploy(string eventMap, bool startImmediately ) throws alfError.invalidApplicationName, alfError.invalidEventMap''<br />
<br />
<br />
The given application event map is send to the to the ALF event manager which merges it into the running event map. If “startImmediately” has the value “true” then the deployed application is immediately started and any events that match its definition are dispatched accordingly.<br />
<br />
<br />
Returns the application name from eventMap.<br />
<br />
<br />
If application named by the event map is already deployed the operation will throw alfError.invalidApplicationName .<br />
If the eventMap is invalid then the operation will throw alfError.invalidEventMap<br />
If no application name is specified in the eventMap then it is assumed to represent an application named “default”. In this case the current “default” application must be un-deployed before the new “default” application can be deployed.<br />
<br />
=== Un-deploy ===<br />
''void undeploy(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
<br />
The named application is paused (see Pause below) if it is not already in that state and then undeployed. The various event-service flow mappings are removed from the run event map.<br />
<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
<br />
=== Pause ===<br />
''void pause()''<br />
<br />
<br />
All events currently being dispatched are completed. All new event dispatching is stopped. Events received after a pause is requested are logged but will never be dispatched and may be considered lost.<br />
<br />
<br />
If the ALF Event manager is already paused this operation just returns without taking any action.<br />
<br />
<br />
Note: Should pausing queue events?<br />
<br />
=== Pause Application ===<br />
''void pause(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
All events currently being dispatched to the given application are completed. All event dispatching to the named application is stopped. Events received for the given application are logged but lost.<br />
<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
If an application is explicitly paused it must be explicitly resumed<br />
<br />
<br />
Note: Should pausing an application queue the events to that application?<br />
<br />
=== Resume ===<br />
''void resume()''<br />
<br />
Event dispatching is resumed to all applications that are not explicitly paused. If the ALF Event manager is not paused this operation just returns without taking any action.<br />
<br />
=== Resume Application ===<br />
''void resume(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
<br />
Event dispatching is resumed to the named application. If the application is not paused, this operation just returns without taking any action.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
<br />
=== Get Runtime EventMap ===<br />
''string GetEventMap(string)''<br />
<br />
<br />
The full runtime event map is returned as an XML string<br />
<br />
<br />
Note: Will this get too big for this operation to be practical?<br />
<br />
=== Get Application EventMap ===<br />
''string GetEventMap(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
The event map associated with the named application is returned as an xml formatted string.<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
<br />
=== Get Application Status ===<br />
''applicationStatus[] GetApplicationStatus()''<br />
<br />
An array of status structures for all the deployed applications is returned. The status structure contains, at least the application name, whether it is paused or running.<br />
<br />
Note: Should we extend this to include some minimal statistics? Fex Time deployed, time last resumed, number of events since past resume etc.<br />
<br />
=== Logging ===<br />
''string[] listLogNames()''<br />
<br />
The list of named logs stored by the ALF Event Manager is returned<br />
<br />
''string listLog(LogName) throws alfError.invalidLogName''<br />
<br />
The Content of the named log is returned as a string<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/CoreServices/AdminService&diff=11947ALF/CoreServices/AdminService2006-09-27T20:09:11Z<p>Alf tbuss.yahoo.com: /* Get Application Status */</p>
<hr />
<div>== ALF Applications ==<br />
=== Introduction ===<br />
An ALF application is a set of ALF events and Service Flows configured together with the intent of providing a coherent service. An ALF application can be expressed in an ALF Event Map.<br />
=== Building ===<br />
To build an ALF application it is necessary to construct an ALF Event Map expresses the relationships between the various ALF events and the Service Flows that are intended to run on those events. Typically the set of events and the Service Flow definitions will differ between applications. However, tools that participate in ALF cannot distinguish between ALF applications. This is left to the ALF event manager. The ALF event manager distinguishes between applications via the application name provided in the ALF Event Map<br />
=== Deployment ===<br />
To deploy an ALF application, an ALF Event Map for that application is provided to the ALF event manager. The ALF event manager loads the ALF event map and merges it into its runtime event dispatch table. The dispatch table entries are distinguished by the application name provided in the Event Map. This allows independent runtime control (pause resume etc) over each of applications deployed to the ALF event manager.<br />
An ALF event manager can host one or more ALF applications. ALF applications are distinguished by only by name. The ALF event manager does not manage versions. it is the responsibility of the deployment tool to keep track of application versions and how they are named and related. Generally this is not an issue since only one version of an application is deployed at once. Thus the deployment tool could choose to un-deploy the old version and re-deploy the new version using the same name.<br />
However, if it is desired to distinguish between versions of an application at runtime then the deployment tool must deploy these versions using different names. For example and application named “BuildAll” may have various versions over time. These may be distinguished using a naming convention that appends a version designator as in “BuildAll-1_0”, “BuildAll-1_5”, “BuildAll-2_0” etc. The ALF event manager sees these as separate applications and does not relate them in anyway. Any records generated by ALF will be correlated to the application name. If the application needs to correlate data between its various versions then either the various application versions must be deployed using the same name or the application design must provide its own mechanism to do so.<br />
=== Runtime ===<br />
ALF applications may overlap in their use of tool emitted Events and Service Flows. These entities are defined by the system configuration from the perspective of the ALF event manager. The event manager cannot implicitly distinguish them by application. If two or more applications share the same event to service flow mapping then the event manager must be able to distinguish between these cases when it is configured. In this case the event manager will treat each application’s event to service flow mapping as distinct. Where deployed applications share a common event to service flow mapping definition, it will dispatch the event once per application creating a new instance of the service flow for each application. This convention anticipates the use of separate BPEL servers per application. The separate service flow instances will be distinguished by the application identifier supplied by the event manager in the event.<br />
== ALF Event Manager Administration Service ==<br />
=== Introduction ===<br />
The ALF Event Manager has a number of runtime management controls that can be invoked via its Admin web service. These controls include<br />
• The ability to deploy and un-deploy an application event map.<br />
• The ability to pause and resume a deployed application.<br />
• The ability to retrieve a deployed application event map<br />
• The ability to report the current status of the deployed applications.<br />
• The ability to retrieve the content of the ALF Event Manager Logs<br />
=== Deploy ===<br />
''string deploy(string eventMap, bool startImmediately ) throws alfError.invalidApplicationName, alfError.invalidEventMap''<br />
<br />
<br />
The given application event map is send to the to the ALF event manager which merges it into the running event map. If “startImmediately” has the value “true” then the deployed application is immediately started and any events that match its definition are dispatched accordingly.<br />
<br />
<br />
Returns the application name from eventMap.<br />
<br />
<br />
If application named by the event map is already deployed the operation will throw alfError.invalidApplicationName .<br />
If the eventMap is invalid then the operation will throw alfError.invalidEventMap<br />
If no application name is specified in the eventMap then it is assumed to represent an application named “default”. In this case the current “default” application must be un-deployed before the new “default” application can be deployed.<br />
<br />
=== Un-deploy ===<br />
''void undeploy(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
<br />
The named application is paused (see Pause below) if it is not already in that state and then undeployed. The various event-service flow mappings are removed from the run event map.<br />
<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
<br />
=== Pause ===<br />
''void pause()''<br />
<br />
<br />
All events currently being dispatched are completed. All new event dispatching is stopped. Events received after a pause is requested are logged but will never be dispatched and may be considered lost.<br />
<br />
<br />
If the ALF Event manager is already paused this operation just returns without taking any action.<br />
<br />
<br />
Note: Should pausing queue events?<br />
<br />
=== Pause Application ===<br />
''void pause(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
All events currently being dispatched to the given application are completed. All event dispatching to the named application is stopped. Events received for the given application are logged but lost.<br />
<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
If an application is explicitly paused it must be explicitly resumed<br />
<br />
<br />
Note: Should pausing an application queue the events to that application?<br />
<br />
=== Resume ===<br />
''void resume()''<br />
<br />
Event dispatching is resumed to all applications that are not explicitly paused. If the ALF Event manager is not paused this operation just returns without taking any action.<br />
<br />
=== Resume Application ===<br />
''void resume(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
<br />
Event dispatching is resumed to the named application. If the application is not paused, this operation just returns without taking any action.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
<br />
=== Get Runtime EventMap ===<br />
''string GetEventMap(string)''<br />
<br />
<br />
The full runtime event map is returned as an XML string<br />
<br />
<br />
Note: Will this get too big for this operation to be practical?<br />
<br />
=== Get Application EventMap ===<br />
''string GetEventMap(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
The event map associated with the named application is returned as an xml formatted string.<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
<br />
=== Get Application Status ===<br />
''applicationStatus[] GetApplicationStatus()''<br />
<br />
An array of status structures for all the deployed applications is returned. The status structure contains, at least the application name, whether it is paused or running.<br />
<br />
Note: Should we extend this to include some minimal statistics? Fex Time deployed, time last resumed, number of events since past resume etc.<br />
<br />
=== Logging ===<br />
string[] listLogNames()<br />
The list of named logs stored by the ALF Event Manager is returned<br />
string listLog(LogName) throws alfError.invalidLogName<br />
The Content of the named log is returned as a string<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/CoreServices/AdminService&diff=11946ALF/CoreServices/AdminService2006-09-27T20:08:43Z<p>Alf tbuss.yahoo.com: /* Get Application EventMap */</p>
<hr />
<div>== ALF Applications ==<br />
=== Introduction ===<br />
An ALF application is a set of ALF events and Service Flows configured together with the intent of providing a coherent service. An ALF application can be expressed in an ALF Event Map.<br />
=== Building ===<br />
To build an ALF application it is necessary to construct an ALF Event Map expresses the relationships between the various ALF events and the Service Flows that are intended to run on those events. Typically the set of events and the Service Flow definitions will differ between applications. However, tools that participate in ALF cannot distinguish between ALF applications. This is left to the ALF event manager. The ALF event manager distinguishes between applications via the application name provided in the ALF Event Map<br />
=== Deployment ===<br />
To deploy an ALF application, an ALF Event Map for that application is provided to the ALF event manager. The ALF event manager loads the ALF event map and merges it into its runtime event dispatch table. The dispatch table entries are distinguished by the application name provided in the Event Map. This allows independent runtime control (pause resume etc) over each of applications deployed to the ALF event manager.<br />
An ALF event manager can host one or more ALF applications. ALF applications are distinguished by only by name. The ALF event manager does not manage versions. it is the responsibility of the deployment tool to keep track of application versions and how they are named and related. Generally this is not an issue since only one version of an application is deployed at once. Thus the deployment tool could choose to un-deploy the old version and re-deploy the new version using the same name.<br />
However, if it is desired to distinguish between versions of an application at runtime then the deployment tool must deploy these versions using different names. For example and application named “BuildAll” may have various versions over time. These may be distinguished using a naming convention that appends a version designator as in “BuildAll-1_0”, “BuildAll-1_5”, “BuildAll-2_0” etc. The ALF event manager sees these as separate applications and does not relate them in anyway. Any records generated by ALF will be correlated to the application name. If the application needs to correlate data between its various versions then either the various application versions must be deployed using the same name or the application design must provide its own mechanism to do so.<br />
=== Runtime ===<br />
ALF applications may overlap in their use of tool emitted Events and Service Flows. These entities are defined by the system configuration from the perspective of the ALF event manager. The event manager cannot implicitly distinguish them by application. If two or more applications share the same event to service flow mapping then the event manager must be able to distinguish between these cases when it is configured. In this case the event manager will treat each application’s event to service flow mapping as distinct. Where deployed applications share a common event to service flow mapping definition, it will dispatch the event once per application creating a new instance of the service flow for each application. This convention anticipates the use of separate BPEL servers per application. The separate service flow instances will be distinguished by the application identifier supplied by the event manager in the event.<br />
== ALF Event Manager Administration Service ==<br />
=== Introduction ===<br />
The ALF Event Manager has a number of runtime management controls that can be invoked via its Admin web service. These controls include<br />
• The ability to deploy and un-deploy an application event map.<br />
• The ability to pause and resume a deployed application.<br />
• The ability to retrieve a deployed application event map<br />
• The ability to report the current status of the deployed applications.<br />
• The ability to retrieve the content of the ALF Event Manager Logs<br />
=== Deploy ===<br />
''string deploy(string eventMap, bool startImmediately ) throws alfError.invalidApplicationName, alfError.invalidEventMap''<br />
<br />
<br />
The given application event map is send to the to the ALF event manager which merges it into the running event map. If “startImmediately” has the value “true” then the deployed application is immediately started and any events that match its definition are dispatched accordingly.<br />
<br />
<br />
Returns the application name from eventMap.<br />
<br />
<br />
If application named by the event map is already deployed the operation will throw alfError.invalidApplicationName .<br />
If the eventMap is invalid then the operation will throw alfError.invalidEventMap<br />
If no application name is specified in the eventMap then it is assumed to represent an application named “default”. In this case the current “default” application must be un-deployed before the new “default” application can be deployed.<br />
<br />
=== Un-deploy ===<br />
''void undeploy(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
<br />
The named application is paused (see Pause below) if it is not already in that state and then undeployed. The various event-service flow mappings are removed from the run event map.<br />
<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
<br />
=== Pause ===<br />
''void pause()''<br />
<br />
<br />
All events currently being dispatched are completed. All new event dispatching is stopped. Events received after a pause is requested are logged but will never be dispatched and may be considered lost.<br />
<br />
<br />
If the ALF Event manager is already paused this operation just returns without taking any action.<br />
<br />
<br />
Note: Should pausing queue events?<br />
<br />
=== Pause Application ===<br />
''void pause(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
All events currently being dispatched to the given application are completed. All event dispatching to the named application is stopped. Events received for the given application are logged but lost.<br />
<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
If an application is explicitly paused it must be explicitly resumed<br />
<br />
<br />
Note: Should pausing an application queue the events to that application?<br />
<br />
=== Resume ===<br />
''void resume()''<br />
<br />
Event dispatching is resumed to all applications that are not explicitly paused. If the ALF Event manager is not paused this operation just returns without taking any action.<br />
<br />
=== Resume Application ===<br />
''void resume(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
<br />
Event dispatching is resumed to the named application. If the application is not paused, this operation just returns without taking any action.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
<br />
=== Get Runtime EventMap ===<br />
''string GetEventMap(string)''<br />
<br />
<br />
The full runtime event map is returned as an XML string<br />
<br />
<br />
Note: Will this get too big for this operation to be practical?<br />
<br />
=== Get Application EventMap ===<br />
''string GetEventMap(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
The event map associated with the named application is returned as an xml formatted string.<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
<br />
=== Get Application Status ===<br />
applicationStatus[] GetApplicationStatus()<br />
An array of status structures for all the deployed applications is returned. The status structure contains, at least the application name, whether it is paused or running.<br />
Note: Should we extend this to include some minimal statistics? Fex Time deployed, time last resumed, number of events since past resume etc.<br />
=== Logging ===<br />
string[] listLogNames()<br />
The list of named logs stored by the ALF Event Manager is returned<br />
string listLog(LogName) throws alfError.invalidLogName<br />
The Content of the named log is returned as a string<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/CoreServices/AdminService&diff=11945ALF/CoreServices/AdminService2006-09-27T20:08:17Z<p>Alf tbuss.yahoo.com: /* Get Runtime EventMap */</p>
<hr />
<div>== ALF Applications ==<br />
=== Introduction ===<br />
An ALF application is a set of ALF events and Service Flows configured together with the intent of providing a coherent service. An ALF application can be expressed in an ALF Event Map.<br />
=== Building ===<br />
To build an ALF application it is necessary to construct an ALF Event Map expresses the relationships between the various ALF events and the Service Flows that are intended to run on those events. Typically the set of events and the Service Flow definitions will differ between applications. However, tools that participate in ALF cannot distinguish between ALF applications. This is left to the ALF event manager. The ALF event manager distinguishes between applications via the application name provided in the ALF Event Map<br />
=== Deployment ===<br />
To deploy an ALF application, an ALF Event Map for that application is provided to the ALF event manager. The ALF event manager loads the ALF event map and merges it into its runtime event dispatch table. The dispatch table entries are distinguished by the application name provided in the Event Map. This allows independent runtime control (pause resume etc) over each of applications deployed to the ALF event manager.<br />
An ALF event manager can host one or more ALF applications. ALF applications are distinguished by only by name. The ALF event manager does not manage versions. it is the responsibility of the deployment tool to keep track of application versions and how they are named and related. Generally this is not an issue since only one version of an application is deployed at once. Thus the deployment tool could choose to un-deploy the old version and re-deploy the new version using the same name.<br />
However, if it is desired to distinguish between versions of an application at runtime then the deployment tool must deploy these versions using different names. For example and application named “BuildAll” may have various versions over time. These may be distinguished using a naming convention that appends a version designator as in “BuildAll-1_0”, “BuildAll-1_5”, “BuildAll-2_0” etc. The ALF event manager sees these as separate applications and does not relate them in anyway. Any records generated by ALF will be correlated to the application name. If the application needs to correlate data between its various versions then either the various application versions must be deployed using the same name or the application design must provide its own mechanism to do so.<br />
=== Runtime ===<br />
ALF applications may overlap in their use of tool emitted Events and Service Flows. These entities are defined by the system configuration from the perspective of the ALF event manager. The event manager cannot implicitly distinguish them by application. If two or more applications share the same event to service flow mapping then the event manager must be able to distinguish between these cases when it is configured. In this case the event manager will treat each application’s event to service flow mapping as distinct. Where deployed applications share a common event to service flow mapping definition, it will dispatch the event once per application creating a new instance of the service flow for each application. This convention anticipates the use of separate BPEL servers per application. The separate service flow instances will be distinguished by the application identifier supplied by the event manager in the event.<br />
== ALF Event Manager Administration Service ==<br />
=== Introduction ===<br />
The ALF Event Manager has a number of runtime management controls that can be invoked via its Admin web service. These controls include<br />
• The ability to deploy and un-deploy an application event map.<br />
• The ability to pause and resume a deployed application.<br />
• The ability to retrieve a deployed application event map<br />
• The ability to report the current status of the deployed applications.<br />
• The ability to retrieve the content of the ALF Event Manager Logs<br />
=== Deploy ===<br />
''string deploy(string eventMap, bool startImmediately ) throws alfError.invalidApplicationName, alfError.invalidEventMap''<br />
<br />
<br />
The given application event map is send to the to the ALF event manager which merges it into the running event map. If “startImmediately” has the value “true” then the deployed application is immediately started and any events that match its definition are dispatched accordingly.<br />
<br />
<br />
Returns the application name from eventMap.<br />
<br />
<br />
If application named by the event map is already deployed the operation will throw alfError.invalidApplicationName .<br />
If the eventMap is invalid then the operation will throw alfError.invalidEventMap<br />
If no application name is specified in the eventMap then it is assumed to represent an application named “default”. In this case the current “default” application must be un-deployed before the new “default” application can be deployed.<br />
<br />
=== Un-deploy ===<br />
''void undeploy(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
<br />
The named application is paused (see Pause below) if it is not already in that state and then undeployed. The various event-service flow mappings are removed from the run event map.<br />
<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
<br />
=== Pause ===<br />
''void pause()''<br />
<br />
<br />
All events currently being dispatched are completed. All new event dispatching is stopped. Events received after a pause is requested are logged but will never be dispatched and may be considered lost.<br />
<br />
<br />
If the ALF Event manager is already paused this operation just returns without taking any action.<br />
<br />
<br />
Note: Should pausing queue events?<br />
<br />
=== Pause Application ===<br />
''void pause(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
All events currently being dispatched to the given application are completed. All event dispatching to the named application is stopped. Events received for the given application are logged but lost.<br />
<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
If an application is explicitly paused it must be explicitly resumed<br />
<br />
<br />
Note: Should pausing an application queue the events to that application?<br />
<br />
=== Resume ===<br />
''void resume()''<br />
<br />
Event dispatching is resumed to all applications that are not explicitly paused. If the ALF Event manager is not paused this operation just returns without taking any action.<br />
<br />
=== Resume Application ===<br />
''void resume(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
<br />
Event dispatching is resumed to the named application. If the application is not paused, this operation just returns without taking any action.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
<br />
=== Get Runtime EventMap ===<br />
''string GetEventMap(string)''<br />
<br />
<br />
The full runtime event map is returned as an XML string<br />
<br />
<br />
Note: Will this get too big for this operation to be practical?<br />
<br />
=== Get Application EventMap ===<br />
string GetEventMap(string applicationName) throws alfError.invalidApplicationName<br />
The event map associated with the named application is returned as an xml formatted string.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
=== Get Application Status ===<br />
applicationStatus[] GetApplicationStatus()<br />
An array of status structures for all the deployed applications is returned. The status structure contains, at least the application name, whether it is paused or running.<br />
Note: Should we extend this to include some minimal statistics? Fex Time deployed, time last resumed, number of events since past resume etc.<br />
=== Logging ===<br />
string[] listLogNames()<br />
The list of named logs stored by the ALF Event Manager is returned<br />
string listLog(LogName) throws alfError.invalidLogName<br />
The Content of the named log is returned as a string<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/CoreServices/AdminService&diff=11943ALF/CoreServices/AdminService2006-09-27T20:07:06Z<p>Alf tbuss.yahoo.com: /* Resume Application */</p>
<hr />
<div>== ALF Applications ==<br />
=== Introduction ===<br />
An ALF application is a set of ALF events and Service Flows configured together with the intent of providing a coherent service. An ALF application can be expressed in an ALF Event Map.<br />
=== Building ===<br />
To build an ALF application it is necessary to construct an ALF Event Map expresses the relationships between the various ALF events and the Service Flows that are intended to run on those events. Typically the set of events and the Service Flow definitions will differ between applications. However, tools that participate in ALF cannot distinguish between ALF applications. This is left to the ALF event manager. The ALF event manager distinguishes between applications via the application name provided in the ALF Event Map<br />
=== Deployment ===<br />
To deploy an ALF application, an ALF Event Map for that application is provided to the ALF event manager. The ALF event manager loads the ALF event map and merges it into its runtime event dispatch table. The dispatch table entries are distinguished by the application name provided in the Event Map. This allows independent runtime control (pause resume etc) over each of applications deployed to the ALF event manager.<br />
An ALF event manager can host one or more ALF applications. ALF applications are distinguished by only by name. The ALF event manager does not manage versions. it is the responsibility of the deployment tool to keep track of application versions and how they are named and related. Generally this is not an issue since only one version of an application is deployed at once. Thus the deployment tool could choose to un-deploy the old version and re-deploy the new version using the same name.<br />
However, if it is desired to distinguish between versions of an application at runtime then the deployment tool must deploy these versions using different names. For example and application named “BuildAll” may have various versions over time. These may be distinguished using a naming convention that appends a version designator as in “BuildAll-1_0”, “BuildAll-1_5”, “BuildAll-2_0” etc. The ALF event manager sees these as separate applications and does not relate them in anyway. Any records generated by ALF will be correlated to the application name. If the application needs to correlate data between its various versions then either the various application versions must be deployed using the same name or the application design must provide its own mechanism to do so.<br />
=== Runtime ===<br />
ALF applications may overlap in their use of tool emitted Events and Service Flows. These entities are defined by the system configuration from the perspective of the ALF event manager. The event manager cannot implicitly distinguish them by application. If two or more applications share the same event to service flow mapping then the event manager must be able to distinguish between these cases when it is configured. In this case the event manager will treat each application’s event to service flow mapping as distinct. Where deployed applications share a common event to service flow mapping definition, it will dispatch the event once per application creating a new instance of the service flow for each application. This convention anticipates the use of separate BPEL servers per application. The separate service flow instances will be distinguished by the application identifier supplied by the event manager in the event.<br />
== ALF Event Manager Administration Service ==<br />
=== Introduction ===<br />
The ALF Event Manager has a number of runtime management controls that can be invoked via its Admin web service. These controls include<br />
• The ability to deploy and un-deploy an application event map.<br />
• The ability to pause and resume a deployed application.<br />
• The ability to retrieve a deployed application event map<br />
• The ability to report the current status of the deployed applications.<br />
• The ability to retrieve the content of the ALF Event Manager Logs<br />
=== Deploy ===<br />
''string deploy(string eventMap, bool startImmediately ) throws alfError.invalidApplicationName, alfError.invalidEventMap''<br />
<br />
<br />
The given application event map is send to the to the ALF event manager which merges it into the running event map. If “startImmediately” has the value “true” then the deployed application is immediately started and any events that match its definition are dispatched accordingly.<br />
<br />
<br />
Returns the application name from eventMap.<br />
<br />
<br />
If application named by the event map is already deployed the operation will throw alfError.invalidApplicationName .<br />
If the eventMap is invalid then the operation will throw alfError.invalidEventMap<br />
If no application name is specified in the eventMap then it is assumed to represent an application named “default”. In this case the current “default” application must be un-deployed before the new “default” application can be deployed.<br />
<br />
=== Un-deploy ===<br />
''void undeploy(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
<br />
The named application is paused (see Pause below) if it is not already in that state and then undeployed. The various event-service flow mappings are removed from the run event map.<br />
<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
<br />
=== Pause ===<br />
''void pause()''<br />
<br />
<br />
All events currently being dispatched are completed. All new event dispatching is stopped. Events received after a pause is requested are logged but will never be dispatched and may be considered lost.<br />
<br />
<br />
If the ALF Event manager is already paused this operation just returns without taking any action.<br />
<br />
<br />
Note: Should pausing queue events?<br />
<br />
=== Pause Application ===<br />
''void pause(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
All events currently being dispatched to the given application are completed. All event dispatching to the named application is stopped. Events received for the given application are logged but lost.<br />
<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
If an application is explicitly paused it must be explicitly resumed<br />
<br />
<br />
Note: Should pausing an application queue the events to that application?<br />
<br />
=== Resume ===<br />
''void resume()''<br />
<br />
Event dispatching is resumed to all applications that are not explicitly paused. If the ALF Event manager is not paused this operation just returns without taking any action.<br />
<br />
=== Resume Application ===<br />
''void resume(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
<br />
Event dispatching is resumed to the named application. If the application is not paused, this operation just returns without taking any action.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
<br />
=== Get Runtime EventMap ===<br />
string GetEventMap(string)<br />
The full runtime event map is returned as an XML string<br />
Note: Will this get too big for this operation to be practical?<br />
=== Get Application EventMap ===<br />
string GetEventMap(string applicationName) throws alfError.invalidApplicationName<br />
The event map associated with the named application is returned as an xml formatted string.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
=== Get Application Status ===<br />
applicationStatus[] GetApplicationStatus()<br />
An array of status structures for all the deployed applications is returned. The status structure contains, at least the application name, whether it is paused or running.<br />
Note: Should we extend this to include some minimal statistics? Fex Time deployed, time last resumed, number of events since past resume etc.<br />
=== Logging ===<br />
string[] listLogNames()<br />
The list of named logs stored by the ALF Event Manager is returned<br />
string listLog(LogName) throws alfError.invalidLogName<br />
The Content of the named log is returned as a string<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/CoreServices/AdminService&diff=11942ALF/CoreServices/AdminService2006-09-27T20:06:47Z<p>Alf tbuss.yahoo.com: /* Resume */</p>
<hr />
<div>== ALF Applications ==<br />
=== Introduction ===<br />
An ALF application is a set of ALF events and Service Flows configured together with the intent of providing a coherent service. An ALF application can be expressed in an ALF Event Map.<br />
=== Building ===<br />
To build an ALF application it is necessary to construct an ALF Event Map expresses the relationships between the various ALF events and the Service Flows that are intended to run on those events. Typically the set of events and the Service Flow definitions will differ between applications. However, tools that participate in ALF cannot distinguish between ALF applications. This is left to the ALF event manager. The ALF event manager distinguishes between applications via the application name provided in the ALF Event Map<br />
=== Deployment ===<br />
To deploy an ALF application, an ALF Event Map for that application is provided to the ALF event manager. The ALF event manager loads the ALF event map and merges it into its runtime event dispatch table. The dispatch table entries are distinguished by the application name provided in the Event Map. This allows independent runtime control (pause resume etc) over each of applications deployed to the ALF event manager.<br />
An ALF event manager can host one or more ALF applications. ALF applications are distinguished by only by name. The ALF event manager does not manage versions. it is the responsibility of the deployment tool to keep track of application versions and how they are named and related. Generally this is not an issue since only one version of an application is deployed at once. Thus the deployment tool could choose to un-deploy the old version and re-deploy the new version using the same name.<br />
However, if it is desired to distinguish between versions of an application at runtime then the deployment tool must deploy these versions using different names. For example and application named “BuildAll” may have various versions over time. These may be distinguished using a naming convention that appends a version designator as in “BuildAll-1_0”, “BuildAll-1_5”, “BuildAll-2_0” etc. The ALF event manager sees these as separate applications and does not relate them in anyway. Any records generated by ALF will be correlated to the application name. If the application needs to correlate data between its various versions then either the various application versions must be deployed using the same name or the application design must provide its own mechanism to do so.<br />
=== Runtime ===<br />
ALF applications may overlap in their use of tool emitted Events and Service Flows. These entities are defined by the system configuration from the perspective of the ALF event manager. The event manager cannot implicitly distinguish them by application. If two or more applications share the same event to service flow mapping then the event manager must be able to distinguish between these cases when it is configured. In this case the event manager will treat each application’s event to service flow mapping as distinct. Where deployed applications share a common event to service flow mapping definition, it will dispatch the event once per application creating a new instance of the service flow for each application. This convention anticipates the use of separate BPEL servers per application. The separate service flow instances will be distinguished by the application identifier supplied by the event manager in the event.<br />
== ALF Event Manager Administration Service ==<br />
=== Introduction ===<br />
The ALF Event Manager has a number of runtime management controls that can be invoked via its Admin web service. These controls include<br />
• The ability to deploy and un-deploy an application event map.<br />
• The ability to pause and resume a deployed application.<br />
• The ability to retrieve a deployed application event map<br />
• The ability to report the current status of the deployed applications.<br />
• The ability to retrieve the content of the ALF Event Manager Logs<br />
=== Deploy ===<br />
''string deploy(string eventMap, bool startImmediately ) throws alfError.invalidApplicationName, alfError.invalidEventMap''<br />
<br />
<br />
The given application event map is send to the to the ALF event manager which merges it into the running event map. If “startImmediately” has the value “true” then the deployed application is immediately started and any events that match its definition are dispatched accordingly.<br />
<br />
<br />
Returns the application name from eventMap.<br />
<br />
<br />
If application named by the event map is already deployed the operation will throw alfError.invalidApplicationName .<br />
If the eventMap is invalid then the operation will throw alfError.invalidEventMap<br />
If no application name is specified in the eventMap then it is assumed to represent an application named “default”. In this case the current “default” application must be un-deployed before the new “default” application can be deployed.<br />
<br />
=== Un-deploy ===<br />
''void undeploy(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
<br />
The named application is paused (see Pause below) if it is not already in that state and then undeployed. The various event-service flow mappings are removed from the run event map.<br />
<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
<br />
=== Pause ===<br />
''void pause()''<br />
<br />
<br />
All events currently being dispatched are completed. All new event dispatching is stopped. Events received after a pause is requested are logged but will never be dispatched and may be considered lost.<br />
<br />
<br />
If the ALF Event manager is already paused this operation just returns without taking any action.<br />
<br />
<br />
Note: Should pausing queue events?<br />
<br />
=== Pause Application ===<br />
''void pause(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
All events currently being dispatched to the given application are completed. All event dispatching to the named application is stopped. Events received for the given application are logged but lost.<br />
<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
If an application is explicitly paused it must be explicitly resumed<br />
<br />
<br />
Note: Should pausing an application queue the events to that application?<br />
<br />
=== Resume ===<br />
''void resume()''<br />
<br />
Event dispatching is resumed to all applications that are not explicitly paused. If the ALF Event manager is not paused this operation just returns without taking any action.<br />
<br />
=== Resume Application ===<br />
void resume(string applicationName) throws alfError.invalidApplicationName<br />
<br />
Event dispatching is resumed to the named application. If the application is not paused, this operation just returns without taking any action.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
=== Get Runtime EventMap ===<br />
string GetEventMap(string)<br />
The full runtime event map is returned as an XML string<br />
Note: Will this get too big for this operation to be practical?<br />
=== Get Application EventMap ===<br />
string GetEventMap(string applicationName) throws alfError.invalidApplicationName<br />
The event map associated with the named application is returned as an xml formatted string.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
=== Get Application Status ===<br />
applicationStatus[] GetApplicationStatus()<br />
An array of status structures for all the deployed applications is returned. The status structure contains, at least the application name, whether it is paused or running.<br />
Note: Should we extend this to include some minimal statistics? Fex Time deployed, time last resumed, number of events since past resume etc.<br />
=== Logging ===<br />
string[] listLogNames()<br />
The list of named logs stored by the ALF Event Manager is returned<br />
string listLog(LogName) throws alfError.invalidLogName<br />
The Content of the named log is returned as a string<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/CoreServices/AdminService&diff=11941ALF/CoreServices/AdminService2006-09-27T20:06:26Z<p>Alf tbuss.yahoo.com: /* Pause Application */</p>
<hr />
<div>== ALF Applications ==<br />
=== Introduction ===<br />
An ALF application is a set of ALF events and Service Flows configured together with the intent of providing a coherent service. An ALF application can be expressed in an ALF Event Map.<br />
=== Building ===<br />
To build an ALF application it is necessary to construct an ALF Event Map expresses the relationships between the various ALF events and the Service Flows that are intended to run on those events. Typically the set of events and the Service Flow definitions will differ between applications. However, tools that participate in ALF cannot distinguish between ALF applications. This is left to the ALF event manager. The ALF event manager distinguishes between applications via the application name provided in the ALF Event Map<br />
=== Deployment ===<br />
To deploy an ALF application, an ALF Event Map for that application is provided to the ALF event manager. The ALF event manager loads the ALF event map and merges it into its runtime event dispatch table. The dispatch table entries are distinguished by the application name provided in the Event Map. This allows independent runtime control (pause resume etc) over each of applications deployed to the ALF event manager.<br />
An ALF event manager can host one or more ALF applications. ALF applications are distinguished by only by name. The ALF event manager does not manage versions. it is the responsibility of the deployment tool to keep track of application versions and how they are named and related. Generally this is not an issue since only one version of an application is deployed at once. Thus the deployment tool could choose to un-deploy the old version and re-deploy the new version using the same name.<br />
However, if it is desired to distinguish between versions of an application at runtime then the deployment tool must deploy these versions using different names. For example and application named “BuildAll” may have various versions over time. These may be distinguished using a naming convention that appends a version designator as in “BuildAll-1_0”, “BuildAll-1_5”, “BuildAll-2_0” etc. The ALF event manager sees these as separate applications and does not relate them in anyway. Any records generated by ALF will be correlated to the application name. If the application needs to correlate data between its various versions then either the various application versions must be deployed using the same name or the application design must provide its own mechanism to do so.<br />
=== Runtime ===<br />
ALF applications may overlap in their use of tool emitted Events and Service Flows. These entities are defined by the system configuration from the perspective of the ALF event manager. The event manager cannot implicitly distinguish them by application. If two or more applications share the same event to service flow mapping then the event manager must be able to distinguish between these cases when it is configured. In this case the event manager will treat each application’s event to service flow mapping as distinct. Where deployed applications share a common event to service flow mapping definition, it will dispatch the event once per application creating a new instance of the service flow for each application. This convention anticipates the use of separate BPEL servers per application. The separate service flow instances will be distinguished by the application identifier supplied by the event manager in the event.<br />
== ALF Event Manager Administration Service ==<br />
=== Introduction ===<br />
The ALF Event Manager has a number of runtime management controls that can be invoked via its Admin web service. These controls include<br />
• The ability to deploy and un-deploy an application event map.<br />
• The ability to pause and resume a deployed application.<br />
• The ability to retrieve a deployed application event map<br />
• The ability to report the current status of the deployed applications.<br />
• The ability to retrieve the content of the ALF Event Manager Logs<br />
=== Deploy ===<br />
''string deploy(string eventMap, bool startImmediately ) throws alfError.invalidApplicationName, alfError.invalidEventMap''<br />
<br />
<br />
The given application event map is send to the to the ALF event manager which merges it into the running event map. If “startImmediately” has the value “true” then the deployed application is immediately started and any events that match its definition are dispatched accordingly.<br />
<br />
<br />
Returns the application name from eventMap.<br />
<br />
<br />
If application named by the event map is already deployed the operation will throw alfError.invalidApplicationName .<br />
If the eventMap is invalid then the operation will throw alfError.invalidEventMap<br />
If no application name is specified in the eventMap then it is assumed to represent an application named “default”. In this case the current “default” application must be un-deployed before the new “default” application can be deployed.<br />
<br />
=== Un-deploy ===<br />
''void undeploy(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
<br />
The named application is paused (see Pause below) if it is not already in that state and then undeployed. The various event-service flow mappings are removed from the run event map.<br />
<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
<br />
=== Pause ===<br />
''void pause()''<br />
<br />
<br />
All events currently being dispatched are completed. All new event dispatching is stopped. Events received after a pause is requested are logged but will never be dispatched and may be considered lost.<br />
<br />
<br />
If the ALF Event manager is already paused this operation just returns without taking any action.<br />
<br />
<br />
Note: Should pausing queue events?<br />
<br />
=== Pause Application ===<br />
''void pause(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
All events currently being dispatched to the given application are completed. All event dispatching to the named application is stopped. Events received for the given application are logged but lost.<br />
<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
If an application is explicitly paused it must be explicitly resumed<br />
<br />
<br />
Note: Should pausing an application queue the events to that application?<br />
<br />
=== Resume ===<br />
void resume()<br />
<br />
Event dispatching is resumed to all applications that are not explicitly paused. If the ALF Event manager is not paused this operation just returns without taking any action.<br />
<br />
=== Resume Application ===<br />
void resume(string applicationName) throws alfError.invalidApplicationName<br />
<br />
Event dispatching is resumed to the named application. If the application is not paused, this operation just returns without taking any action.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
=== Get Runtime EventMap ===<br />
string GetEventMap(string)<br />
The full runtime event map is returned as an XML string<br />
Note: Will this get too big for this operation to be practical?<br />
=== Get Application EventMap ===<br />
string GetEventMap(string applicationName) throws alfError.invalidApplicationName<br />
The event map associated with the named application is returned as an xml formatted string.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
=== Get Application Status ===<br />
applicationStatus[] GetApplicationStatus()<br />
An array of status structures for all the deployed applications is returned. The status structure contains, at least the application name, whether it is paused or running.<br />
Note: Should we extend this to include some minimal statistics? Fex Time deployed, time last resumed, number of events since past resume etc.<br />
=== Logging ===<br />
string[] listLogNames()<br />
The list of named logs stored by the ALF Event Manager is returned<br />
string listLog(LogName) throws alfError.invalidLogName<br />
The Content of the named log is returned as a string<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/CoreServices/AdminService&diff=11940ALF/CoreServices/AdminService2006-09-27T20:06:02Z<p>Alf tbuss.yahoo.com: /* Pause */</p>
<hr />
<div>== ALF Applications ==<br />
=== Introduction ===<br />
An ALF application is a set of ALF events and Service Flows configured together with the intent of providing a coherent service. An ALF application can be expressed in an ALF Event Map.<br />
=== Building ===<br />
To build an ALF application it is necessary to construct an ALF Event Map expresses the relationships between the various ALF events and the Service Flows that are intended to run on those events. Typically the set of events and the Service Flow definitions will differ between applications. However, tools that participate in ALF cannot distinguish between ALF applications. This is left to the ALF event manager. The ALF event manager distinguishes between applications via the application name provided in the ALF Event Map<br />
=== Deployment ===<br />
To deploy an ALF application, an ALF Event Map for that application is provided to the ALF event manager. The ALF event manager loads the ALF event map and merges it into its runtime event dispatch table. The dispatch table entries are distinguished by the application name provided in the Event Map. This allows independent runtime control (pause resume etc) over each of applications deployed to the ALF event manager.<br />
An ALF event manager can host one or more ALF applications. ALF applications are distinguished by only by name. The ALF event manager does not manage versions. it is the responsibility of the deployment tool to keep track of application versions and how they are named and related. Generally this is not an issue since only one version of an application is deployed at once. Thus the deployment tool could choose to un-deploy the old version and re-deploy the new version using the same name.<br />
However, if it is desired to distinguish between versions of an application at runtime then the deployment tool must deploy these versions using different names. For example and application named “BuildAll” may have various versions over time. These may be distinguished using a naming convention that appends a version designator as in “BuildAll-1_0”, “BuildAll-1_5”, “BuildAll-2_0” etc. The ALF event manager sees these as separate applications and does not relate them in anyway. Any records generated by ALF will be correlated to the application name. If the application needs to correlate data between its various versions then either the various application versions must be deployed using the same name or the application design must provide its own mechanism to do so.<br />
=== Runtime ===<br />
ALF applications may overlap in their use of tool emitted Events and Service Flows. These entities are defined by the system configuration from the perspective of the ALF event manager. The event manager cannot implicitly distinguish them by application. If two or more applications share the same event to service flow mapping then the event manager must be able to distinguish between these cases when it is configured. In this case the event manager will treat each application’s event to service flow mapping as distinct. Where deployed applications share a common event to service flow mapping definition, it will dispatch the event once per application creating a new instance of the service flow for each application. This convention anticipates the use of separate BPEL servers per application. The separate service flow instances will be distinguished by the application identifier supplied by the event manager in the event.<br />
== ALF Event Manager Administration Service ==<br />
=== Introduction ===<br />
The ALF Event Manager has a number of runtime management controls that can be invoked via its Admin web service. These controls include<br />
• The ability to deploy and un-deploy an application event map.<br />
• The ability to pause and resume a deployed application.<br />
• The ability to retrieve a deployed application event map<br />
• The ability to report the current status of the deployed applications.<br />
• The ability to retrieve the content of the ALF Event Manager Logs<br />
=== Deploy ===<br />
''string deploy(string eventMap, bool startImmediately ) throws alfError.invalidApplicationName, alfError.invalidEventMap''<br />
<br />
<br />
The given application event map is send to the to the ALF event manager which merges it into the running event map. If “startImmediately” has the value “true” then the deployed application is immediately started and any events that match its definition are dispatched accordingly.<br />
<br />
<br />
Returns the application name from eventMap.<br />
<br />
<br />
If application named by the event map is already deployed the operation will throw alfError.invalidApplicationName .<br />
If the eventMap is invalid then the operation will throw alfError.invalidEventMap<br />
If no application name is specified in the eventMap then it is assumed to represent an application named “default”. In this case the current “default” application must be un-deployed before the new “default” application can be deployed.<br />
<br />
=== Un-deploy ===<br />
''void undeploy(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
<br />
The named application is paused (see Pause below) if it is not already in that state and then undeployed. The various event-service flow mappings are removed from the run event map.<br />
<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
<br />
=== Pause ===<br />
''void pause()''<br />
<br />
<br />
All events currently being dispatched are completed. All new event dispatching is stopped. Events received after a pause is requested are logged but will never be dispatched and may be considered lost.<br />
<br />
<br />
If the ALF Event manager is already paused this operation just returns without taking any action.<br />
<br />
<br />
Note: Should pausing queue events?<br />
<br />
=== Pause Application ===<br />
void pause(string applicationName) throws alfError.invalidApplicationName<br />
<br />
All events currently being dispatched to the given application are completed. All event dispatching to the named application is stopped. Events received for the given application are logged but lost. <br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
If an application is explicitly paused it must be explicitly resumed<br />
Note: Should pausing an application queue the events to that application?<br />
=== Resume ===<br />
void resume()<br />
<br />
Event dispatching is resumed to all applications that are not explicitly paused. If the ALF Event manager is not paused this operation just returns without taking any action.<br />
<br />
=== Resume Application ===<br />
void resume(string applicationName) throws alfError.invalidApplicationName<br />
<br />
Event dispatching is resumed to the named application. If the application is not paused, this operation just returns without taking any action.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
=== Get Runtime EventMap ===<br />
string GetEventMap(string)<br />
The full runtime event map is returned as an XML string<br />
Note: Will this get too big for this operation to be practical?<br />
=== Get Application EventMap ===<br />
string GetEventMap(string applicationName) throws alfError.invalidApplicationName<br />
The event map associated with the named application is returned as an xml formatted string.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
=== Get Application Status ===<br />
applicationStatus[] GetApplicationStatus()<br />
An array of status structures for all the deployed applications is returned. The status structure contains, at least the application name, whether it is paused or running.<br />
Note: Should we extend this to include some minimal statistics? Fex Time deployed, time last resumed, number of events since past resume etc.<br />
=== Logging ===<br />
string[] listLogNames()<br />
The list of named logs stored by the ALF Event Manager is returned<br />
string listLog(LogName) throws alfError.invalidLogName<br />
The Content of the named log is returned as a string<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/CoreServices/AdminService&diff=11939ALF/CoreServices/AdminService2006-09-27T20:05:19Z<p>Alf tbuss.yahoo.com: /* Un-deploy */</p>
<hr />
<div>== ALF Applications ==<br />
=== Introduction ===<br />
An ALF application is a set of ALF events and Service Flows configured together with the intent of providing a coherent service. An ALF application can be expressed in an ALF Event Map.<br />
=== Building ===<br />
To build an ALF application it is necessary to construct an ALF Event Map expresses the relationships between the various ALF events and the Service Flows that are intended to run on those events. Typically the set of events and the Service Flow definitions will differ between applications. However, tools that participate in ALF cannot distinguish between ALF applications. This is left to the ALF event manager. The ALF event manager distinguishes between applications via the application name provided in the ALF Event Map<br />
=== Deployment ===<br />
To deploy an ALF application, an ALF Event Map for that application is provided to the ALF event manager. The ALF event manager loads the ALF event map and merges it into its runtime event dispatch table. The dispatch table entries are distinguished by the application name provided in the Event Map. This allows independent runtime control (pause resume etc) over each of applications deployed to the ALF event manager.<br />
An ALF event manager can host one or more ALF applications. ALF applications are distinguished by only by name. The ALF event manager does not manage versions. it is the responsibility of the deployment tool to keep track of application versions and how they are named and related. Generally this is not an issue since only one version of an application is deployed at once. Thus the deployment tool could choose to un-deploy the old version and re-deploy the new version using the same name.<br />
However, if it is desired to distinguish between versions of an application at runtime then the deployment tool must deploy these versions using different names. For example and application named “BuildAll” may have various versions over time. These may be distinguished using a naming convention that appends a version designator as in “BuildAll-1_0”, “BuildAll-1_5”, “BuildAll-2_0” etc. The ALF event manager sees these as separate applications and does not relate them in anyway. Any records generated by ALF will be correlated to the application name. If the application needs to correlate data between its various versions then either the various application versions must be deployed using the same name or the application design must provide its own mechanism to do so.<br />
=== Runtime ===<br />
ALF applications may overlap in their use of tool emitted Events and Service Flows. These entities are defined by the system configuration from the perspective of the ALF event manager. The event manager cannot implicitly distinguish them by application. If two or more applications share the same event to service flow mapping then the event manager must be able to distinguish between these cases when it is configured. In this case the event manager will treat each application’s event to service flow mapping as distinct. Where deployed applications share a common event to service flow mapping definition, it will dispatch the event once per application creating a new instance of the service flow for each application. This convention anticipates the use of separate BPEL servers per application. The separate service flow instances will be distinguished by the application identifier supplied by the event manager in the event.<br />
== ALF Event Manager Administration Service ==<br />
=== Introduction ===<br />
The ALF Event Manager has a number of runtime management controls that can be invoked via its Admin web service. These controls include<br />
• The ability to deploy and un-deploy an application event map.<br />
• The ability to pause and resume a deployed application.<br />
• The ability to retrieve a deployed application event map<br />
• The ability to report the current status of the deployed applications.<br />
• The ability to retrieve the content of the ALF Event Manager Logs<br />
=== Deploy ===<br />
''string deploy(string eventMap, bool startImmediately ) throws alfError.invalidApplicationName, alfError.invalidEventMap''<br />
<br />
<br />
The given application event map is send to the to the ALF event manager which merges it into the running event map. If “startImmediately” has the value “true” then the deployed application is immediately started and any events that match its definition are dispatched accordingly.<br />
<br />
<br />
Returns the application name from eventMap.<br />
<br />
<br />
If application named by the event map is already deployed the operation will throw alfError.invalidApplicationName .<br />
If the eventMap is invalid then the operation will throw alfError.invalidEventMap<br />
If no application name is specified in the eventMap then it is assumed to represent an application named “default”. In this case the current “default” application must be un-deployed before the new “default” application can be deployed.<br />
<br />
=== Un-deploy ===<br />
''void undeploy(string applicationName) throws alfError.invalidApplicationName''<br />
<br />
<br />
The named application is paused (see Pause below) if it is not already in that state and then undeployed. The various event-service flow mappings are removed from the run event map.<br />
<br />
<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
<br />
=== Pause ===<br />
void pause()<br />
All events currently being dispatched are completed. All new event dispatching is stopped. Events received after a pause is requested are logged but will never be dispatched and may be considered lost.<br />
If the ALF Event manager is already paused this operation just returns without taking any action.<br />
Note: Should pausing queue events?<br />
=== Pause Application ===<br />
void pause(string applicationName) throws alfError.invalidApplicationName<br />
<br />
All events currently being dispatched to the given application are completed. All event dispatching to the named application is stopped. Events received for the given application are logged but lost. <br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
If an application is explicitly paused it must be explicitly resumed<br />
Note: Should pausing an application queue the events to that application?<br />
=== Resume ===<br />
void resume()<br />
<br />
Event dispatching is resumed to all applications that are not explicitly paused. If the ALF Event manager is not paused this operation just returns without taking any action.<br />
<br />
=== Resume Application ===<br />
void resume(string applicationName) throws alfError.invalidApplicationName<br />
<br />
Event dispatching is resumed to the named application. If the application is not paused, this operation just returns without taking any action.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
=== Get Runtime EventMap ===<br />
string GetEventMap(string)<br />
The full runtime event map is returned as an XML string<br />
Note: Will this get too big for this operation to be practical?<br />
=== Get Application EventMap ===<br />
string GetEventMap(string applicationName) throws alfError.invalidApplicationName<br />
The event map associated with the named application is returned as an xml formatted string.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
=== Get Application Status ===<br />
applicationStatus[] GetApplicationStatus()<br />
An array of status structures for all the deployed applications is returned. The status structure contains, at least the application name, whether it is paused or running.<br />
Note: Should we extend this to include some minimal statistics? Fex Time deployed, time last resumed, number of events since past resume etc.<br />
=== Logging ===<br />
string[] listLogNames()<br />
The list of named logs stored by the ALF Event Manager is returned<br />
string listLog(LogName) throws alfError.invalidLogName<br />
The Content of the named log is returned as a string<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/CoreServices/AdminService&diff=11938ALF/CoreServices/AdminService2006-09-27T20:04:56Z<p>Alf tbuss.yahoo.com: /* Deploy */</p>
<hr />
<div>== ALF Applications ==<br />
=== Introduction ===<br />
An ALF application is a set of ALF events and Service Flows configured together with the intent of providing a coherent service. An ALF application can be expressed in an ALF Event Map.<br />
=== Building ===<br />
To build an ALF application it is necessary to construct an ALF Event Map expresses the relationships between the various ALF events and the Service Flows that are intended to run on those events. Typically the set of events and the Service Flow definitions will differ between applications. However, tools that participate in ALF cannot distinguish between ALF applications. This is left to the ALF event manager. The ALF event manager distinguishes between applications via the application name provided in the ALF Event Map<br />
=== Deployment ===<br />
To deploy an ALF application, an ALF Event Map for that application is provided to the ALF event manager. The ALF event manager loads the ALF event map and merges it into its runtime event dispatch table. The dispatch table entries are distinguished by the application name provided in the Event Map. This allows independent runtime control (pause resume etc) over each of applications deployed to the ALF event manager.<br />
An ALF event manager can host one or more ALF applications. ALF applications are distinguished by only by name. The ALF event manager does not manage versions. it is the responsibility of the deployment tool to keep track of application versions and how they are named and related. Generally this is not an issue since only one version of an application is deployed at once. Thus the deployment tool could choose to un-deploy the old version and re-deploy the new version using the same name.<br />
However, if it is desired to distinguish between versions of an application at runtime then the deployment tool must deploy these versions using different names. For example and application named “BuildAll” may have various versions over time. These may be distinguished using a naming convention that appends a version designator as in “BuildAll-1_0”, “BuildAll-1_5”, “BuildAll-2_0” etc. The ALF event manager sees these as separate applications and does not relate them in anyway. Any records generated by ALF will be correlated to the application name. If the application needs to correlate data between its various versions then either the various application versions must be deployed using the same name or the application design must provide its own mechanism to do so.<br />
=== Runtime ===<br />
ALF applications may overlap in their use of tool emitted Events and Service Flows. These entities are defined by the system configuration from the perspective of the ALF event manager. The event manager cannot implicitly distinguish them by application. If two or more applications share the same event to service flow mapping then the event manager must be able to distinguish between these cases when it is configured. In this case the event manager will treat each application’s event to service flow mapping as distinct. Where deployed applications share a common event to service flow mapping definition, it will dispatch the event once per application creating a new instance of the service flow for each application. This convention anticipates the use of separate BPEL servers per application. The separate service flow instances will be distinguished by the application identifier supplied by the event manager in the event.<br />
== ALF Event Manager Administration Service ==<br />
=== Introduction ===<br />
The ALF Event Manager has a number of runtime management controls that can be invoked via its Admin web service. These controls include<br />
• The ability to deploy and un-deploy an application event map.<br />
• The ability to pause and resume a deployed application.<br />
• The ability to retrieve a deployed application event map<br />
• The ability to report the current status of the deployed applications.<br />
• The ability to retrieve the content of the ALF Event Manager Logs<br />
=== Deploy ===<br />
''string deploy(string eventMap, bool startImmediately ) throws alfError.invalidApplicationName, alfError.invalidEventMap''<br />
<br />
<br />
The given application event map is send to the to the ALF event manager which merges it into the running event map. If “startImmediately” has the value “true” then the deployed application is immediately started and any events that match its definition are dispatched accordingly.<br />
<br />
<br />
Returns the application name from eventMap.<br />
<br />
<br />
If application named by the event map is already deployed the operation will throw alfError.invalidApplicationName .<br />
If the eventMap is invalid then the operation will throw alfError.invalidEventMap<br />
If no application name is specified in the eventMap then it is assumed to represent an application named “default”. In this case the current “default” application must be un-deployed before the new “default” application can be deployed.<br />
<br />
=== Un-deploy ===<br />
void undeploy(string applicationName) throws alfError.invalidApplicationName<br />
The named application is paused (see Pause below) if it is not already in that state and then undeployed. The various event-service flow mappings are removed from the run event map.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
=== Pause ===<br />
void pause()<br />
All events currently being dispatched are completed. All new event dispatching is stopped. Events received after a pause is requested are logged but will never be dispatched and may be considered lost.<br />
If the ALF Event manager is already paused this operation just returns without taking any action.<br />
Note: Should pausing queue events?<br />
=== Pause Application ===<br />
void pause(string applicationName) throws alfError.invalidApplicationName<br />
<br />
All events currently being dispatched to the given application are completed. All event dispatching to the named application is stopped. Events received for the given application are logged but lost. <br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
If an application is explicitly paused it must be explicitly resumed<br />
Note: Should pausing an application queue the events to that application?<br />
=== Resume ===<br />
void resume()<br />
<br />
Event dispatching is resumed to all applications that are not explicitly paused. If the ALF Event manager is not paused this operation just returns without taking any action.<br />
<br />
=== Resume Application ===<br />
void resume(string applicationName) throws alfError.invalidApplicationName<br />
<br />
Event dispatching is resumed to the named application. If the application is not paused, this operation just returns without taking any action.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
=== Get Runtime EventMap ===<br />
string GetEventMap(string)<br />
The full runtime event map is returned as an XML string<br />
Note: Will this get too big for this operation to be practical?<br />
=== Get Application EventMap ===<br />
string GetEventMap(string applicationName) throws alfError.invalidApplicationName<br />
The event map associated with the named application is returned as an xml formatted string.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
=== Get Application Status ===<br />
applicationStatus[] GetApplicationStatus()<br />
An array of status structures for all the deployed applications is returned. The status structure contains, at least the application name, whether it is paused or running.<br />
Note: Should we extend this to include some minimal statistics? Fex Time deployed, time last resumed, number of events since past resume etc.<br />
=== Logging ===<br />
string[] listLogNames()<br />
The list of named logs stored by the ALF Event Manager is returned<br />
string listLog(LogName) throws alfError.invalidLogName<br />
The Content of the named log is returned as a string<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/CoreServices/AdminService&diff=11937ALF/CoreServices/AdminService2006-09-27T20:03:32Z<p>Alf tbuss.yahoo.com: </p>
<hr />
<div>== ALF Applications ==<br />
=== Introduction ===<br />
An ALF application is a set of ALF events and Service Flows configured together with the intent of providing a coherent service. An ALF application can be expressed in an ALF Event Map.<br />
=== Building ===<br />
To build an ALF application it is necessary to construct an ALF Event Map expresses the relationships between the various ALF events and the Service Flows that are intended to run on those events. Typically the set of events and the Service Flow definitions will differ between applications. However, tools that participate in ALF cannot distinguish between ALF applications. This is left to the ALF event manager. The ALF event manager distinguishes between applications via the application name provided in the ALF Event Map<br />
=== Deployment ===<br />
To deploy an ALF application, an ALF Event Map for that application is provided to the ALF event manager. The ALF event manager loads the ALF event map and merges it into its runtime event dispatch table. The dispatch table entries are distinguished by the application name provided in the Event Map. This allows independent runtime control (pause resume etc) over each of applications deployed to the ALF event manager.<br />
An ALF event manager can host one or more ALF applications. ALF applications are distinguished by only by name. The ALF event manager does not manage versions. it is the responsibility of the deployment tool to keep track of application versions and how they are named and related. Generally this is not an issue since only one version of an application is deployed at once. Thus the deployment tool could choose to un-deploy the old version and re-deploy the new version using the same name.<br />
However, if it is desired to distinguish between versions of an application at runtime then the deployment tool must deploy these versions using different names. For example and application named “BuildAll” may have various versions over time. These may be distinguished using a naming convention that appends a version designator as in “BuildAll-1_0”, “BuildAll-1_5”, “BuildAll-2_0” etc. The ALF event manager sees these as separate applications and does not relate them in anyway. Any records generated by ALF will be correlated to the application name. If the application needs to correlate data between its various versions then either the various application versions must be deployed using the same name or the application design must provide its own mechanism to do so.<br />
=== Runtime ===<br />
ALF applications may overlap in their use of tool emitted Events and Service Flows. These entities are defined by the system configuration from the perspective of the ALF event manager. The event manager cannot implicitly distinguish them by application. If two or more applications share the same event to service flow mapping then the event manager must be able to distinguish between these cases when it is configured. In this case the event manager will treat each application’s event to service flow mapping as distinct. Where deployed applications share a common event to service flow mapping definition, it will dispatch the event once per application creating a new instance of the service flow for each application. This convention anticipates the use of separate BPEL servers per application. The separate service flow instances will be distinguished by the application identifier supplied by the event manager in the event.<br />
== ALF Event Manager Administration Service ==<br />
=== Introduction ===<br />
The ALF Event Manager has a number of runtime management controls that can be invoked via its Admin web service. These controls include<br />
• The ability to deploy and un-deploy an application event map.<br />
• The ability to pause and resume a deployed application.<br />
• The ability to retrieve a deployed application event map<br />
• The ability to report the current status of the deployed applications.<br />
• The ability to retrieve the content of the ALF Event Manager Logs<br />
=== Deploy ===<br />
string deploy(string eventMap, bool startImmediately ) throws alfError.invalidApplicationName, alfError.invalidEventMap<br />
The given application event map is send to the to the ALF event manager which merges it into the running event map. If “startImmediately” has the value “true” then the deployed application is immediately started and any events that match its definition are dispatched accordingly.<br />
Returns the application name from eventMap.<br />
If application named by the event map is already deployed the operation will throw alfError.invalidApplicationName .<br />
If the eventMap is invalid then the operation will throw alfError.invalidEventMap<br />
If no application name is specified in the eventMap then it is assumed to represent an application named “default”. In this case the current “default” application must be un-deployed before the new “default” application can be deployed.<br />
=== Un-deploy ===<br />
void undeploy(string applicationName) throws alfError.invalidApplicationName<br />
The named application is paused (see Pause below) if it is not already in that state and then undeployed. The various event-service flow mappings are removed from the run event map.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
=== Pause ===<br />
void pause()<br />
All events currently being dispatched are completed. All new event dispatching is stopped. Events received after a pause is requested are logged but will never be dispatched and may be considered lost.<br />
If the ALF Event manager is already paused this operation just returns without taking any action.<br />
Note: Should pausing queue events?<br />
=== Pause Application ===<br />
void pause(string applicationName) throws alfError.invalidApplicationName<br />
<br />
All events currently being dispatched to the given application are completed. All event dispatching to the named application is stopped. Events received for the given application are logged but lost. <br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
If an application is explicitly paused it must be explicitly resumed<br />
Note: Should pausing an application queue the events to that application?<br />
=== Resume ===<br />
void resume()<br />
<br />
Event dispatching is resumed to all applications that are not explicitly paused. If the ALF Event manager is not paused this operation just returns without taking any action.<br />
<br />
=== Resume Application ===<br />
void resume(string applicationName) throws alfError.invalidApplicationName<br />
<br />
Event dispatching is resumed to the named application. If the application is not paused, this operation just returns without taking any action.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
=== Get Runtime EventMap ===<br />
string GetEventMap(string)<br />
The full runtime event map is returned as an XML string<br />
Note: Will this get too big for this operation to be practical?<br />
=== Get Application EventMap ===<br />
string GetEventMap(string applicationName) throws alfError.invalidApplicationName<br />
The event map associated with the named application is returned as an xml formatted string.<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .<br />
=== Get Application Status ===<br />
applicationStatus[] GetApplicationStatus()<br />
An array of status structures for all the deployed applications is returned. The status structure contains, at least the application name, whether it is paused or running.<br />
Note: Should we extend this to include some minimal statistics? Fex Time deployed, time last resumed, number of events since past resume etc.<br />
=== Logging ===<br />
string[] listLogNames()<br />
The list of named logs stored by the ALF Event Manager is returned<br />
string listLog(LogName) throws alfError.invalidLogName<br />
The Content of the named log is returned as a string<br />
If application named by the event map is not deployed to the event manager, the operation will throw alfError.invalidApplicationName .</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/CoreServices&diff=11936ALF/CoreServices2006-09-27T19:58:57Z<p>Alf tbuss.yahoo.com: /* Core Services */</p>
<hr />
<div>== Core Services ==<br />
<br />
{|<br />
|-<br />
| [[ALF/CoreServices/AdminService | AdminService]]<br />
| <br />
|}</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/CoreServices&diff=11935ALF/CoreServices2006-09-27T19:58:28Z<p>Alf tbuss.yahoo.com: </p>
<hr />
<div>== Core Services ==<br />
<br />
{|<br />
|-<br />
| [[ALF/CoreServices | CoreServices]]<br />
| Core service designs<br />
|}</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/CoreServices&diff=11934ALF/CoreServices2006-09-27T19:57:25Z<p>Alf tbuss.yahoo.com: /* Core Services */</p>
<hr />
<div>== Core Services ==<br />
<br />
{|<br />
|-<br />
| [[ALF/CoreServices/AdminService | AdminService]]<br />
|<br />
}</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/CoreServices&diff=11933ALF/CoreServices2006-09-27T19:56:38Z<p>Alf tbuss.yahoo.com: </p>
<hr />
<div>== Core Services ==<br />
<br />
{|<br />
|-<br />
| [[ALF/CoreServices | CoreServices]]<br />
| Core service designs<br />
}</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF&diff=11932ALF2006-09-27T19:54:54Z<p>Alf tbuss.yahoo.com: /* Developer Resources */</p>
<hr />
<div>Welcome to the ALF Wiki page. Come back often for the latest and greatest about ALF.<br />
<br />
The Application Lifecycle Framework (ALF) Project enables development and IT tools to be orchestrated in support of the consumer’s business needs. ALF provides the logical definition of the overall interoperability business process. This technology handles the exchange of information from one tool to another, the business logic governing the sequencing of tools in support of the application lifecycle process, and the routing of significant events as tools interact. ALF achieves this by providing a common infrastructure (SOAP Web Services, BPEL orchestration engine and the ALF Event Manager), and a set of domain vocabularies that define the events, objects and attributes. Together these address the issues of tool interoperability and interchangeability, process segmentation, reusability, and versioning. ALF provides various Common Services (logging, notifications, security, etc.) that are easily integrated into BPEL processes to create richer interoperability processes. <br />
<br />
== User Resources ==<br />
<br />
{|<br />
| [http://www.eclipse.org/alf/ ALF Project Home]<br />
| The home page for the ALF project.<br />
|-<br />
| [http://www.eclipse.org/alf/alffaq.php FAQ]<br />
| Answers to the most common questions about ALF. This should be the first place you go for any Question that you may have.<br />
|-<br />
|-<br />
| [http://www.eclipse.org/alf/alfabout.php Objectives]<br />
| Full description of the project objectives, project plan and architectural approach.<br />
|-<br />
|}<br />
<br />
== Developer Resources ==<br />
<br />
{|<br />
| [http://bugs.eclipse.org/bugs Eclipse Bugzilla]<br />
| Enter and check on ALF bugs here.<br />
|-<br />
| [https://dev.eclipse.org/mailman/listinfo/alf-dev Developer Mailing List]<br />
| Subscribe to the mailing list or access the archives.<br />
|-<br />
| [[ALF/requirements | Requirements]]<br />
| Requirements docs<br />
|-<br />
| [[ALF/architecture | Architecture]]<br />
| Architecture and design docs<br />
|-<br />
| [[ALF/CoreServices | CoreServices]]<br />
| Core service designs<br />
|-<br />
| [[ALF/vocabularies | Vocabularies]]<br />
| Documentation of ALF vocabularies<br />
|-<br />
| [[ALF/CommonServices | CommonServices]]<br />
| Common service designs<br />
|-<br />
| [[ALF/whoswho | Who's Who]]<br />
| Who's who in the ALF development community<br />
|-<br />
| [[ALF/planning | Planning]]<br />
| Planning information for ALF releases.<br />
|-<br />
| [[ALF/meetings | Meetings]]<br />
| Numbers and Minutes from our regular conference calls.<br />
|}</div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/Vocabularies/SCM_Vocabulary/WSDL&diff=11930ALF/Vocabularies/SCM Vocabulary/WSDL2006-09-27T19:48:02Z<p>Alf tbuss.yahoo.com: </p>
<hr />
<div>[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
== SCM Vocabulary WSDL ==<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8" ?><br />
<wsdl:definitions name="ALFSCM"<br />
targetNamespace="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
xmlns:tns="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"<br />
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"<br />
xmlns:xsd="http://www.w3.org/2001/XMLSchema"><br />
<wsdl:documentation><br />
Copyright Notice The material in this document is Copyright (c)<br />
Serena Software, Inc. and others, 2005, 2006 Terms and<br />
Conditions: The Eclipse Foundation makes available all content<br />
in this document ("Content"). Unless otherwise indicated below,<br />
the Content is provided to you under the terms and conditions of<br />
the Eclipse Public License Version 1.0 ("EPL"). A copy of the<br />
EPL is available at http://www.eclipse.org/legal/epl-v10.html.<br />
For purposes of the EPL, "Program" will mean the Content. If you<br />
did not receive this Content directly from the Eclipse<br />
Foundation, the Content is being redistributed by another party<br />
("Redistributor") and different terms and conditions may apply<br />
to your use of any object code in the Content. Check the<br />
Redistributor's license that was provided with the Content. If<br />
you did not receive any such license, contact the Redistributor.<br />
Unless otherwise indicated below, the terms and conditions of<br />
the EPL still apply to the Content.<br />
</wsdl:documentation><br />
<!-- ALF SCM WSDL <br />
--><br />
<wsdl:types><br />
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"<br />
targetNamespace="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
xmlns:tns="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
elementFormDefault="qualified" attributeFormDefault="unqualified"><br />
<xsd:include schemaLocation="ALFSCM.xsd" /><br />
<xsd:complexType name="PromoteRequestType"><br />
<xsd:sequence><br />
<xsd:element name="fromBranchID" type="xsd:string" /><br />
<xsd:element name="toBranchID" type="xsd:string" /><br />
<xsd:element name="elementVersionList"<br />
type="ElementVersionCollectionType" nillable="true" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="PromoteResponseType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:element name="promoteRequest"<br />
type="PromoteRequestType" /><br />
<xsd:element name="promoteResponse"<br />
type="PromoteResponseType" /><br />
<xsd:complexType name="CreateBaselineRequestType"><br />
<xsd:sequence><br />
<xsd:element name="baselineName" type="xsd:string" /><br />
<xsd:element name="branchID" type="xsd:string" /><br />
<xsd:element name="configurationID"<br />
type="xsd:string" nillable="true" /><br />
<xsd:element name="otherOptions" type="xsd:string"<br />
nillable="true" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="CreateBaselineResponseType"><br />
<xsd:sequence><br />
<xsd:element name="baselineID" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:element name="createBaselineRequest"<br />
type="CreateBaselineRequestType" /><br />
<xsd:element name="createBaselineResponse"<br />
type="CreateBaselineResponseType" /><br />
<xsd:complexType name="CreateBranchRequestType"><br />
<xsd:sequence><br />
<xsd:element name="branchName" type="xsd:string" /><br />
<xsd:element name="parentBranchID"<br />
type="xsd:string" /><br />
<xsd:element name="timeBasis" type="TimestampType"<br />
nillable="true" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="CreateBranchResponseType"><br />
<xsd:sequence><br />
<xsd:element name="branchID" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:element name="createBranchRequest"<br />
type="CreateBranchRequestType" /><br />
<xsd:element name="createBranchResponse"<br />
type="CreateBranchResponseType" /><br />
<xsd:complexType name="RemoveAssetsRequestType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:complexType name="RemoveAssetsResponseType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:element name="removeAssetsRequest"<br />
type="RemoveAssetsRequestType" /><br />
<xsd:element name="removeAssetsResponse"<br />
type="RemoveAssetsResponseType" /><br />
<xsd:complexType name="IntentToModifyRequestType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:complexType name="IntentToModifyResponseType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:element name="intentToModifyRequest"<br />
type="IntentToModifyRequestType" /><br />
<xsd:element name="intentToModifyResponse"<br />
type="IntentToModifyResponseType" /><br />
<xsd:complexType name="updateWorkspaceRequestType"><br />
<xsd:sequence><br />
<xsd:element name="baselineID" type="xsd:string" /><br />
<xsd:element name="branchID" type="xsd:string" /><br />
<xsd:element name="configurationID"<br />
type="xsd:string" /><br />
<xsd:element name="options" type="xsd:string" /><br />
<xsd:element name="otherOptions" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="updateWorkspaceResponseType"><br />
<xsd:sequence /><br />
</xsd:complexType><br />
<xsd:element name="updateWorkspaceRequest"<br />
type="updateWorkspaceRequestType" /><br />
<xsd:element name="updateWorkspaceResponse"<br />
type="updateWorkspaceResponseType" /><br />
<xsd:complexType name="createNewVersionsRequestType"><br />
<xsd:sequence><br />
<xsd:element name="branchID" type="xsd:string" /><br />
<xsd:element name="elementVersionList"<br />
type="ElementVersionCollectionType" /><br />
<xsd:element name="otherOptions" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="createNewVersionsResponseType"><br />
<xsd:sequence><br />
<xsd:element name="elementVersionList"<br />
type="ElementVersionCollectionType" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:element name="createNewVersionsRequest"<br />
type="createNewVersionsRequestType" /><br />
<xsd:element name="createNewVersionsResponse"<br />
type="createNewVersionsResponseType" /><br />
</xsd:schema><br />
</wsdl:types><br />
<wsdl:message name="PromoteRequest"><br />
<wsdl:part name="parameters" element="tns:promoteRequest" /><br />
</wsdl:message><br />
<wsdl:message name="PromoteResponse"><br />
<wsdl:part name="parameters" element="tns:promoteResponse" /><br />
</wsdl:message><br />
<wsdl:message name="CreateBaselineRequest"><br />
<wsdl:part name="parameters"<br />
element="tns:createBaselineRequest" /><br />
</wsdl:message><br />
<wsdl:message name="CreateBaselineResponse"><br />
<wsdl:part name="parameters"<br />
element="tns:createBaselineResponse" /><br />
</wsdl:message><br />
<wsdl:message name="CreateBranchRequest"><br />
<wsdl:part name="parameters" element="tns:createBranchRequest" /><br />
</wsdl:message><br />
<wsdl:message name="CreateBranchResponse"><br />
<wsdl:part name="parameters" element="tns:createBranchResponse" /><br />
</wsdl:message><br />
<wsdl:message name="RemoveAssetsRequest"><br />
<wsdl:part name="parameters" element="tns:removeAssetsRequest" /><br />
</wsdl:message><br />
<wsdl:message name="RemoveAssetsResponse"><br />
<wsdl:part name="parameters" element="tns:removeAssetsResponse" /><br />
</wsdl:message><br />
<wsdl:message name="IntentToModifyRequest"><br />
<wsdl:part name="parameters"<br />
element="tns:intentToModifyRequest" /><br />
</wsdl:message><br />
<wsdl:message name="IntentToModifyResponse"><br />
<wsdl:part name="parameters"<br />
element="tns:intentToModifyResponse" /><br />
</wsdl:message><br />
<wsdl:message name="UpdateWorkspaceRequest"><br />
<wsdl:part name="parameters"<br />
element="tns:updateWorkspaceRequest" /><br />
</wsdl:message><br />
<wsdl:message name="UpdateWorkspaceResponse"><br />
<wsdl:part name="parameters"<br />
element="tns:updateWorkspaceResponse" /><br />
</wsdl:message><br />
<wsdl:portType name="SCMServer"><br />
<wsdl:operation name="promote"><br />
<wsdl:input message="tns:PromoteRequest" /><br />
<wsdl:output message="tns:PromoteResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="createBaseline"><br />
<wsdl:input message="tns:CreateBaselineRequest" /><br />
<wsdl:output message="tns:CreateBaselineResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="createBranch"><br />
<wsdl:input message="tns:CreateBranchRequest" /><br />
<wsdl:output message="tns:CreateBranchResponse" /><br />
</wsdl:operation><br />
</wsdl:portType><br />
<wsdl:portType name="SCMWorkspace"><br />
<wsdl:operation name="createWorkspace"><br />
<wsdl:input message="tns:createWorkspaceRequest" /><br />
<wsdl:output message="tns:createWorkspaceResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="modifyWorkspace"><br />
<wsdl:input message="tns:modifyWorkspaceRequest" /><br />
<wsdl:output message="tns:modifyWorkspaceResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="removeWorkspace"><br />
<wsdl:input message="tns:removeWorkspaceRequest" /><br />
<wsdl:output message="tns:removeWorkspaceResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="addAssets"><br />
<wsdl:input message="tns:addAssetsRequest" /><br />
<wsdl:output message="tns:addAssetsResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="removeAssets"><br />
<wsdl:input message="tns:RemoveAssetsRequest" /><br />
<wsdl:output message="tns:RemoveAssetsResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="intentToModify"><br />
<wsdl:input message="tns:intentToModifyRequest" /><br />
<wsdl:output message="tns:intentToModifyResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="updateWorkspace"><br />
<wsdl:input message="tns:UpdateWorkspaceRequest" /><br />
<wsdl:output message="tns:UpdateWorkspaceResponse" /><br />
</wsdl:operation><br />
<wsdl:operation name="createNewVersions"><br />
<wsdl:input message="tns:CreateNewVersionsRequest" /><br />
<wsdl:output message="tns:CreateNewVersionsResponse" /><br />
</wsdl:operation><br />
</wsdl:portType><br />
<wsdl:binding name="ALFSCMSOAP" type="tns:ALFSCM"><br />
<soap:binding style="document"<br />
transport="http://schemas.xmlsoap.org/soap/http" /><br />
<wsdl:operation name="promote"><br />
<soap:operation soapAction="" /><br />
<wsdl:input><br />
<soap:body use="literal" /><br />
</wsdl:input><br />
<wsdl:output><br />
<soap:body use="literal" /><br />
</wsdl:output><br />
</wsdl:operation><br />
</wsdl:binding><br />
<wsdl:service name="ALFSCMServer"><br />
<wsdl:port binding="tns:ALFSCMSOAP" name="ALFSCMSOAP"><br />
<soap:address location="http://localhost:8080/ALFSCMServer" /><br />
</wsdl:port><br />
</wsdl:service><br />
<wsdl:service name="ALFSCMWorkspace"><br />
<wsdl:port binding="tns:ALFSCMSOAP" name="ALFSCMSOAP"><br />
<soap:address<br />
location="http://localhost:8080/ALFSCMWorkspace" /><br />
</wsdl:port><br />
</wsdl:service><br />
</wsdl:definitions><br />
</pre></div>Alf tbuss.yahoo.comhttps://wiki.eclipse.org/index.php?title=ALF/Vocabularies/SCM_Vocabulary/Schema&diff=11929ALF/Vocabularies/SCM Vocabulary/Schema2006-09-27T19:47:16Z<p>Alf tbuss.yahoo.com: /* SCM vocabulary Schema */</p>
<hr />
<div>[http://wiki.eclipse.org/index.php/ALF ALF Wiki Home]<br />
== SCM Vocabulary Schema ==<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8" ?><br />
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"<br />
xmlns="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
xmlns:tns="http://www.eclipse.org/alf/schema/alfcommonvocabulary/v0.00"<br />
targetNamespace="http://www.eclipse.org/alf/schema/scmvocabulary/v0.00"<br />
elementFormDefault="qualified" attributeFormDefault="unqualified"><br />
<xsd:annotation><br />
<xsd:documentation><br />
Copyright Notice The material in this document is Copyright<br />
(c) Serena Software, Inc. and others, 2005,2006 Terms and<br />
Conditions: The Eclipse Foundation makes available all<br />
content in this document ("Content"). Unless otherwise<br />
indicated below, the Content is provided to you under the<br />
terms and conditions of the Eclipse Public License Version<br />
1.0 ("EPL"). A copy of the EPL is available at<br />
http://www.eclipse.org/legal/epl-v10.html. For purposes of<br />
the EPL, "Program" will mean the Content. If you did not<br />
receive this Content directly from the Eclipse Foundation,<br />
the Content is being redistributed by another party<br />
("Redistributor") and different terms and conditions may<br />
apply to your use of any object code in the Content. Check<br />
the Redistributor's license that was provided with the<br />
Content. If you did not receive any such license, contact<br />
the Redistributor. Unless otherwise indicated below, the<br />
terms and conditions of the EPL still apply to the Content.<br />
</xsd:documentation><br />
</xsd:annotation><br />
<xsd:simpleType name="UserIDType"><br />
<xsd:restriction base="xsd:string" /><br />
</xsd:simpleType><br />
<xsd:simpleType name="TimestampType"><br />
<xsd:restriction base="xsd:string" /><br />
</xsd:simpleType><br />
<xsd:complexType name="LabelType"><br />
<xsd:sequence><br />
<xsd:element name="LabelID" type="xsd:string" /><br />
<xsd:element name="LabelName" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="LabelCollectionType"><br />
<xsd:sequence><br />
<xsd:element name="Label" type="LabelType" minOccurs="0"<br />
maxOccurs="unbounded" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="LockType"><br />
<xsd:sequence><br />
<xsd:element name="LockID" type="xsd:string" /><br />
<xsd:element name="ElementVersionID" type="xsd:string" /><br />
<xsd:element name="LockTimestamp" type="TimestampType" /><br />
<xsd:element name="LockComment" type="xsd:string" /><br />
<xsd:element name="LockUser" type="UserIDType" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="LockCollectionType"><br />
<xsd:sequence><br />
<xsd:element name="Lock" type="LockType" minOccurs="0"<br />
maxOccurs="unbounded" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="ContentType"><br />
<xsd:sequence><br />
<xsd:element name="Path" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="ElementType"><br />
<xsd:sequence><br />
<xsd:element name="ElementID" type="xsd:string" /><br />
<xsd:element name="ElementName" type="xsd:string" /><br />
<xsd:element name="OwnerUser" type="UserIDType" /><br />
<xsd:element name="ElementDatatype" type="xsd:string" /><br />
<xsd:element name="CreationTimestamp" type="TimestampType" /><br />
<xsd:element name="CreationComment" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="ElementVersionType"><br />
<xsd:sequence><br />
<xsd:element name="ElementVersionID" type="xsd:string" /><br />
<xsd:element name="ElementVersionName" type="xsd:string" /><br />
<xsd:element name="ParentElementID" type="xsd:string" /><br />
<xsd:element name="AuthorUser" type="UserIDType" /><br />
<xsd:element name="Content" type="ContentType" /><br />
<xsd:element name="VersionTimestamp" type="TimestampType" /><br />
<xsd:element name="VersionComment" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="ElementVersionCollectionType"><br />
<xsd:sequence><br />
<xsd:element name="ElementVersion" type="ElementVersionType"<br />
minOccurs="0" maxOccurs="unbounded" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="VersionCollectionType"><br />
<xsd:sequence><br />
<xsd:element name="VersionCollectionID" type="xsd:string" /><br />
<xsd:element name="VersionCollectionName" type="xsd:string" /><br />
<xsd:element name="OwnerUser" type="UserIDType" /><br />
<xsd:element name="CreationTimestamp" type="TimestampType" /><br />
<xsd:element name="CreationComment" type="xsd:string" /><br />
<xsd:element name="Versions"<br />
type="ElementVersionCollectionType" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="ChangeSetType"><br />
<xsd:complexContent><br />
<xsd:extension base="VersionCollectionType" /><br />
</xsd:complexContent><br />
</xsd:complexType><br />
<xsd:complexType name="BaselineType"><br />
<xsd:complexContent><br />
<xsd:extension base="VersionCollectionType" /><br />
</xsd:complexContent><br />
</xsd:complexType><br />
<xsd:complexType name="RevisionIdentifierType"><br />
<xsd:sequence><br />
<xsd:element name="Name" type="xsd:string" /><br />
<xsd:element name="Description" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="BranchType"><br />
<xsd:sequence><br />
<xsd:element name="BranchID" type="xsd:string" /><br />
<xsd:element name="BranchName" type="xsd:string" /><br />
<xsd:element name="CreationTimestamp" type="TimestampType" /><br />
<xsd:element name="CreationComment" type="xsd:string" /><br />
<xsd:element name="StreamParentID" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="BranchCollectionType"><br />
<xsd:sequence><br />
<xsd:element name="Branch" type="BranchType" minOccurs="0"<br />
maxOccurs="unbounded" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="RevisionsType"><br />
<xsd:sequence><br />
<xsd:element name="ElementVersionID" type="xsd:string" /><br />
<xsd:element name="ElementVersionName" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="WorkspaceType"><br />
<xsd:sequence><br />
<xsd:element name="WorkspaceName" type="xsd:string" /><br />
<xsd:element name="WorkspaceID" type="xsd:string" /><br />
<xsd:element name="ConfigurationSpec" type="xsd:string" /><br />
<xsd:element name="OwnerID" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="VersionableObjectType"><br />
<xsd:sequence><br />
<xsd:element name="VersionableObjectName" type="xsd:string" /><br />
<xsd:element name="VersionableObjectID" type="xsd:string" /><br />
<xsd:element name="ConfigurationSpec" type="xsd:string" /><br />
<xsd:element name="ElementID" type="xsd:string" /><br />
<xsd:element name="RevisionIdentifier"<br />
type="RevisionIdentifierType" /><br />
<xsd:element name="CreationTimestamp" type="TimestampType" /><br />
<xsd:element name="LastModifiedTimestamp"<br />
type="TimestampType" /><br />
<xsd:element name="FolderID" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:complexType><br />
<xsd:complexType name="FolderType"><br />
<xsd:complexContent><br />
<xsd:extension base="VersionableObjectType"><br />
<xsd:sequence><br />
<xsd:element name="LocalPath" type="xsd:string" /><br />
</xsd:sequence><br />
</xsd:extension><br />
</xsd:complexContent><br />
</xsd:complexType><br />
<xsd:complexType name="FileType"><br />
<xsd:complexContent><br />
<xsd:extension base="VersionableObjectType"><br />
<xsd:sequence><br />
<xsd:element name="Filename" /><br />
</xsd:sequence><br />
</xsd:extension><br />
</xsd:complexContent><br />
</xsd:complexType><br />
</xsd:schema><br />
</pre></div>Alf tbuss.yahoo.com