Complexity of conversation aware notation

[objectiser]

The "conversation aware" mechanism currently is aimed at delivering two capabilities:

(a) a design time capability to be able to ensure that the behaviour specified in the implementation of a service (as defined in a jboss-esb.xml configuration) matches the expected behaviour in a choreography description

(b) a runtime capability to enforce the behaviour, so that messages sent or received out of order will be blocked

The complexity of the "conversation aware" notation is to support both of these capabilities - we need the ability to infer the complete process flow from the description in order to achieve (a), and without an understanding of where a particular service instance is within the choreography, it is not possible to determine whether a message of a particular type can be sent or received (i.e. to support (b)).

However, due to this complexity, we are exploring other ways to achieve both of these capabilities, but with a simpler notation. This new approach does not attempt to represent the complete stateful behaviour of a service, but instead describe the service in a more stateless manner, but still enable these 'stateless fragments' of behaviour to be compared against the choreography - so this would help to still achieve (a).

The other benefit of this 'stateless' approach is that it does not require so much runtime support - i.e. no state information will need to be managed, other than would be normally required by the internal service implementation. Because of this, (b) would not be possible - however the other aspect of Overlord CDL is a monitoring capability that does provide this functionality. So rather than duplicate this behavioural monitoring capability in the "conversation aware" mechanism, this 'stateless' approach would leverage the monitoring capability.

In terms of the notation, we believe the main changes are:

1) The stateful approach uses a MessageRouterAction to route the inbound messages to the service descriptor that can process them. The stateless approach reuses the 'SwitchAction', which can be used in other service descriptors to route based on message type.

2) No longer necessary to define identity information, which in the stateful approach was required to link the message to a particular session being managed by the runtime.

3) Many of the actions are no longer required.

The list of actions for stateful approach are: CreateSessionAction, IfAction, MessageRouterAction, ParallelAction, PerformAction, ReceiveMessageAction, RetrieveSessionAction, ScheduleStateAction, SendMessageAction, SetStateAction, SwitchAction, WhenAction and WhileAction

Current list of actons for stateless approach are: IfAction, ReceiveMessageAction, SendMessageAction and SwitchAction.

Other possible actions that may still be required for stateless approach are: ParallelAction and WhileAction.

[objectiser]

Some issues that need to be considered, related to the 'stateless' conversational actions:

1) Sending a Message

The current action notation is:

 <action class="org.jboss.soa.overlord.jbossesb.actions.stateless.SendMessageAction">
 <property name="operation" value="getQuote"/>
 <property name="messageType" value="requestForQuote"/>
 <property name="serviceCategory" value=""/>
 <property name="serviceName" value=""/>
 </action>

The 'serviceCategory' and 'serviceName' properties can be used to explicitly identify the target service descriptor.

What other approaches should be supported? i.e. in what other ways should a user be able to identify the target service descriptor.

a) class implementing a particular interface that can be invoked at runtime to provide the information?

b) property (or properties) to define the required information that can be used to query a service registry - but what properties?


The other aspect is how do we derive the message contents to be sent?

One approach is to just send the message on the current action pipeline - possibly the default approach. This is the approach used in the stateful mechanism, relying on the actions preceding the SendMessageAction to construct the relevant message and place it on the pipeline.

Another approach would be to have a property defining a class (again implementing a defined interface) that can be supplied the current message on the pipeline, and return the message to be sent by this action.


2) Making a decision between multiple paths

 <action class="org.jboss.soa.overlord.jbossesb.actions.stateless.IfAction">
 <property name="paths">
 <if service-category="org.pi4soa.esbbroker.esbbroker" service-name="ESBBrokerProcess_Broker__2"/>
 <else service-category="org.pi4soa.esbbroker.esbbroker" service-name="ESBBrokerProcess_Broker__3"/>
 </property>
 </action>

In this snippet, the paths are identified in terms of the target service descriptors, but the conditions that need to be evaluated to select the paths are not currently defined.

In the stateful approach this was based on invoking a method on the class that represented the stateful session - however this is not available in the stateless approach.

One approach could be to define a 'class' that implements a decision interface, which can be invoked (supplying the current message being processed by the action pipeline), and returns the boolean decision.

Any other idea?



Will discussion other issues later - but these are two of the main points to resolve initially.

[jeff.yuchang]

"objectiser" wrote:


1) Sending a Message

The 'serviceCategory' and 'serviceName' properties can be used to explicitly identify the target service descriptor.

What other approaches should be supported? i.e. in what other ways should a user be able to identify the target service descriptor.

a) class implementing a particular interface that can be invoked at runtime to provide the information?

b) property (or properties) to define the required information that can be used to query a service registry - but what properties?

IMO, the 'serviceCategory' and the 'serviceName' combination is enough. Other ways such as specify EPR etc will be too low-level.

"objectiser" wrote:


The other aspect is how do we derive the message contents to be sent?

One approach is to just send the message on the current action pipeline - possibly the default approach. This is the approach used in the stateful mechanism, relying on the actions preceding the SendMessageAction to construct the relevant message and place it on the pipeline.

Another approach would be to have a property defining a class (again implementing a defined interface) that can be supplied the current message on the pipeline, and return the message to be sent by this action.

I'd vote for the 1st approach, send the message on the current action pipeline. As this is what ESB did.

"objectiser" wrote:


2) Making a decision between multiple paths

One approach could be to define a 'class' that implements a decision interface, which can be invoked (supplying the current message being processed by the action pipeline), and returns the boolean decision.

+1 to this approach.


Thanks
Jeff

[marklittle]

How do we deal with the fact that there may be multiple services with the same name/category?

[objectiser]

How does JBossESB handle this?

Should it not complain if two .esb files are deployed with the same service name/category? Otherwise this could lead to ambiguity in the implementation of a distributed application.

[marklittle]

No, UDDI lets you have multiple services registered with the same name/category. The ESB allows this too for load balancing and fail over purposes.

[objectiser]

In that case, from a consumer perspective it should not matter. It will just use whatever service is returned.

From a service behaviour perspective, ideally each implementation of the same service (name/category) should support the same behaviour.

In terms of conformance checking, each service implementation will be validated in isolated - so if there are multiple implementations, this would not impact the conformance checking.

From a runtime perspective, if a consumer was having a stateful session with the particular service implementation, then I think the consumer would need to cache the EPR to ensure that subsequent interactions went to the same service implementation? But this could be handled as part of the internal state information the consumer would be responsible for managing.

Although this would depend how different the service implementations were - ideally each implementation should be able to handle individual requests within the stateful conversation.

What are the guidelines on this, when deploying two services with the same category/name? Should the consumer continue to use the same EPR until completion, or should each separate request from the consumer be permitted to different service implementations?

[marklittle]

Actually I just realised that there's an issue with this: the esb allows you to define a load balancer at runtime and that could mean that different services get different requests in a conversation. The current esb architecture assumes that any time there are multiple services with the same name/category then they are stateless, so this kind of striping of requests is ok. I don't think that is valid for us, correct?

[objectiser]

It would probably be a problem for the stateful approach - unless each of the service implementations were sharing the same db for storing the session information.

However the new 'stateless' approach we are investigating should be fine - as it does not make any assumptions about the event being processed, in the context of the overall business transaction - it would rely on the service validatation functionality for that, which is external to the service implementation and therefore should not care how the service is implemented, just that its external behaviour is correct.

[marklittle]

OK, so we need to make sure that we restrict that in the documentation. We could provide our own load balancer that throws an exception if it finds more than one Epr in the service name/category list. That would prevent the user getting into trouble if they don't read the docs.

[objectiser]

I have created a 'design discussion' page on the wiki related to Process Governance, where I am hoping that we can outline issues with the design of the 'stateless' conversation aware notation:

https://www.jboss.org/community/docs/DOC-13313

This page will include examples of the proposed 'stateless' conversation aware ESB notation.


It would be beneficial if users could take the skeleton example(s) on the wiki page, and add implementation details.

This may include adding custom actions, or in the case of some of the decision actions (IfAction), adding a way to evaluate the condition that will determine which path to take.

Other things to consider (related to the current example on the wiki page) would be how the internal service implementation handles the accumulation of quote responses from the multiple suppliers that have been dealt with concurrently. This means that the service implementation must maintain some internal state, and understand when all responses have been received, to cause the 'quoteList' to be sent back to the buyer.

Hopefully taking this approach, and experimenting with how to implement a service based on the provided template description, then we can work out what standard actions should be provided, and what functionality should be left for custom actions implemented by the developer.

At this stage we don't need to have full blown executable implementations, with associated Java classes, but it would be good to have some example jboss-esb.xml files with the implementation details (i.e. "filling in the gaps").

[objectiser]

Have added a version 5 of the worked example, on the wiki (Process Governance Design Discussions http://www.jboss.org/community/docs/DOC-13313) page.

This version now routes all service requests and non-message based events through the main service descriptor (with a SwitchAction). All response messages are directed to specific service descriptors to handle those responses - and if multiple response message types may be expected from a request, then a new service descriptor is inserted with a SwitchAction to route based on the response message type.

I think this structure now represents the closest to how a developer would tackle the problem - but would be interested in what others think?

At present the 'stateless' approach won't deal with parallel and async perform constructs from a choreography. The only other main aspect to do is define the conditions for conditional activities - but this is mainly related to the runtime implementation of the actions, although some additional validation could be performed here.

[marklittle]

Hi Gary. I took a look and I like it. It's certainly easier to understand the structure. What's next?

[objectiser]

I think the next steps will be for Jeff to implement the runtime actions in support of the 'stateless' approach, and then also implement the internal (non-observable) aspects of the example to get it running in an ESB.

This should flush out any other issues.

May require some additional validation rules, to ensure conditions are correctly specified - but we can tighten this up once we have a working example.

[marklittle]

What about a worked example based on the new approach?