The Way Business Is Moving published by
Issue Date: February 2008

Service oriented architectures - the challenges

7 February 2008
Wayne Venter, Nortel systems engineer enterprise

Today, service-oriented architectures (SOAs), which were devised to solve business problems associated with intra- and inter-company cooperation, are renewing the promise of simplifying services.
Experience has shown that in the field of voice and communications services, combining services in a robust and scalable manner has been difficult. As far back as the 1980s, proposals such as the advanced intelligent network (AIN) promised rapid and robust service creation by network owners and customers. At best, however, AIN was only a partial success.
Around the same time, the introduction of the common object request broker architecture (CORBA) promised rapid and robust service creation within enterprises. It too, was only partially successful.
One important difference between SOAs and AIN is the scope of the systems. AIN restricted itself to communications services, whereas SOAs see communications services as peers to many other IT-related services.
Although SOAs are addressing larger issues, they have provided a form of liberation for communications-centric services by offering a different way for communications and network engineers to view services.
At first glance, it may seem unrealistic to apply SOA technology - which was designed for an IT world capable of handling hundreds of complex database-oriented events per second - to the machine-driven, time-sensitive environment of telecommunications, which was built to handle tens or hundreds of thousands of simple events per second.
Indeed, mismatches between the requirements of the IT world and those of the telecommunications world in areas such as security. Availability could impede the adoption of SOA technology and needs to be addressed.
Potential mismatches
Certainly most people would anticipate serious issues of raw performance. While these issues do exist, most of the primary mismatches relate to another characteristic of telecommunications services: service level agreements (SLAs), where the service provider guarantees a certain level of service in return for a specified payment.
SOAs are enabling enterprises to base more and more mission-critical activities on services provided by independent service providers (eg, Amazon's Simple Storage and Queuing Service). This extends formal contracts and SLAs from the telecommunications arena to the enterprise.
SOA is based on the concept of combining services through orchestration.
That is, using workflow to invoke different services in a defined sequence to implement a business process. To enable providers to offer SLAs, the behaviour of the composite service must be able to be predicted and, during execution, monitored.
Unfortunately, there are a number of non-functional behavioural properties for which descriptive mechanisms do not - or, in some cases, could not - exist. While these capabilities are important to all services, they are particularly so for time-sensitive ones, such as voice or sensor networks.
To appreciate the challenges raised by this lack of definition, imagine a catalogue of integrated circuits, where the product descriptions include only the detailed definitions of the interface pins, and no definition of any of the non-functional features, such as power consumption, size, number of pins, and perhaps most importantly, a description of what the circuit itself does. Such a dearth of information would prevent a designer from 'orchestrating' that chip with others on a circuit board.
In a SOA environment, consider the simple example of combining two underlining services, X and Y to produce an orchestrated composite service - Z. Typically, services X, Y and Z can be developed and offered either by the same company or by different companies, and Z itself may become part of yet another composite service.
The flexibility of Web Services in a SOA environment arises in large part from the loose coupling of the services. To be able to predict the behaviour of Z and thereby offer SLAs for Z, without resorting to tight binding between the services, X and Y need to make visible (expose) a number of their behavioural properties, and there may be mismatches.

Others who read this also read these articles

Search Site


Previous Issues