Sunday, June 06, 2010
Enterprise Architecture, SOA and ServiceMix
The noted James Governor of RedMonk wanted to know my thoughts regarding ServiceMix and I decided to share my thoughts here...
The notion of an Enterprise Service Bus (ESB) in terms of popularity has grown and shrunk in pendulum-like fashion. In order to properly understand whether an ESB is sound or lacking requires not just comparing it to other products in the marketplace
but in terms of how it is used within an enterprise setting. So, the first complaint about the majority of ESB products in the marketplace at large is not really with any server-oriented component, but the lack of proper design tools that allow enterprises to properly leverage them.
Consider for a moment how easily it is to create WSDL using Eclipse or NetBeans in order to describe a particular web service. Now consider how difficult it is to create consistent WSDL across multiple web services where simple business concepts such as what a purchase order, policy number or even an address looks like such that it is consistently described.
When left to developer interpretation, every developer will reinvent the wheel, with each describing the same notion slightly different. The ability of an ESB to introspect on inconsistent element definitions is the first challenge. Sure, many ESBs support transforming of one format to another, but this almost always results in suboptimal performance where ESBs take the blame for things that should have been considered at design time. The better answer is for the enterprise to have some sort of tool that allows for consistent element definition at the small scale which can ultimately escalate into something that feels like an enterprise messaging model.
Are enterprise architects thinking about enterprise messaging models? Very few enterprises in my travels have one. Many attempt to harvest industry models as the starting point since they take a lot of effort to create and customize from there. This begs another question of how an ESB should think about variants. Many ESBs understand how to handle versions, but few know how to handle variants.
The bigger question may be to ask whether an enterprise messaging model is the starting point for an SOA. At some level, the chicken-egg debate rears its ugly head where some parties will argue that an enterprise messaging model should be derived and semantically consistent with an enterprise data model and the endless loop of conversations begins. Of course, most enterprises also don't have enterprise data models, so the debate in my opinion is fruitless.
For those industries and enterprises that have had mediocrity as success, probably have borrowed from industry-vertical specifications. Should an ESB have an inherent built-in understanding of the more popular vertical standards or should it let each and every enterprise reinvent the same wheel in their own way?
Within my own vertical, our industry standards body is ACORD. If you were to look at the various messaging specifications, you will see a common pattern or should I say anti-pattern when applied to ESB? Every message within ACORD is built on the notion of request-response. If you wanted to do anything other than request-response, you have some heavy lifting to do. Is it the fault of an ESB because it doesn't align with suboptimal XML design as created by standards bodies or is it the fault of standards bodies for letting people who only understand the basics of architecture create standards? Not to sound sarcastic, but the challenge here is really more about having the right people within the enterprise participate and not just constrain it to whomever happens to be assigned.
When it comes to ServiceMix itself, I think it has one advantage over commercial offerings. Have you ever heard of Azul Systems, makers of a Java-based appliance that supports 768 cache-coherent cores? To date, ServiceMix is the first and only ESB certified on this device and therefore enterprises who are worried about scalability don't have to worry about scalability when using ServiceMix.
When you look at an ESB through a security lens, I see four areas of improvement. The first is with support for federated identity. Much of the conversation around identity federation tends to focus more on browser-based interactions. The OASIS SAML specification also defines how SAML should work in the world of web services. I think there are a few opportunities for ServiceMix to go a little deeper in terms of support both SAML and WS-Federation. I equally think there is an opportunity to be first in terms of integrating with Microsoft's Windows Identity Foundation (Code-named Geneva).
When it comes to authorization/entitlements, ServiceMix needs to provide a standards-based way of defining who can access what set of services under what circumstances and deeper support for OASIS XACML is in order.
If someone ever decides to move credit cards through ServiceMix and needs to comply with the Payment Card Industry Data Security Standard (PCI) then an ESB needs to provide the ability to add asymmetric encryption based on entry/egress points to specific elements as a global policy. Otherwise, you would either have to encrypt entire messages breaking the ability to easily introspect without incurring performance penalties or you would require applications to redefine all of their messages which would be painful.
The final consideration for ServiceMix would be to add a layer to prevent against insufficient anti-automation. ServiceMix will attempt to scale requests by leveraging staged event-driven architecture (SEDA) principles. At some level, the need to detect bad automation needs to be baked into more products. ServiceMix should consider leveraging the OWASP ESAPI and others to prevent against this scenario.
Consider the business scenario of a large Pizza chain such as Domino's wanting to get commercial auto insurance where they may have several hundred locations and own several hundred vehicles with several hundred people who may drive those vehicles in different locations. It would be reasonable to validate that the quote message not only conforms to schema put may contain other validation rules such as validating each vehicle and/or driver is not duplicated, they have valid drivers licenses and vehicle identification numbers (VIN) and so on. The only way to guarantee a good overall response time in this scenario may be to externalize the many transforms that could occur to XML hardware such as IBM DataPower, Tarari, etc. ServiceMix doesn't quite provide the right level of integration under this scenario. Part of the challenge I believe is that their is a lack of standards which could be solved by the Java community. The other half of the challenge is related to having enough worker threads to distribute the workload to externalized devices.
Anyway, there are probably lots of other considerations that haven't yet came to mind. I suspect a conversation with Anne Thomas Manes, Brenda Michelson, Michael Cote, JP Morgenthal or other brilliant industry analysts will help to job my memory.
In the meantime, I hope this helps point people in a better direction...
| | View blog reactionsThe notion of an Enterprise Service Bus (ESB) in terms of popularity has grown and shrunk in pendulum-like fashion. In order to properly understand whether an ESB is sound or lacking requires not just comparing it to other products in the marketplace
but in terms of how it is used within an enterprise setting. So, the first complaint about the majority of ESB products in the marketplace at large is not really with any server-oriented component, but the lack of proper design tools that allow enterprises to properly leverage them.
Consider for a moment how easily it is to create WSDL using Eclipse or NetBeans in order to describe a particular web service. Now consider how difficult it is to create consistent WSDL across multiple web services where simple business concepts such as what a purchase order, policy number or even an address looks like such that it is consistently described.
When left to developer interpretation, every developer will reinvent the wheel, with each describing the same notion slightly different. The ability of an ESB to introspect on inconsistent element definitions is the first challenge. Sure, many ESBs support transforming of one format to another, but this almost always results in suboptimal performance where ESBs take the blame for things that should have been considered at design time. The better answer is for the enterprise to have some sort of tool that allows for consistent element definition at the small scale which can ultimately escalate into something that feels like an enterprise messaging model.
Are enterprise architects thinking about enterprise messaging models? Very few enterprises in my travels have one. Many attempt to harvest industry models as the starting point since they take a lot of effort to create and customize from there. This begs another question of how an ESB should think about variants. Many ESBs understand how to handle versions, but few know how to handle variants.
The bigger question may be to ask whether an enterprise messaging model is the starting point for an SOA. At some level, the chicken-egg debate rears its ugly head where some parties will argue that an enterprise messaging model should be derived and semantically consistent with an enterprise data model and the endless loop of conversations begins. Of course, most enterprises also don't have enterprise data models, so the debate in my opinion is fruitless.
For those industries and enterprises that have had mediocrity as success, probably have borrowed from industry-vertical specifications. Should an ESB have an inherent built-in understanding of the more popular vertical standards or should it let each and every enterprise reinvent the same wheel in their own way?
Within my own vertical, our industry standards body is ACORD. If you were to look at the various messaging specifications, you will see a common pattern or should I say anti-pattern when applied to ESB? Every message within ACORD is built on the notion of request-response. If you wanted to do anything other than request-response, you have some heavy lifting to do. Is it the fault of an ESB because it doesn't align with suboptimal XML design as created by standards bodies or is it the fault of standards bodies for letting people who only understand the basics of architecture create standards? Not to sound sarcastic, but the challenge here is really more about having the right people within the enterprise participate and not just constrain it to whomever happens to be assigned.
When it comes to ServiceMix itself, I think it has one advantage over commercial offerings. Have you ever heard of Azul Systems, makers of a Java-based appliance that supports 768 cache-coherent cores? To date, ServiceMix is the first and only ESB certified on this device and therefore enterprises who are worried about scalability don't have to worry about scalability when using ServiceMix.
When you look at an ESB through a security lens, I see four areas of improvement. The first is with support for federated identity. Much of the conversation around identity federation tends to focus more on browser-based interactions. The OASIS SAML specification also defines how SAML should work in the world of web services. I think there are a few opportunities for ServiceMix to go a little deeper in terms of support both SAML and WS-Federation. I equally think there is an opportunity to be first in terms of integrating with Microsoft's Windows Identity Foundation (Code-named Geneva).
When it comes to authorization/entitlements, ServiceMix needs to provide a standards-based way of defining who can access what set of services under what circumstances and deeper support for OASIS XACML is in order.
If someone ever decides to move credit cards through ServiceMix and needs to comply with the Payment Card Industry Data Security Standard (PCI) then an ESB needs to provide the ability to add asymmetric encryption based on entry/egress points to specific elements as a global policy. Otherwise, you would either have to encrypt entire messages breaking the ability to easily introspect without incurring performance penalties or you would require applications to redefine all of their messages which would be painful.
The final consideration for ServiceMix would be to add a layer to prevent against insufficient anti-automation. ServiceMix will attempt to scale requests by leveraging staged event-driven architecture (SEDA) principles. At some level, the need to detect bad automation needs to be baked into more products. ServiceMix should consider leveraging the OWASP ESAPI and others to prevent against this scenario.
Consider the business scenario of a large Pizza chain such as Domino's wanting to get commercial auto insurance where they may have several hundred locations and own several hundred vehicles with several hundred people who may drive those vehicles in different locations. It would be reasonable to validate that the quote message not only conforms to schema put may contain other validation rules such as validating each vehicle and/or driver is not duplicated, they have valid drivers licenses and vehicle identification numbers (VIN) and so on. The only way to guarantee a good overall response time in this scenario may be to externalize the many transforms that could occur to XML hardware such as IBM DataPower, Tarari, etc. ServiceMix doesn't quite provide the right level of integration under this scenario. Part of the challenge I believe is that their is a lack of standards which could be solved by the Java community. The other half of the challenge is related to having enough worker threads to distribute the workload to externalized devices.
Anyway, there are probably lots of other considerations that haven't yet came to mind. I suspect a conversation with Anne Thomas Manes, Brenda Michelson, Michael Cote, JP Morgenthal or other brilliant industry analysts will help to job my memory.
In the meantime, I hope this helps point people in a better direction...
