Introduction
Any enterprise has are various business processes like selling, payrolls, staffing, transactions to mention a few. Most of the business processes are dependent on each other and can be broken down into one or more discrete units called services. These can be assembled to create automated business process and establish relationship with client.
Working with SOA philosophy, one has to automate these services in a way that client is unaware of their implementation. The relationship between services and a client is of limited dependency.
SOA –Driving Factors
SOA is fundamentally strong, being service oriented. There are strong factors that reinforce their use, as outlined below-
Technology – SOA based web service architectures can addresses fundamental problems otherwise inherited in complex, tightly coupled and distributed multi-platform enterprise architectures.
Open Standards – Open standards, like XML based protocols and Web Services Description Language (WDSL) take the business away from risks of vendor-lock in and dependency.
Service Orientation - SOA reinforces focusing of IT development for underlying business requirements. SOA has particularly potentially huge advantages in case of Greenfield ventures because one can take up state of technology and the task of studying and conversion of existing systems does not exists.
Tight and Loosely Services
In loose coupling, one module is independent of internal implementation of another module and interacts with other modules with a stable interface. Also change in one module will not require a change in implementation of other modules.
The following example explains and distinguishes the two types-
CLAP (Customer Letter Application) uses GMA (Get Mailing Address) function to print customers mailing address. GMA is coded in Flashy Software and requesting client to invoke Flashy using a complex set of Flashy parameters and pass either a customer details to be printed. In first take, the Flashy will pass message stating if it has found/not found client(s). Based on the first, the calling client makes the second call. The first Flashy return ends the conversation by sending the requested mailing address. As seen in this case, two separate calls with different information are passed to retrieve one mailing address, making it a fine-grained transaction.
In loose coupling on the other lateral, one aims for coarse granularity. In coarse granularity, the calling client can provide the required information service in one go.
Had the services in above case been loosely coupled, GMA would have been set as web service, with its interface described in WDSL. CLAP, the calling client would then be unaware of underlying implementation and would have simply provided set of XML data (as suggested in GMA service contract). The GMA service contract would have also defined the GMA return data.
Subscribe to this comment's feed
| < Prev | Next > |
|---|
