From IBM’s presentation about SOA from Board Room a few hours ago. I loved to attend this meeting, ’cause from there I’d got a new perspective about how the system is designed based on Service. Thanks for IBM, and Mrs. Hana Parker for her interesting and interactive presentation. Below is my summarization about service oriented architecture as I got the big picture from the presentation. If there was any wrong concept, please correct me and let me know.
SOA’s Point of View
Suppose that we have existing functionality in our organization, but the functionality resides in separate system, such as: (1) the data is in a database, (2) the bussiness logic is in a legacy mainframe application, and (3) the bussiness logic is also in a J2EE application. We would like to extend the current system without affecting running system, and of course there will be no problem if we want to create new functionality. In SOA’s point of view, things that exposed to be “an services” is bussiness functionality, not applications minded. Take a look at the figure below:
If there are Purchasing application which have Request functionality and Financial application which have Check Budget functionality, on contrary with Object Oriented Architecture which will expose Purchasing and Financial as Objects/Application and Request and Check Budget as Methods, SOA will expose Request and Check Budget as service. So, an application may have one or more services.
As you’ve seen at figure above, this simple diagram showing an distributed architecture. We have two database, one J2EE application. So, talking about database connectivity, we have 2 connections. If we add one more application which connects this two databases, there’ll be 4 connections. And as the system grows, the diagram will be much more complex and just like Mrs. Hanna said, a spaghetti diagram.
SOA comes with solution. We add an interface, let say, a pipe, or whatever. Every resources such as database back-end, or existing applications connect to this pipe. IBM introduces their terminology: Enterprise Service Bus. Any services is defined here. Applications exposes their functionality as a service and its service will reside here. By then, application which has connectivity with user (user interface) will access this ESB and access what they need. Of course, it can be defined, what services can be accessed by an application. SOA claimed that this approach will be much more simpler than spaghetti architecture when the system grows bigger and more complex. It doesn’t matter which database should be accessed by an application, but the point is, which services should be accessed by an application. Its services is provided by an service provider which has direct connectivity with its needed resources such as database, file server, and so on.
Well, it’s a very big subjects to learn, and unfortunately, I don’t have much time just like when I’m still in college. Technology is always running fast and we should keep our eyes on it.
Hihihi… ;)) sengojo ditulis neng boso enggres, sopo ngerti si bule iku moco :”>