Site sections

Software Directory Mainframe Strategy Hardware Upgrade Software Upgrade Mainframe News Articles & Reviews Mainframe Sites IT Job Sites Contact Us About Us Home

SOA Fundamentals

Article by William Hoffman, mainframe-upgrade.com
Published May 2006, Copyright © 2006 mainframe-upgrade.com

The fundamentals of Service Oriented Architecture

	This article introduces the basic principles of Service Oriented Architecture and has many links to useful resources on the web that will give the reader a good start in this exciting area. For those wanting to learn in more depth then see my book recommendations at the end of the article. Introduction Enterprises are made up of a set of Business Processes. That is what makes a company tick, it's the day to day, week to week, year to year stuff that the corporation does to make a profit - provide a service, make something, sell something, receive money, issue invoices, bank money, pay staff and so on. Most of these processes can be broken down into more fundamental discrete building blocks known as services. SOA dictates that all services that can be automated be built in such a way that no calling client needs to worry about how it is implemented - the service is truly an abstract black box with a formal contract of engagement , the services can easily be reused and assembled into Business processes and the relationship between services and clients is one of limited dependency. This is what the business really wants ! They want to play with their Lego and make lots and lots of money. If you have been finding the concepts and jargon hard to take then take a step back and take a fresh look. Business, more and more nowadays, needs to react to change in a slick way. They do not want to have to wait for the IT department to spend six months building something that may be out of date by the time they get it. What they need are the building blocks with which to assemble their processes. The pain will be transforming current Enterprise architectures into this SOA approach - the pleasure will be working in that environment once the architecture is bedded in. And one word of warning, new start-ups that adopt this architecture on green field sites will have a potentially huge advantage - so in our view there is not really any option but to take this seriously. So why is Service Oriented Architecture an idea that can work now? SOA is not new; it's something we have been aiming at for a long time. There are three main factors that take it beyond the hype: Open Standards - XML based protocols including Web Services Description Language (WDSL), which describes the public interface to a web service. This is incredibly important, and amazingly we are now moving away from the vendor specific protocols of the past. Technology - Web Service based architectures are mature enough now to do the job and legacy mainframe systems can sit in that architecture comfortably. SOA addresses the fundamental problems inherent in the complex, distributed multi-platform, tightly coupled Enterprise Architectures we are currently lumbered with. Business Requirements Focus - SOA also imposes a healthy re-focusing of IT development onto the underlying true Business requirements. To make SOA work, there are some basic concepts that need to be understood and followed. Here I will concentrate on one, Loose Coupling, which relates to many other SOA principles and I list many others with plenty of links to sites with good explanations and guidance: Loose Coupling Definition Loose coupling means that one module does not have to be concerned with the internal implementation of another module, and interacts with another module with a stable interface. With loose coupling, a change in one module will not require a change in the implementation of another module. Loose coupling is a sign of a well-structured computer system. Example of a pair of Tightly Coupled services: To better understand the concept of Loose Coupling we'll take a look here at a fictional pair of Tightly Coupled Services. An automated customer letter application known as CLAP uses a function called Get Mailing Address (GMA) so it can print the customers mailing address on the front. This function is written in Flashy Software and requires a calling client to Invoke Flashy using a complex set of Flashy parameters, Pass either a customer reference or a name Flashy will then pass back a message stating whether it has a) found a client b) Not found a client c) found multiple clients The calling client can then make a second call based on the first Flashy return, which requests a mailing address, ends the conversation, or provides additional information to try and identify a client from a link. This is not Loosely Coupled because If GMA was rewritten in Fishy software then CLAP would have to be amended to call Fishy instead of Flash (not vendor independent messaging). CLAP has to make two calls to GMA, the second of which depends on the state of this function following the first call - i.e. GMA is not a stateless service. CLAP has to understand the state of GMA. This creates a logic dependency and any small changes to the GMA service are likely to result in CLAP changes too. E.g. Flashy upgrades GMA to return a found client in two ways: found client in USA, and found client Not In USA. The fact that at least two calls, with different pieces of information being passed, need to be made to retrieve one mailing address, make this a fine grained transaction. We should aim for Coarse Granularity, which in turn helps achieve Loose Coupling. Coarse Granularity is achieved when the calling client is able to provide all the information needed by the service in one go. A Loosely Coupled SOA version of the example would see the GMA set up as a Web Service, with its interface described in WDSL. The calling client, CLAP would not be interested in the underlying implementation and would simply provide an agreed set of XML data as required in the formal service contract of the GMA. The formal service contract would also define the GMA return data. This would all be done in one call. Other commonly discussed SOA concepts and principles include: Reusability Stateless Services Formal contracts between Services Coarse Granularity Asynchrony Abstract Underlying logic (black box) Composable (services as building blocks) Discoverable services Autonomous services Links The following links provide interesting SOA discussion and theory on these concepts and give a good grounding in the subject. The ubiquitous Thomas Erl - author of Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services and Service-Oriented Architecture (SOA): Concepts, Technology, and Design has numerous interesting articles published on the web including a thorough primer at The Principles of Service-Orientation – SOA Webservices Journal as well as Paths to SOA High Roads, Low Roads, and Roads Less Travelled and a Glossary of commonly used Web Services terms with actual code examples where appropriate. Other good articles and sites What Is Service-Oriented Architecture by Hao He Web Services and Service-Oriented Architectures at service-architecture.com IBM - Migrating to a service-oriented architecture, Part 1 What is service-oriented architecture? – JavaWorld article At your service - Forget buying software; build your next application from existing components Web Service-Oriented Architecture - The Best Solution to Business Integration By Annraí O'Toole Service-Oriented Architecture: A brief introduction from SOAPRPC Words of warning: Boards running scared of SOA - and even IT bosses see hype clouding the business benefits Security in a Loosely Coupled SOA Environment By Eric Pulier and Hugh Taylor Has SOA jumped the shark? Other books worth a read: Service-Oriented Architecture (SOA): A Planning and Implementation Guide for Business and Technology Eric A. Marks, Michael Bell Service Oriented Architecture Compass: Business Value, Planning, and Enterprise Roadmap By Sanjay K. Bose, Marc Fiammante, Keith Jones, Rawn Shah and Norbert Bieberstein General SOA sites of interest The brilliantly named looselycoupled.com Thomas Erl's soasystems.com Oracle's Service-Oriented Architecture Technology Center Sun Microsystems - Service Oriented Architecture BEA - Service-oriented Architecture
[Back]

Mainframe-upgrade.com permits the re-publication of this article on condition that the author agrees and that mainframe-upgrade.com is clearly shown as being the original publisher. The information should incorporate a hypertext link to www.mainframe-upgrade.com, and show the year and month of the original publication. Please contact us for further information.