Hi all,

Currently in the activity data agent used to publish activity data to BAM,
the ID associated with an activity is propagated through the SOAP header.
An Axis2 handler is responsible to check if the incoming message already
has a header property set, and if not it will add a new ID. The message
context is used to track responses to requests and an out handler checks if
the activity ID set in the request is present or not.

While we were testing the activity data publisher in the ESB we noticed
that in situations where multiple ESB instances are used in sequence, the
activity ID is not being maintained per single activity. The reason for
this is that the PTT used in the ESB by default only builds the message for
predefined handlers, an thus the activity ID set by a previous node is not
being seen. This results in more than one activity ID being used per
activity in multiple nodes. For KPI monitoring, it will be necessary to
uniquely identify an activity through its ID and will need to use others
IDs such as parentID etc. as well in the future.

We discussed the following options to go ahead with improving this
behaviour:

1. Keep the activity ID in the SOAP header - This will require having the
messages to be built. We could add properties to the handler to achieve
this.

Pros - Easier to implement, maintains transport independence
Cons - Will need to mandate message building. Will need to look for other
options in situations such as servicing REST calls etc.


2. Use the transport-level (HTTP) header - the activity ID is moved from
the SOAP header to the HTTP header.

Pros - No need to build the message (i.e. can cater to ESB passthru
scenarios). More extensible in terms of supporting different message types
Cons - Transport-dependent (e.g. when JMS etc. are used will need to
manually copy over the ID as a JMS property or similar)


3. Keep the activity ID in both - HTTP header as well as SOAP header

Pros - can address transport switches without user intervention
Cons - Unwieldy to work with. May be edge cases which will restrict use


We are aiming to proceed with option 2 (moving it to the HTTP header).
Please add your comments/suggestions.

Thanks,
Gokul.

-- 
*Balakrishnan Gokulakrishnan*
Software Engineer,
WSO2, Inc.; http://wso2.com

Twitter:  http://twitter.com/gokulbs
Mobile: +94775935789
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to