Hi y'all! Back to blogging for now, it seems. :)
A brief Glen-update before we proceed to the subject of this post - I've been having a pretty good year so far, and have been doing a lot of thinking about social technologies and how to make them work better together. I've been doing a fair bit of tweeting, and enjoying the progress on foaf+ssl. I'm consulting right now, helping out a university with an ESB RFP, which is fun in that I'm enjoying being on the client side of one of these things for once. :) I've got my eyes open looking for the Next Step, which might be continued consulting or might involve taking a Real Job. Will keep you posted.
OK. So I've been thinking about debugging complex SOA interactions which might involve multiple layers of intermediaries - proxies on the client side, ESBs, etc. What I want is either the ability to collect log information in a message as it flows through nodes along a message path, or the ability to have each node log some information to a remote logging service, correlated in some way so it's clear all the logs relating to a given message flow (process/composition) are together. There are certainly some SOA Management products out there on the market (AmberPoint, Actional, etc) which can handle this kind of thing, but I'd like a simple, ideally Open Source solution.
Along these lines, are there any common SOAP extensions that function similarly to either traceroute or syslog? What I want is something like either this:
<soap:header>
<dbg:tracepad role="next" relay="true">
<step nodeid="identifier of this node">
Each node along the way has the opportunity/responsibility to
add a "step" containing whatever information it feels like injecting.
It then ensures that this header is inserted into the outgoing
message(s) heading further down the message path.
</step>
</dbg:tracepad>
</soap:header>
...where debugging info can collect in the message, or like this:
<soap:header>
<dbg:log role="next" relay="true">
<id>correlator-for-this-process</id>
<logger>http://example.com/logService</logger>
</dbg:log>
</soap:header>
Of course both of these ideas require plugins (Axis2 Modules, JAX-WS Handlers, etc) that support the desired functionality for all the platforms you want it to work with.
Is this a niche waiting to be filled, or does this exist already in some non-proprietary form?UPDATE : look at that, Mark Little was clearly thinking along the same lines recently - check out his InfoQ article asking about SOA testing tools...
3 comments:
Very interesting idea. Do you think you would need all the nodes in a path to understand and process either dbg:tracepad or dbg:log for this to be useful or just, say, 80% (to pick a random percentage)? Is there a way one, "debug aware" node could tell if the message had just traversed one or more nodes that weren't debug aware?
Also, wouldn't it be simpler to just make dbg:log an EPR considering that it is a URI and an accompanying cookie?
Nope, doesn't currently exist. Limiting it to SOAP messages seems a little superficial, don't you think? In real-life complex systems (those that would benefit from this tracking), what percentage of invocations are represented by SOAP message exchanges versus all the other forms of invocation (adapters, message queues, batch jobs, SQL, file drops...)? Things can break and/or slow down just the same with any of these mechanisms. Plus, if you really have a complex, composite, multi-party SOA application, don't you often have an orchestrator (e.g. BPEL or ESB) that sees most of the in/out SOAP messages? You may be better off trying to derive the correlation from this than trying to instrument all the endpoints. But I am really just guessing at your use case.
Gil: you wouldn't necessarily need all of them to process it, but you would need them to respect the relay attribute and forward it on. The problem there is that sometimes a given node isn't exactly forwarding the same message, but sending some other related message - without understanding the extension they wouldn't know to put the header in for that case. As for the EPR thing, sure, that would work too - although as you may recall I have an aversion to ReferenceParameters as they stand. :)
William: The reason I wanted to make sure this gets to all nodes, rather than just logging at the coordinating node, is that there may be stuff that happens inside a given node (not just the wire messages) that should be entered into the log for that interaction. You're quite right that there are certainly non-SOAP interactions that might want to be included as well - but I'm primarily interested in the SOAP interface for this. Perhaps we just point to syslog for the log protocol, which a lot of different systems already use...?
Thanks for the comments, guys. I may try to build something like this into Axis2 at some point - let me know if you might be interested in collaborating on the spec.
Post a Comment