Service-Oriented Architectures (SOA)
SOA is the new buzz word everyone in the architect team is talking about. The other two are SmartClient and WSE, by the way. So what is SOA? What a service-oriented application looked like? What is drive for SOA? What are the implications in terms of customer experience, operation benchmarks: reliability, availability, scalability, performance etc and software engineering: implementation process agility, data and process modelling and designed patterns.
After a week’s miserable, wintry days, I am sitting in my study whcih flooded with sunshine, enjoying this glorious Sunday morning. What could be an even better thing to consolidate all these? I even have my sunglasses on .The better half is tidying up the front garden. Bless her.
What is SOA?
By definition from Microsoft .NET Frequently Asked Questions, ‘SOA describes an information technology architecture that enables distributed computing environments with many different types of computing platforms and applications.’ SOA is not a programming language, nor a programming model, nor a Design Pattern. It is an emerged ENTERPRISE Pattern.
What SOA looked like?
In typical n-tier enterprise architectures, SOA abstracts middle tiers and exposes the complex business object interactions and heterogeneous backend (say composed of a DB2 database, an Oracle and a few 3rd party extranet calls) as ‘contract-services’. The result is a ‘loosely coupled, and standards based’(Dave Chappell Extracting Business Value from SOA )enterprise system.
Following figures are from Chip Irek’s excellent paper Realizing a Service-Oriented Architecture with .NET shows a sitting plan of the SOA service interface.
A typical 3-tier application architecture
A service-oriented application architecture
Now image this is a simplified IT architecture of a bank. There are handheld devices, browser client and other smart clients the presentation box needs to support for internal and external customers. For a typical transaction of credit account, it involves customer database, product database and calls to BACS (Bankers Automated Clearing System).
As you can see in the second figure, the purple cloud - service interface wraps the entire transaction and exposes it as single point of contact to the caller – the presentation box. (The two cubicles in the purple cloud should be read as two unrelated requests happened to be invoked from the same client to simplify the case.)
On receiving a client request, ‘services purple cloud’ orchestrates calls to discreet business objects (traditional middleware), in our case retrieving customer data, retrieving product information and issues a request for credit to BACS. The purple cloud also manages the responses, and finally response to client.
In contrast, in a traditional n-tier application, presentation box are heavily interacting with business objects directly.
Why do SOA?
I cited Chip’s Realizing a Service-Oriented Architecture with .NET here: ‘A good architecture emphasizes a separation of responsibilities. For example, the presentation tier manages presentation components; the business logic tier manages business logic components; and the data access tier manages data access components.’
‘This separation provides for fault tolerance, easier maintenance, and future-proofing. A good service-oriented architecture is nothing new, just a smart way of separating (and exposing) a component's responsibilities.’
Fault tolerance, easier maintenance, and future-proofing are big marketecture buzz words to tell VPs and CIO. Regardless how these words have been abused, they are true in SOA scenario.
In a recent online application project I have worked on, we see these immediate benefits. This is high level description of the archetecture:
The gain is multi-dimensional.
From presentation (client) point of view, what happens between request-submitted to response-returned is a black box case. We do online transaction at the moment, but we could also dehydrate the application data if some business functions hosting in a different platform down. These are all transparent to the client. And because the only link between client and service is the application XML schema, it is easily accommodate the future needs. Say, we now have presentation supports web client, but if we do Windows Form or B2B whole sale, the same XML schema is suffice without requiring any change to purple cloud and behind it.
For code implementation point, the development is naturally broken down into more manageable iterations. The first iteration is to implement the application data dehydration. Then we add online transaction capacity in second iteration. Should business process decide to call a stop for iteration 2, the iteration 1 deliverable can still go live without a hinge. (There is a process to extract dehydrated data though, it is needed anyway.)
What enables SOA?
As you guessed, the key player in SOA is the SOAP and Web Services. In our case study, presentation box validates and serializes application data SOAP message then invokes call to the web service. From presentation point of view, the entire end-to-end business process has only a single point of contact.
Compares SOA and OOA
SOA is not the Chinese monkey king born out from rock. It evolves from the classic object-oriented architectures.
In Object-oriented architectures (OOA) paradigm - not sure if this is an establish name, I used it just to contrasting SOA – such like COM, DCOM, RPC, .NET Remoting and etc, ‘objects are marshaled across process boundaries through the proxy/stub techniques… provides benefits such as location transparency.’ (Chip Irek). This requires stateful objects persisted multiple communication links and lots of plumbing boilerplate codes. These communication links contributes to more tightly coupled architecture between presentation and middleware.
Table is turned in a service-oriented architecture. As you see there is no coupling between presentation and middleware. Clients consume services rather than invoking discreet method calls directly. The result is a loosely coupled system that glued together by contract of SOAP message.
Don’t get confused by the SOA, OOA and OOAD (as of object-oriented analysis and design). Object-oriented architectures and service-oriented architecture are enterprise architecture patterns while OOAD is the data modeling, programming methodology. SOA doesn’t and shouldn’t defy OOAD in implementing business process – the black box behind the purple cloud.
On a side note, in last year’ MS PDC in Amsterdam, Don Box informally compared the performance between Remoting and Web Service and the conclusion is web service wins. 'On ASMX serialization vs. binary serialization with remoting, ASMX will be faster than .NET remoting, short term performance gains using remoting today will not position your applications for future releases'. Read it here
SOA Design Issue
Having said the OOAD can be applied, it doesn’t mean there is absolutely not changes in the design patterns. I reckon the biggest challenge is to design the application as composed of stateless components while it still provides a rich customer experience. Get back to the online application process in our case study, the application data should be a modelled against its paper based cousin. It should be self –described. So anyone picks it up can process it without restoring help from other system.
I cite (again) Chip Irek to conclusion how to effectively implement SOA design: ‘Web methods should be designed to perform an entire service for an entire form.
Reference:
Chip Irek: Realizing a Service-Oriented Architecture with .NET
Further Reading:
Dave Chappell Extracting Business Value from SOA
James Greenwood SOA Design with Agile methodologies
No comments:
Post a Comment