Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "ALF/architecture/ALF Schemas 001"
(→Introduction) |
m (ALF/architecture/ALF Schemas moved to ALF/architecture/ALF Schemas 001) |
||
| (23 intermediate revisions by the same user not shown) | |||
| Line 11: | Line 11: | ||
| − | '''1. Eliminate a nesting level between BasicEventType and Event Data.''' | + | === '''1. Eliminate a nesting level between BasicEventType and Event Data.''' === |
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. | 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. | ||
| − | '''2. Eliminate the Object Array in favor of a single ObjectType.''' | + | === '''2. Eliminate the Object Array in favor of a single ObjectType.''' === |
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. | 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. | ||
| − | '''3. Eliminate the Context Array''' | + | === '''3. Eliminate the Context Array''' === |
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. | 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. | ||
| − | '''4.Eliminate "InitiatingFlow" and the "nesting" attribute''' | + | === '''4.Eliminate "InitiatingFlow" and the "nesting" attribute''' === |
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. | 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. | ||
| − | '''5. Add "PrecedingEvent" and "PrecedingServiceFlow" to the Basic Event Type as nillable elements.''' | + | === '''5. Add "PrecedingEvent" and "PrecedingServiceFlow" to the Basic Event Type as nillable elements.''' === |
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. | 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. | ||
| − | '''6. Add a ALFEventNoACK element and associated Type.''' | + | === '''6. Add a ALFEventNoACK element and associated Type.''' === |
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) | 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) | ||
| − | '''7. Eliminate the use of the "mixed" attribute.''' | + | === '''7. Eliminate the use of the "mixed" attribute.''' === |
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. | 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. | ||
| − | '''8. "Clean up" or "Gratuitously change" some names.''' | + | === '''8. "Clean up" or "Gratuitously change" some names.''' === |
The purpose is to make things feel a bit more consistent and this is really our last chance to do so. | The purpose is to make things feel a bit more consistent and this is really our last chance to do so. | ||
| Line 54: | Line 54: | ||
BasicEventType -> EventBaseType | BasicEventType -> EventBaseType | ||
| + | |||
EventDetailsType -> EventDetailType | EventDetailsType -> EventDetailType | ||
| − | ToolExtensionDataType -> EventExtensionType BasicEvent -> Base EventDetails -> Detail ToolExtensionData -> Extension | + | |
| + | ToolExtensionDataType -> EventExtensionType | ||
| + | |||
| + | BasicEvent -> Base | ||
| + | |||
| + | EventDetails -> Detail | ||
| + | |||
| + | ToolExtensionData -> Extension | ||
ALFEventACKType -> ALFEventResponseType | ALFEventACKType -> ALFEventResponseType | ||
| + | |||
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. | 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. | ||
ALFEvent -> EventNotice | ALFEvent -> EventNotice | ||
| + | |||
ALFEventACK -> EventNoticeResponse | ALFEventACK -> EventNoticeResponse | ||
| + | |||
Note: this is to conform with the WSDL "Document Literal Wrapped" convention | Note: this is to conform with the WSDL "Document Literal Wrapped" convention | ||
| Line 70: | Line 81: | ||
The EventNoticeWithReply operations is added to the ALFEventManager service | The EventNoticeWithReply operations is added to the ALFEventManager service | ||
| − | Some new ports and corresponding bindings are added to provide the base template for Service Flow services ALFServiceFlow ALFServiceFlowWithReply | + | Some new ports and corresponding bindings are added to provide the base template for Service Flow services ALFServiceFlow ALFServiceFlowWithReply (see item #11) |
| − | == | + | === '''9. The Credential element should be typed "any".''' === |
| − | + | 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. | |
| − | ''' | + | === '''10. Added New elements to Base".''' === |
| + | ''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 | ||
| − | + | ''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. | |
| − | ''' | + | === '''11. New Ports and corresponding bindings added".''' === |
| + | 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 | ||
| − | + | ALFServiceFlow - the port/binding intended to be used by a normal "asynchronous" or one way service flow | |
| − | + | ALFServiceFlowWithReply - the port/binding intended to be used by a service flow that provides a response to the caller. | |
| − | + | == Additional Changes == | |
| + | Listed below are some other possible simplifications and name changes. These need some some further discussion/definition before we accept them. | ||
| − | + | ==='''1. Combine Detail and Extension to a single xs:any element perhaps called <payload>.'''=== | |
| − | + | 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. | |
| − | + | ==='''2. Eliminate the "required" attributes.'''=== | |
| − | + | ''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. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ''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. | |
| + | ==='''3. Clarify ProductCallbackURI'''.=== | ||
| − | + | 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. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | 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. | |
| − | + | ||
| − | + | ||
| − | < | + | The wsa namespace: |
| − | + | <pre> | |
| − | </ | + | xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing" |
| + | </pre> | ||
| − | + | defines the endpoint reference as: | |
| − | + | <pre> | |
| − | + | <wsa:EndpointReference> | |
| − | + | <wsa:Address>anyURI</wsa:Address> | |
| − | + | <wsa:ServiceName>tns:Service</wsa:ServiceName> | |
| − | + | </wsa:EndpointReference> | |
| − | + | </pre> | |
| − | + | ||
| − | + | ||
| − | </ | + | |
| − | + | 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. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ==='''4. Eliminate the BaseEvent structure in the ALFEventResponse message.'''=== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | 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. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | == Schema 001 == | |
| − | + | [[ALF/architecture/ALF_Schemas/ALFEventBase_001.xsd | ALFEventBase_001.xsd]] | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | == WSDL 001 == | |
| − | + | [[ALF/architecture/ALF_Schemas/ALFEventManager_001.WSDL | ALFEventManager_001.WSDL]] | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Latest revision as of 21:05, 1 November 2006
Contents
- 1 Introduction
- 1.1 1. Eliminate a nesting level between BasicEventType and Event Data.
- 1.2 2. Eliminate the Object Array in favor of a single ObjectType.
- 1.3 3. Eliminate the Context Array
- 1.4 4.Eliminate "InitiatingFlow" and the "nesting" attribute
- 1.5 5. Add "PrecedingEvent" and "PrecedingServiceFlow" to the Basic Event Type as nillable elements.
- 1.6 6. Add a ALFEventNoACK element and associated Type.
- 1.7 7. Eliminate the use of the "mixed" attribute.
- 1.8 8. "Clean up" or "Gratuitously change" some names.
- 1.9 9. The Credential element should be typed "any".
- 1.10 10. Added New elements to Base".
- 1.11 11. New Ports and corresponding bindings added".
- 2 Additional Changes
- 3 Schema 001
- 4 WSDL 001
Introduction
ALF Event Manager Schemas and WSDL version 001
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 be considered final. Please respond with any comments you may have and any other suggestions about way to streamline the ALF event Schema.
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
1. Eliminate a nesting level between BasicEventType and Event Data.
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.
2. Eliminate the Object Array in favor of a single ObjectType.
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.
3. Eliminate the Context Array
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.
4.Eliminate "InitiatingFlow" and the "nesting" attribute
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.
5. Add "PrecedingEvent" and "PrecedingServiceFlow" to the Basic Event Type as nillable elements.
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.
6. Add a ALFEventNoACK element and associated Type.
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)
7. Eliminate the use of the "mixed" attribute.
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.
8. "Clean up" or "Gratuitously change" some names.
The purpose is to make things feel a bit more consistent and this is really our last chance to do so.
The suggested changes are as follows:
The schema file will be called ALFEventBase.xsd
BasicEventType -> EventBaseType
EventDetailsType -> EventDetailType
ToolExtensionDataType -> EventExtensionType
BasicEvent -> Base
EventDetails -> Detail
ToolExtensionData -> Extension
ALFEventACKType -> ALFEventResponseType
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.
ALFEvent -> EventNotice
ALFEventACK -> EventNoticeResponse
Note: this is to conform with the WSDL "Document Literal Wrapped" convention
The following messages are added for "synchronous events" EventNoticeWithReply EventNoticeWithReplyResponse
The EventNoticeWithReply operations is added to the ALFEventManager service
Some new ports and corresponding bindings are added to provide the base template for Service Flow services ALFServiceFlow ALFServiceFlowWithReply (see item #11)
9. The Credential element should be typed "any".
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.
10. Added New elements to Base".
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
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.
11. New Ports and corresponding bindings added".
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
ALFServiceFlow - the port/binding intended to be used by a normal "asynchronous" or one way service flow
ALFServiceFlowWithReply - the port/binding intended to be used by a service flow that provides a response to the caller.
Additional Changes
Listed below are some other possible simplifications and name changes. These need some some further discussion/definition before we accept them.
1. Combine Detail and Extension to a single xs:any element perhaps called <payload>.
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.
2. Eliminate the "required" attributes.
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.
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.
3. Clarify ProductCallbackURI.
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.
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.
The wsa namespace:
xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing"
defines the endpoint reference as:
<wsa:EndpointReference>
<wsa:Address>anyURI</wsa:Address>
<wsa:ServiceName>tns:Service</wsa:ServiceName>
</wsa:EndpointReference>
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.
4. Eliminate the BaseEvent structure in the ALFEventResponse message.
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.