Comments on: ESBs improve SOA testability http://www.udidahan.com/2006/06/04/esbs-improve-soa-testability/ Enterprise Development Expert & SOA Specialist Sun, 14 Mar 2010 06:27:00 -0500 http://wordpress.org/?v=2.8.4 hourly 1 By: Udi Dahan - The Software Simplist http://www.udidahan.com/2006/06/04/esbs-improve-soa-testability/comment-page-1/#comment-326 Udi Dahan - The Software Simplist Thu, 15 Jun 2006 01:09:51 +0000 http://wp_630.weblogs.us/archives/289#comment-326 The fact that a service, or client for that matter, handles a message does not necessarily make that message type belong to the handling service's schema. Pub/sub is the best example of this. I find this to be quite different than "sharing schema". As for removing all deployment aspects from application code, this makes for a system that is more flexible at deployment time. The specific issue of removing the target end point from the "Send" method signature means you have one less parameter to check for the logic to be correct - though I grant that the testability was never meant to come from there. Rather, the isolation of the Message Handler role is what better enables testability. The fact that a service, or client for that matter, handles a message does not necessarily make that message type belong to the handling service’s schema. Pub/sub is the best example of this. I find this to be quite different than “sharing schema”.

As for removing all deployment aspects from application code, this makes for a system that is more flexible at deployment time. The specific issue of removing the target end point from the “Send” method signature means you have one less parameter to check for the logic to be correct – though I grant that the testability was never meant to come from there. Rather, the isolation of the Message Handler role is what better enables testability.

]]> By: John Wood http://www.udidahan.com/2006/06/04/esbs-improve-soa-testability/comment-page-1/#comment-325 John Wood Fri, 09 Jun 2006 21:41:27 +0000 http://wp_630.weblogs.us/archives/289#comment-325 >> There’s no reason two Autonomous Services should share the same schema. << I’m still not sold on this … another example of where I have services sharing schema: In a task scheduling system I have several services that take a message type called TaskReference, and they do something with the task. One is called CompleteTask, which takes a reference to the task and marks it as complete. Another is called DeleteTask which also takes a reference to a task. Sure in the future the requirements may diverge and I’ll have to assign them different derived schema, but for now all they need is a reference to a task. Why would it make sense for me to create new schema for every service if they can re-use existing schema? It just ends up as more for me to maintain. Your design where you just pass a message (with no specific destination) to a bus and it decides which service it goes to is just one possible architecture, I don’t think I’ve seen in your explanation why exactly this architecture is superior or even why it’s better suited to testing. Could you clarify? >> There’s no reason two Autonomous Services should share the same schema. <<
I’m still not sold on this … another example of where I have services sharing schema: In a task scheduling system I have several services that take a message type called TaskReference, and they do something with the task. One is called CompleteTask, which takes a reference to the task and marks it as complete. Another is called DeleteTask which also takes a reference to a task. Sure in the future the requirements may diverge and I’ll have to assign them different derived schema, but for now all they need is a reference to a task. Why would it make sense for me to create new schema for every service if they can re-use existing schema? It just ends up as more for me to maintain.

Your design where you just pass a message (with no specific destination) to a bus and it decides which service it goes to is just one possible architecture, I don’t think I’ve seen in your explanation why exactly this architecture is superior or even why it’s better suited to testing. Could you clarify?

]]>