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...

Book Review: Charlene Li - Open Leadership

A book review is sometimes either over-amplified or tainted by the life experiences of the reviewer, so I figured I write this review and acknowledge my own biases along the way...



I am an Enterprise Architect for a Fortune 100 enterprise who along with my peers needed an intervention as we were fundamentally broken. Many of us thought of leadership as something that comes from above while not acknowledging that leadership starts from within. Sure, I am a leader, after all I have lots of followers. The bigger question was whether I was being a leader 100% of the time or was this a part-time activity done only when convenient.

I along with 200 other colleagues attended a four-day training event on leadership with CruxPoint Consulting. Most leadership courses are nothing but pep rally sessions that float you so high up that you have no choice but to come down. This training was different in that I walked away with a feeling of disgust targeted at myself and my peers. It took something profound for me to realize that our culture was fundamentally busted and I needed to do my part to help make things better. The cliche of redoubling ones efforts most certainly applies here.

Part of being a leader is to spend time gaining insights from others and there is no better person than Charlene Li. The book arrived last week Friday and I felt compelled to stay up all night reading as much as I could. Even though I have never met Charlene, I felt that she was not only talking to me personally, but that we were lifelong friends. Her writing style is most certainly not the dry PhD humorless monotone repeat after me hype that is found elsewhere. This book is highly conversational and written in the tone used by humans.

The case studies aren't saved for the back of the book but instead are presented in a contextual manner. She provides solutions for every scenario possible and even I couldn't blow holes in her thinking. Using her words, I am the consummate transparent evangelist and her suggestions for improvement are spot-on.

Few leaders talk openly about their failures and even fewer learn from them. Charlene provides insight into building the trust that comes from failure by using herself as an example. She also provides much needed guidance on separating the person from the failure. Too often, the careers of good people are ruined by clueless, cowardly executives who fire people instead of taking personal accountability. She helps people understand that you didn't fail, the project did.

I started to smile when she started to discuss passive-aggressive behaviors as I didn't even know what it was till several weeks ago. Nothing destroys morale faster. I found myself being turned into a cheerleader and gave a rebel yell when she stated that the whole idea of never going to your boss without a solution to a problem is nonsense.

Many people will make the mistake and think that this book is only about implementing social media in a leadership way. This book is 100% relevant to being a leader even if you worked for the most technology adverse company on the planet.

If I had to choose my most favorite part, it would have to be the guidance on establishing sandbox covenants. These are the rules organizations set up to determine what sorts of limits and conventions there are on openness. One thing worth noting is that Charlene even broke tradition from the usual style of collecting references. She provided commentary on this as well.

In conclusion, this book is absolutely one of the best books I have read this century and encourage every Enterprise Architect I know to not only purchase a copy for themselves, but to consider purchasing a few for those above you in the organization chart. This is money and time well spent...

Thoughts on XML 2.0

Is XML the only web technology that is widely adopted and still remains at 1.0 version? On the chance that anyone from W3C is noodling future changes, here are a few enhancements I would love to see...


In my travels, I have ran across lots of horrific usages of XML. While part of the challenge is related to learning XML via Dummies books and other introductory methods that don't make it to more complex design considerations, some of it is attributable to those who desire a richer grammar and end up reinventing the wheel. The below enhancements are all related to the latter.

• Currency: We live in a global economy and should never assume that money is always in local currency. Anytime you are dealing with currency, it should be treated as a complex type that ideally should be built in. For example, you may have an attribute known as amount, an enumeration of the currency used such as Rupees, Dollars, Yen, etc and another enumeration that contains the country of the currency since dollars, rupees and yen are all used beyond a single country.
  
• Duration: Ever notice the concept of valid date ranges being constantly used. It should be straight-forward to have a reusable complex type that allows someone to specify a from and to date.
  
• Enumeration: This is probably the more interesting challenge in that we first need to a way to specify whether they are open or closed such that this can be validated via schema. The need to extend enumerations (open) within a business context is important. Examples may include supporting new diagnosis codes and procedures as medical technology advances or even the additional of new countries. Sometimes, enumerations also need to be closed and not subject to further extension (aka final). For example, if you decided to treat Gender as an enumeration, you may at most have a fixed number of values that shouldn't change over its lifetime.
  
• Boolean: The funny thing about Boolean is that it really isn't boolean. Those who grew up on mainframes and C may think of booleans as being represented by 0 and 1. Those who grew up with English as their background, may think of booleans as TRUE and FALSE. Shouldn't we strongly type booleans so that they are represented one and only one way?
  
• Namespace: We need to eliminate the notion of a default namespace and instead have the ability to mandate that all XML have one? This would making parsing ambiguity disappear.
  
• Character Set: Wouldn't it be good if you could specify what are the allowed character sets for a given attribute such that it could be validated via schema? Should I be able to shove Japanese Kanji via Unicode into an attribute where the receiver can only process English?