From ZapThink's Jason Bloomberg
In particular, it is essential to take a process-driven approach to your infrastructure, instead of an integration-centric approach. Remember that building Service compositions that implement processes typically compose capabilities across multiple execution environments. Furthermore, those compositions are both dynamic and unpredictable -- the business process specialist in charge of the compositions may change them around long after you've deployed the Services. Governance becomes the key to managing that unpredictability, rather than pre-defined integrations.
Business users creating dynamic composite unpredictable applications based upon services you have deployed. I think this is where SOA starts getting the Ivory Tower reputation. I really don't believe that 99.9% of organizations will or even should attempt to achieve this. I think before you propose something like that you should have some details on how you would accomplish it. Show how your service design could so flexible and robust to account for unknown variations on how it is composed without compromising your companies critical data and infrastructure.
My next issue came with this part.
One essential point here is that SOA leverages interoperability more so than portability. In a virtual machine-based "write once, run anywhere" environment, whether Java or Microsoft Common Language Runtime (CLR)-based, distributed computing relies upon the portability of code. SOA, however, leverages the interoperability of the Service interfaces so that you don't need to move the underlying Service implementations around. As a result, running all your Services on the ESB can actually impede your SOA implementation, rather than support it.
I don't disagree with a distributed service environment but again one size doesn't fit all. Managing a distributed service environment is not easy and in fact can also impede your SOA implementation. Extremely strong governance is a must in that type of environment. The fact is some organizations are better suited for a centralized bus approach and there is nothing wrong with that.
The last issue is on messaging. Here is the quote:
So, only use the traditional messaging middleware capabilities of your ESB if you really need them, and only leverage the Service runtime your ESB provides when convenient, but configure your ESB as an intermediary to get full value out of it as part of your SOA infrastructure.
There really isn't any detail here to explain the thought on why messaging is bad. Does it mean all messaging including SOAP based messages? Or is it just targeted at the built-in messaging most ESB's provide? Either way I don't follow. Messaging is very powerful and robust. Given the state of most Web Service development I have seen, more traditional messaging can be a powerful alternative. Remember that a service is not a technology specific thing, right?
The article also had a lot of strong points in my opinion. In particular this is a good quote to reiterate.
The bottom line is to always remember that the business drives the architecture, and the architecture drives the technology. Don't let the technology drive the architecture! SOA is particularly adept at abstracting existing technology, which can include recently purchased products in addition to your legacy environment. But knowing which of your existing capabilities to leverage -- and which to forego -- can make or break your SOA initiative.
IT has been known to go out and buy technology and then go looking for a problem to solve. To the point of the article knowing when to leverage your existing technology is very important. That can be an existing ESB though and that's okay.
No comments:
Post a Comment