On Tue, Aug 6, 2013 at 1:04 PM, Srinath Perera <[email protected]> wrote:
> Lets start with #2, but we may have to keep the activity ID in both SOAP + > transport header eventually. > +1. Once we had similar requirement and decide to add transport header named "X-massage-id" (non standard header). Hope we can do something similar here as well. Thanks, Sanjeewa. > > --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 > > -- * * *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.blogspot.com/<http://sanjeewamalalgoda.blogspot.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
