Hi Isabelle, The plan is to implement this to HTTP and JMS at first, since these are the most often transports. The point with this approach is, depending on SOAP header maybe much worse, compared to depending on a specific set of transports, since non-SOAP messages we can't support. And also, even some SOAP message scenarios where, we don't want to build the message, such as a pure pass-through scenario in ESB, we only have access to the HTTP headers, if we want to do the routing efficiently, and still publish to BAM on the activities.
Cheers, Anjana. On Tue, Aug 6, 2013 at 2:22 PM, Isabelle Mauny <[email protected]> wrote: > Whatever you choose, please make sure it works across the WSO2 platform > and eventually, in 3rd party products . We need to be able to track a > transaction as it flows through the enterprise... > Also, does the approach we are taking now restricts us to HTTP ? what > about JMS or other transports ? > Isabelle. > __________________________________________________ > > *Isabelle Mauny > *Director, Product Management; WSO2, Inc.; http://wso2.com/ > email: [email protected] - mobile (Spain) : +34 616050684 - mobile (Sri > Lanka) +94 (0)774777663 > > * > * > > On Aug 6, 2013, at 9:52 AM, Sanjeewa Malalgoda <[email protected]> wrote: > > > > 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 > > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Anjana Fernando* Technical Lead WSO2 Inc. | http://wso2.com lean . enterprise . middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
