Todd Biske: Outside the Box

While I won’t be there for this, I think Jon Udell has got some very interesting topics for the discussion, outlined in his blog here and here. For day one, a topic listed is “migration to policy-driven intermediation.” He mentions security and compliance policies, but I’d also add in operational (i.e. routing rules, caching, monitoring) and what I term integration (transformation, especially in support of versioning) policies. While externalizing these policies is problem one, what will quickly follow is a big management problem. Right now, policy management is typically provided as part of an enforcement solution. When those policies start to branch out beyond security, can the management solution still be sold as part of the enforcement solution? Is that what we want? Ultimately, we’d want the policy owners to be the ones setting these policies which could mean at least four departments: Information Security, Compliance, Operations, and the development team. How many tools currently support this scenario well?

He also suggests some topics around the “evolving role of the repository” including the human factors. I think this will be an interesting discussion as we’re starting to see some convergence between the human-oriented tools from vendors like Flashline and LogicLibrary and the system-facing UDDI registries from vendors like Systinet and Infravio.

One topic that I’ve been interested to hear about (I keep meaning to call David Linthicum’s voicemail line for his <a href=”http://www.soaexpertpodcast.com/”>podcast</a> on this one) is how to make Web Services with a “pull” invocation model a first class citizen. A service is a function that is performed on behalf of some external party. There are really two styles for this: a push model, where the consumer “pushes” the request to the service provider directly (easily implemented as SOAP/HTTP(S) and may or may not involve a response message) and a pull model, where the service provider “pulls” the request from some form of queueing system, i.e. JMS, MQ Series, or MSMQ. Think of this as the difference between a session bean and a message-driven bean in the J2EE world. The problem with the “pull” model is that it’s not a first class citizen in the Web Services world. This isn’t a notification scenario, so WS-Notification isn’t appropriate. Notifications tells you something happened, but the source of the notification has no expectation that some action will be formed.

The current state-of-the-art for handling this would be to use some form of intermediary (ESB, WSM broker, etc.) to perform HTTP-JMS bridging. Until we have an open wire protocol like HTTP for talking to queueing systems, that’s about all we can hope for. The problem with that is we now move out of the Web Services and into the MOM world. Depending on the implementation platform (especially if it’s not from the same vendor as your messaging backbone), the fact that the payload is a SOAP envelope may be completely invisible to the platform framework, resulting in a lot more work for the service developer. This topic doesn’t really fit with John’s other topics, but it’s of particular interest to me, so if you’ve got thoughts on this, blog away.

Overall, I think this forum should be very interesting. I look forward to following the blogs from it.