Skip to main content

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

Jump to: navigation, search

Talk:ALF/architecture/ALF Schemas 001

Please comment on this document here

on Additional Changes 1. Combine Detail and Extension to a single xs:any element perhaps called <payload>.

- posted for Brian Carroll The intent of separating the two parts of the payload into the standard part defined by an ALF Vocabulary and tool-specific extension data was to allow for tool substitutability. Any arbitrary tool that understood the ALF Vocabulary-defined portions but not the tool-specific data could still process the standard portion of the payload. Separating the standard ALF Vocabulary-defined portions from the tool extension data make the event more generically process able by tools that simply understand the ALF Vocabulary portion. We need to keep that separation.

- reply from Tim Buss Yes it does force the division. My concern is that it creates an artificial division from a data usage perspective and perhaps the need that it tries to address could be addressed differently. An alternative might be to say that vocabulary structures must be extensible eg:

Defining ALFEventType as

	<xs:complexType name="ALFEventType">
		<xs:sequence>
			<xs:element name="Base" type="EventBaseType"/>
			<xs:any minOccurs=0>
		</xs:sequence>
		<xs:attribute name="version" type="xs:string" use="required"/>
	</xs:complexType>

Allows the omission of the two extra elements that we currently require but may often be empty.

Vocabulary details can be declared as follows. Note that xs:any allows them to be extended to include additional elements. This allows for compatible type extensions and xs:any can be added at all structure levels allowing a tool to declare its extra data with close proximity to the vocabulary elements to which it is probably related.

For example:

	<xs:complexType name="VocabStructure1Type">
		<xs:sequence>
			<xs:element name="VocabElement1" type="xs:string"/>
			<xs:element name="VocabElement2" type="xs:string"/>
			<xs:element name="VocabStructure2" type="vocabStructure2Type>
			<xs:any minOccurs=0>
		</xs:sequence>
	</xs:complexType>

	<xs:complexType name="VocabStructure2Type">
		<xs:sequence>
			<xs:element name="VocabElement3" type="xs:string"/>
			<xs:element name="VocabElement4" type="xs:string"/>
			<xs:any minOccurs=0>
		</xs:sequence>
	</xs:complexType>

Giving the vocab event definition.

	<xs:complexType name="MyVocabEvent1Type">
		<xs:complexContent>
			<xs:restriction base="ALFEventType">
				<xs:sequence>
					<xs:element name="Base" type="MyEventBase3Type"/>
					<xs:element name="Detail" type="VocabStructure1Type"/>
					<xs:any minOccurs=0>
				</xs:sequence>
				<xs:attribute name="version" type="xs:string" use="required"/>
			</xs:restriction>
		</xs:complexContent>
	</xs:complexType>

Given this vocab definition, a tool is free to added elements either inside VocabStructure1Type or to ALFEventType but the event can still be handled using just the generic vocabulary if so desired.

Another possible advantage of this method is that we can control what is a vocabulary schema and define that it be extensible in this way. This may be easier enforce than whether a particular tool declares its detail/extension elements within one arbitrary element or another.

Another possible advantage of this method is the these extensible vocabulary structures can also be applied to service defintions. The brute force division by element we have so far proposed is not very convenient for that or likely to be observed. To be sure that this alternative method would work for services we would need to try it with the various service proxy generators to reasure ourselves that <xs:any minOccurs=0> is currently handled appropriately and is practical to use. It will work fine for the eventManager and BPEL.

Probably need to play with this idea a bit more to be sure but I think it may be a compelling alternative.

Tim

on Additional Changes - 2. Eliminate the "required" attributes - "schemaLocation" .

The purpose is to allow dynamic discovery of the concrete schema when you receive an event as a Base event. My thought is that this use is unlikely and if it was to be used it may be better defined at a higher level. The tool event declaration schema (see elsewhere on declaring events) can define the entire event structure for the tool's events and would be interesting at the Event level. Thus instead of two attributes for Detail and Extension we might have just one at the ALFEvent level thus

	<xs:complexType name="ALFEventType">
		<xs:sequence>
			<xs:element name="Base" type="EventBaseType"/>
			<xs:element name="Detail" type="EventDetailType"/>
			<xs:element name="Extension" type="EventExtensionType"/>
		</xs:sequence>
		<xs:attribute name="schemaLocation" type="xs:string" use="required"/>
	</xs:complexType>

I'm a little bothered by this being "required". I suppose the default could be the ALFEventSchema location for those tools that do not extend the event in any way. Even those should declare their events so maybe there is always a possible specific schema.

Tim

on Additional Changes - 2. Eliminate the "required" attributes. - "alfEventVersion"

on EventBaseType (nee BasicEventType)

posted for Brian Carroll

We need to keep the alfEventVersion or find an alternative mechanism to allow applications to process events as the definition of the event evolves over time. Since we cannot mandate that all tools switch over from one version to another on a specified date, we need a mechanism to allow not only the EventManager, but also tools to accept and process different versions of the event message even as its format evolves. Having an event carry explicit indication of what format was used allows ALF to evolve without trauma to the EventManager or applications.

posted by Tim Buss

Dynamic version switching is the point of the attribute and I'm not 100% clear why it bothers me so here's some pondering.

First, if we do have it then it should be defined as always having the value "1.0" or the current version of the schema in which it is defined since by design it would need to be fixed to the version of the schema. Tools must not set it arbitrarily

Looking at how we might consider creating a new version of the EventStructure, one technique would be to just make it extensible now by adding xs:any as follows.

	<xs:complexType name="EventBaseType">
		<xs:sequence>
			<xs:element name="EventID" type="EventIDType"/>
			<xs:element name="Timestamp" type="TimestampType"/>
			<xs:element name="EventType" type="EventTypeType"/>
			<xs:element name="Object" type="ObjectDataType"/>
			<xs:element name="Source" type="SourceType"/>
			<xs:element name="PredecedingEvent" type="EventIDType" nillable="true"/>
			<xs:element name="ApplicationName" type="ApplicationNameType" nillable="true"/>
			<xs:element name="Environment" type="EnvironmentType" nillable="true"/>
			<xs:element name="User" type="UserType"/>
			<xs:any minOccurs=0>
		</xs:sequence>
	</xs:complexType>

The implication of this is that in the future there might be more elements that the Event manager can look at but they will be optional and the event manager will use them if they are there. At that point we would publish a derived type

	<xs:complexType name="EventBaseType2">
		<xs:complexContent>
			<xs:restriction base="EventBaseType">
			<xs:sequence>
				<xs:element name="EventID" type="EventIDType"/>
				<xs:element name="Timestamp" type="TimestampType"/>
				<xs:element name="EventType" type="EventTypeType"/>
				<xs:element name="Object" type="ObjectDataType"/>
				<xs:element name="Source" type="SourceType"/>
				<xs:element name="PredecedingEvent" type="EventIDType" nillable="true"/>
				<xs:element name="ApplicationName" type="ApplicationNameType" nillable="true"/>
				<xs:element name="Environment" type="EnvironmentType" nillable="true"/>
				<xs:element name="User" type="UserType"/>
				<xs:element name="NewElementForVersion2" type="xs:string" />
				<xs:any minOccurs=0>
			</xs:sequence>
			</xs:restriction>
		</xs:complexContent>
	</xs:complexType>

So now the eventManager (or whatever) would have to look for <NewElementForVersion2> and process it if present.

The version attribute might help if we wanted to create a fundamentally different structure (eg eliminating one of the mandatory elements or changing its type in way that’s not declared to be extensible) but this seem rather unlikely and if required, might be better handled by defining a new type and a new operation on the EventManager. Since tools would need to change in any case its just as easy for them to invoke a different operation with the new type.

Another point here is that if the event type has changed fundamentally then none of the existing Service Flows will work with it and the attribute won't be useful in allowing them to adapt. The only way they could would be to treat the input message as <xs:any> and dynamically discover the content - a very complex undertaking however you implement the service flow. Again this argues for creating a new type with a new EventManger operation and a new class of ServiceFlow that is defined to handle these new events.

Bottom line I don't see the version attribute ever being used as intended. The cost of me being wrong would be that we would need to add the "version" attribute in at some point in the future and tools would need to start setting it if they are changing to use the new version. This is fine and could be anticipated with anyAttribute if we are seriously bothered by that.

	<xs:complexType name="EventBaseType">
		<xs:sequence>
			<xs:element name="EventID" type="EventIDType"/>
			<xs:element name="Timestamp" type="TimestampType"/>
			<xs:element name="EventType" type="EventTypeType"/>
			<xs:element name="Object" type="ObjectDataType"/>
			<xs:element name="Source" type="SourceType"/>
			<xs:element name="PredecedingEvent" type="EventIDType" nillable="true"/>
			<xs:element name="ApplicationName" type="ApplicationNameType" nillable="true"/>
			<xs:element name="Environment" type="EnvironmentType" nillable="true"/>
			<xs:element name="User" type="UserType"/>
			<xs:any minOccurs=0>
		</xs:sequence>
		<xsd:anyAttribute/>
	</xs:complexType>

So I favor eliminating it. I am less sure about the inclusion <xs:any minOccurs=0> and <xsd:anyAttribute/> since there may be other side effects and the EventDetail structure allows extension one way or another.

Tim

on Additional Changes - 4. Eliminate the BaseEvent structure in the ALFEventResponse message.

One necessary thing to return is the EventId allocated by the event manager. The calling tool may wish to correllate that to its own notion of event ID. This may indicate the need for two event IDs, a tool allocated ID and an Event Manager allocated ID. If so then it may be useful although, not necessary, to return both.

On returning the Service Flow matches it would seem useful to return either the number of matches or a list of "Names" of the matches. A full name for a match would include ApplicationName:EventName:ServiceFlowName.

"ApplicationName" has already been described elsewhere (see Admin Service). It is an identifier that uniquely names a set of service flow declarations and the event declarations that cause them to run. It is useful for identifing a particular set of events and service flow that together implement a particular function.

EventName would be a named identifier that is unique within the "Application" identified by "ApplicationName". It identifies the name of the event logically rather that by the specific physical values it may take a runtime.

ServiceFlowName is a named identifier that is unique within the "Application" identified by "ApplicationName". It identifies the name of the ServiceFlow logically rather tben by the specific physical ServiceFlow definition.

The purpose of returning these names is that it could provide a logical value by which the event raiser could take further action. We might consider the possibility of using the name to lookup physical entities such as service flow addresses at runtime. That requires furhter consideration.

Tim

Back to the top