A life of service

SOA - new developers start here


Comment While pundits argue about when Service Oriented Architectures (SOA) will take over the world, there is a reasonable consensus that this is the way much of the business IT implementations world is moving. Given that, the world of the applications developer is liable to change, with perhaps the most important aspect being the expansion of the frame of reference of the title 'developer', which will shift from variations on a code-cutting theme to include the development of business processes.

This shift will open up opportunities for both existing code-oriented developers and business people with a technical bent, which is why it was interesting to hear Steve Elliott of Sun's Client Solutions Organisation speaking at the recent Java 06 conference in London. He set out a good grounding for most of the factors developers of all hues need to be considering as SOA creeps inexorably up on them. These edited highlights make a good start-point tutorial.

One of the key factors is that SOA will not just change the rules for developers but also for vendors. Regardless of what they will say there is a need for a little reality check. This is based on a quote from Jim Waldo of Sun - the main architect of JINI. It is what he calls the 'Highlander Principle', taken from the Highlander films, where vendors will tell users 'there can be only one'. This is the first and most important fallacy to learn and dismiss, no matter what the vendors say. There is not just one way of doing SOA. One of the most important examples of this is that web services do not equal SOA. There are other architectures that are just as valid, including JINI, Web 2.0 and Mashups. The driver is the complexity of the services required by the business. A mashup based around Google maps is still a service.

A good example of how to think about services is the 'Victorian Gentry' model. They pull a bell rope and, a few minutes later, a butler appears with tea and cakes. They didn't care too much about the implementation below stairs. It is not about the technology of the implementation. What they care about is quality of service, and that is subjective. Most users will be irritated but not damaged by a railway timetable service being down for five minutes, but risk serious problems if their bank system is down.

So the technology is important, but the key issue here is how does one infrastructure and service talk to another. There are standards involved here, such as HTTP, and some key web service standards such as Web Services Definition Language (WSDL) which enables developers to describe a service. There are also architectural standards to consider that focus on layers and granularity.

Orchestration, the ability to take individual services and binding them together to create composite services, with one service controlling the rest, is an important process to grasp. Another is Identity Management, the concept of having policies that apply a network identity and a federated identity to services and users. This is important as services must be able to authenticate with each other as appropriate.

Governance is becoming a hot topic as well. As you build more services, the ability to locate the service needed is important, as is the ability to manage their individual life cycles.

Most business services will be composites, and may even be made up of services running on different systems, so building a platform to run the composite is an important consideration. The first step is to have some service composition tools available to create the services and plait them together into a composite service. Then they need to be managed so they can be governed, registered, and have access authorisation and identity controlled. Only then should a developer consider issues of access and delivery: for example is it delivered to a webpage, or perhaps a mobile that uses a different protocol.

There are a number of standards bodies worth checking out, such as the Java Community Process for all things Java; W3C, responsible for defining and controlling the core XML standards and standards like WSDL; and the Web Services Interoperability (WS-I) organisation. This is not a standards body but responsible for working out how to take existing standards and plug them together to make interoperable web services. This is particularly important in getting Java stacks and .NET stacks to work together, which will be a common requirement. OASIS is concerned with higher level issues such as security, and addressing modes, while the Liberty Alliance focuses on identity management issues.

These standards are important to know about, particularly if the services planned are complex, for they will need security, transaction management and the like. It is certainly true that some services are far simpler and will not require this level of knowledge.

Knowledge of Business Processes will be important, especially when any sort of transaction is to be used. In real life the process flow is important - get actions out of sequence and a process can collapse. And many of the processes are long-lived, they can take a good bit of time to run their proper course. This is where Business Process Execution Language (BPEL) is important. This defines the long-running, stateful and transactional services, plus their integration into higher level composite services. These are sometime referred to as AC/DC services - asynchronous and document-centric conversational services. These are the archetypal loosely-coupled services that are defined by business processes not technology.

So today 'developer' does not just mean someone who cuts code every day, it also means someone who develops systems at a process level and a growing number of tools are now available to speed the generation of code from process models. One of the main ones is Java Business Integration (JBI), which provides an interoperable architecture in which developers can create service engine or binding component plug-ins. These enable one set of services to be integrated out, using whatever protocol is required, to another end service. This maps on to real life, where there are many different protocols in use, never just one (regardless of what the vendors might suggest). JBI allows developers to define the bindings that link out from a user's internal 'world'.

There is also a need to be able to integrate new execution engines into an architecture if they are required. There are many different engines already available, but many users will still require their own. JBI allows developers to write their own rules engine that can be inserted into the overall integration architecture. Much of what JBI is about is in fact aimed at the main SOA-oriented vendors, while other aspects are aimed at applications service vendors. Knowing that such environments exist, however, and how to use them, will allow developers use the visual modelling tools in ways that exploit that existence. ®

Biting the hand that feeds IT © 1998–2018