http://bill-poole.blogspot.
http://bill-poole.blogspot.
Very impressive arguments. Thanks to Sriram for sending me these links.
Wednesday, May 27, 2009
SOA Layering
The following links from Bill Poole is a must read for the SOA developers and architects.
http://bill-poole.blogspot.com/2008/05/layered-service-models-are-bad.html
http://bill-poole.blogspot.com/2008/05/layered-service-models-are-bad_20.html
Very impressive arguments. Thanks to Sriram for sending me these links.
http://bill-poole.blogspot.
http://bill-poole.blogspot.
Very impressive arguments. Thanks to Sriram for sending me these links.
Wednesday, May 20, 2009
ESB - Does my project need it?
A key component of the SOA architecture is ESB. Most often ESB is used as silver bullet to clean-up the Enterprise integration mesh.
I came across quite an interesting perspective after a brief session with Jim Webber, an advocate of Guerilla SOA.
From my past experience following are some of the key reasons for using an ESB.
ESB cleans-up the integration mesh (or mess)
A typical diagram of ESB based transformation is as shown above. In reality all the mesh gets into the ESB itself; ESB encapsulates the mesh. Subsequent to the ESB based solution implementation, enterprises would have to setup teams to manage the ESB and deal with the governance around the ESB usage.
Eventually there is a possibility of the mesh outgrowing the ESB and spilling over; taking the integration back to where it started. Only difference this time is that the ESB will be part of the mesh.
ESB is good for business process orchestration
This is one of major feature that attracts a lot of developers. As a result, the business process gets into the ESB. The ESB now contains the critical business process of the enterprise, apart being just an integration back bone. This makes whole system extra complex with business logic spread all over.
Other ESB vices
In general usage of ESB results in vendor lock in. Business process is always wired in using vendor specific languages.
Performance hit with ESB is significant. More dollars are spent scaling this beast.
Occasionally project requires development custom adapter/data transformers to be used with ESB - additional effort for the development team with already strict time lines.
Is ESB useless?
No, its not; but ESB is not a silver bullet.
ESB assists the project in meeting the data transformation and communication requirements. Its a good candidate for dealing with disparate protocols (FTP, IIOP, and SOAP) between the interacting systems
How do I deal my integration mess?
Business Chaos Modeling!!
As I understand, Guerrilla SOA advocates modeling the SOA integration based on the real world business process. This is an interesting perspective.
As we all know traditional software that models the business domain is the one best meeting the business requirement. Why can't we extend this to SOA?
Just model the business interactions between services. If thats a mesh, so be it. The business itself is running with so many interactions.
If a clean-up is required, then the change should originate from the business domain. This business domain change will percolate and would warrant a change in the SOA model.
I feel this is idea of modeling the business chaos among the services is so much in line with the philosophy of SOA which promotes the alignment of software systems in line with the business.
ESB can definitely not clean-up the so called chaos that originates in the business domain.
Business Process Orchestration
Business process is just business logic; why treat the process as a special entity? Implement the process like any other business logic. Such an implementation would ensure the entire business logic remains as a single unit and is more manageable.
Managing Chaos
Manageability of the solution/system post implementation is critical to any client. Although we model the business domain mesh in our system, it critical that the mesh be manageable. Monitoring and control interfaces to manage interactions are essential.
Summary
A manageable business integration (SOA), with thoughtful ESB usage would definitely make the client happy and align the implementation with business!!
Hmm...quite a change of ideas in me after getting to know about Guerrilla SOA!!
I came across quite an interesting perspective after a brief session with Jim Webber, an advocate of Guerilla SOA.
From my past experience following are some of the key reasons for using an ESB.
ESB cleans-up the integration mesh (or mess)
A typical diagram of ESB based transformation is as shown above. In reality all the mesh gets into the ESB itself; ESB encapsulates the mesh. Subsequent to the ESB based solution implementation, enterprises would have to setup teams to manage the ESB and deal with the governance around the ESB usage.Eventually there is a possibility of the mesh outgrowing the ESB and spilling over; taking the integration back to where it started. Only difference this time is that the ESB will be part of the mesh.
ESB is good for business process orchestration
This is one of major feature that attracts a lot of developers. As a result, the business process gets into the ESB. The ESB now contains the critical business process of the enterprise, apart being just an integration back bone. This makes whole system extra complex with business logic spread all over.
Other ESB vices
In general usage of ESB results in vendor lock in. Business process is always wired in using vendor specific languages.
Performance hit with ESB is significant. More dollars are spent scaling this beast.
Occasionally project requires development custom adapter/data transformers to be used with ESB - additional effort for the development team with already strict time lines.
Is ESB useless?
No, its not; but ESB is not a silver bullet.
ESB assists the project in meeting the data transformation and communication requirements. Its a good candidate for dealing with disparate protocols (FTP, IIOP, and SOAP) between the interacting systems
How do I deal my integration mess?
Business Chaos Modeling!!
As I understand, Guerrilla SOA advocates modeling the SOA integration based on the real world business process. This is an interesting perspective.
As we all know traditional software that models the business domain is the one best meeting the business requirement. Why can't we extend this to SOA?
Just model the business interactions between services. If thats a mesh, so be it. The business itself is running with so many interactions.
If a clean-up is required, then the change should originate from the business domain. This business domain change will percolate and would warrant a change in the SOA model.
I feel this is idea of modeling the business chaos among the services is so much in line with the philosophy of SOA which promotes the alignment of software systems in line with the business.
ESB can definitely not clean-up the so called chaos that originates in the business domain.
Business Process Orchestration
Business process is just business logic; why treat the process as a special entity? Implement the process like any other business logic. Such an implementation would ensure the entire business logic remains as a single unit and is more manageable.
Managing Chaos
Manageability of the solution/system post implementation is critical to any client. Although we model the business domain mesh in our system, it critical that the mesh be manageable. Monitoring and control interfaces to manage interactions are essential.
Summary
A manageable business integration (SOA), with thoughtful ESB usage would definitely make the client happy and align the implementation with business!!
Hmm...quite a change of ideas in me after getting to know about Guerrilla SOA!!
Subscribe to:
Posts (Atom)
