Understanding and implementing SOA in a middleware environment

SOA (Service-Oriented Architecture) is arguably one of the most misunderstood terms in the IT industry.

Whilst this is probably because the term has been around since the earliest days of computing in the 1960s and 1970s, when software flowcharts were de-rigueur for program development, the methodology is highly appropriate to today's 32- and 64-bit computing systems.

Put simply, SOA is a methodology for defining how different business processes - which can be fully or partially IT-enabled - interact with each other.

The aim of SOA modelling is to develop a loose coupling between different operating systems, their software and other technologies in such a way that it is possible to easily exchange data between the various processes.

To do this, SOA defines the IT-enabled business functions of an organisation into separate services which can then be linked together across a network.

The major advantage that stems from positive use of SOA is that quite disparate IT elements can be linked together: for example, a 1980s legacy mainframe-based system can be efficiently interfaced with a modern client-server PC-based network without wastage.

Furthermore, the programming that underlies the legacy systems can also be re-used in the modern computer system, thanks to the use of common coding structures and other programming approaches.

What's in it for me?

Whilst SOA methodologies were the domain of `men in white coats' in the 1980s and 1990s, the discipline of approaching IT development - at all levels - using an SOA model is that many more people in a given organisation can understand how the IT process works.

At its most basic, a 3D flowchart-style map can be drawn up of a company's various IT-enabled processes, allowing most managers to understand - in relatively simple terms - what is required to interconnect the various IT functions together.And, perhaps more importantly, it allows IT staff to slot in and integrate quite disparate computing functions such as when companies acquire each other, merge or similarly evolve.

The use of EDI (electronic data interchange) to allow disparate IT systems to interact with each other under SOA is an important feature, as it gives companies the ability to allow third-party firms to interact with their IT resources without having to recode their respective IT systems.

It also allows cross-checking and validation of data between systems allowing, for example, a customer of one company in a financial services group to open an account with another in the same group, with the minimum of fuss, and link the two accounts as part of a cross-selling portfolio.

Cross-selling is one of the major advantages of SOA in the modern IT environment. It allows, for example, an airline to cross-sell - with permission-based exchange of data - hotels and car rental add-ons to their flights.

British Airways, for example, uses SOA-enabled technology to allow it to cross-sell hotels, car rental and other travel-related services on an integrated basis via its main Web portal.

Look closely at other e-commerce-enabled Web portals and you will see SOA weaving its magic to make life easier for the consumer, as well as maximising business efficiencies and helping to minimise IT costs.

SOA implementation in the real world

Assuming that you've read this far and are attracted to the idea of being able to future-proof your overall IT systems against the hurly-burly of modern acquisitions and mergers, as well as keeping costs under control, how to you effectively implement SOA?

The process is not as difficult or nebulous as some experts make out, as SOA modelling allows management to build applications out of software services.

These services - which can be quite different (e.g. a flight booking with one airline and a hotel booking with another company) - have no program code calls between them. They are two separate programs running on two distinct computer systems.Instead of program code calls, SOA modelling allows the use of common protocols for both systems to communicate with each other. And, perhaps more importantly, it allows other systems to intelligently communicate with each other as they are added to the mix.

This process is called orchestration in the world of SOA and allows different services to be associated with each other on a non-hierarchical basis.

The process differs markedly from the traditional programming approach of associating different program functions (classes) together in hierarchical group as normally happens when a complete IT system is developed from the ground up.

And this is the beauty of SOA modelling - it allows entirely different IT systems of different ages and different operating systems to be loosely coupled with each other and for them to efficiently exchange data between themselves.

All of which leads us neatly into talking about the integration of the latest Internet technologies, including Web 2.0 services, into the IT systems of a typical company.

In the early-to-mid-1990s, when the World Wide Web was starting to take off, many companies actually had to print off their orders from the Internet and re-key them into the existing sales and order processing system.

Using SOA this archaic practice goes out of the window. Even data from social networking sites such as Facetime and MySpace - which are classic examples of Web 2.0 services - can be easily integrated into the IT mix using SOA modelling.

According to respected IT authors Tom O'Reilly and John Battelle, Web 2.0 services like Facebook are actually a platform, with various applications operating in the Internet environment, and generating data along the way.

For the hard-pressed IT manager, integrating data from the Web 2.0 environment - which could come in a variety of formats - into the company IT resource can be an extraordinarily difficult process.

Unless you bring SOA modelling into play.If the data from the Internet is reduced to its basic constituents, such as data fields and allied strings of information, then the resulting protocol can be read by almost any IT system.

This process is called the creation of metadata and forms the corner-stone of allowing quite complex data to be exchanged between the Internet and company IT systems, whether they are mainframe or PC client/server-based.

It's this process of data interchange that allows IT professionals to create a federation of resources and, in the process, allow the re-use of program code between what are traditionally viewed as different computing platforms.

This is SOA at its best.

If we go back to the 1980s when several different home computing platforms were around, including the BBC Model B, Commodore C64 and Sinclair Spectrum, the biggest problem facing the software houses of the day was how to develop games and applications that could be easily ported between the various platforms.

The more advanced programmers of the day quickly realised that code porting was the wrong approach.

Instead, they used an SOA modelling approach to define the various elements of each application - typically clusters of machine code for the different computing platforms - and how those elements interacted.

Using this approach allowed programmers to re-use the elements on different platforms, using and re-using the program code to perform the specific functions of each computing platform.

Fast-forward two decades and we can apply the same principles to integrating data and programs both within a company and outside, as well as exchanging data intelligently with the Internet.
Metadata is at the heart of effective SOA

From this we can see that the effective use of SOA is highly dependent on metadata and its effective exchange between quite disparate IT environments.

Perhaps more importantly, the metadata itself needs to be in a form that facilitates the automatic discovery - and incorporation - of new types of data formats within a given IT process.

In our airline example given above, this means that, if a new travel facility (e.g. Eurostar) is grafted on to a bookings system, then the booking systems will recognise that Eurostar is a rail transport system and process the data accordingly - without the need for full-blown human programmer intervention.

And, from a programming viewpoint, this is where the effective use of SOA modelling engenders a number of business efficiencies, including the development of a common data model between systems.

Despite the nebulous concept of SOA modelling, it's perfectly possible to adopt traditional programming techniques, such as the development of a common data model.

Using a common data model approach allows developers to view data as a part of the architecture and, in doing so, couple the data to the services in the SOA model.

The slightly bad news is that it's only possible to loosely couple to the data to services. The best approach is to start with the services and work back to the data - redesigning and redefining the service after you define the data layer.

It's also important to realise that the resultant abstracted - or common model - must be tested like any other program component.

A good service-oriented model takes a holistic view of the analysis, design and architecture or all the software entities on a company IT resource and views those entities as service-oriented assets, which are collectively known as services.Central to many SOA converts' business processes is WS-CDL (Web Services Choreography Description Language), an XML-based language that describes peer-to-peer collaborations of participants by defining their interaction and overall behaviour.

There are several other Web Services languages in common usage in the SOA community but, according to Mark Little, SOA Development Manager within RedHat's JBoss division, WS-CDL is one of the best options for any company looking to develop an SOA methodology.

WS-CDL, he argues, allows IT managers to define interoperable and peer-to-peer collaborations between any type of participant regardless of the supporting platform or programming model used by the implementation of the hosting environment.

As such, he says, it allows the easy development of an SOA model, without the user needing to know how the specific assets function in their respective environment.

SOA engenders business efficiency

Against this backdrop, Little says that the important thing to realise with SOA modelling is that its use engenders business efficiency.

As a starting point, he explains, it allows managers to take a holistic view of their IT resource and, if the need for integration of a new IT system arises - perhaps as a result of a merger or acquisition - then the process can run quite smoothly.

In the shorter term, meanwhile, SOA modelling allows IT managers to respond quickly to changing market conditions.

This, says Little, is particularly appropriate to the current `credit crunch' situation which is forcing many companies to dramatically change their expansion plans and even downscale some of their operations.

Despite what some experts say, SOA is far more than simply taking a modular approach to programming - it creates a multi-dimensional flowchart model of the business IT process of a typical organisation that can be represented on-screen on a drill-down basis.

According to Little, it can also - and this is a major plus for those companies operating a legacy or semi-integrated set of IT systems - be used on a distributed platform.

And finally, he notes, it engenders better management planning since it allows all members of the IT team plus, with a little education, the management team, to understand how the various IT systems interact within an organisation and/or group.