Lets start with #2, but we may have to keep the activity ID in both SOAP + transport header eventually.
--Srinath On Tue, Aug 6, 2013 at 12:10 PM, Balakrishnan Gokulakrishnan <[email protected] > wrote: > 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 > -- ============================ Srinath Perera, Ph.D. Director, Research, WSO2 Inc. Visiting Faculty, University of Moratuwa Member, Apache Software Foundation Research Scientist, Lanka Software Foundation Blog: http://srinathsview.blogspot.com/ Photos: http://www.flickr.com/photos/hemapani/ Phone: 0772360902
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
