SOA design goals and benefits

Service-oriented architecture (SOA) continues to be punted as the utopian foundation for enterprise solutions. The merits of this systems architecture and development `way of life` are undeniable. What many IT shops are still grappling with is how to start embracing the SOA principles and ideologies. In fact, embarking on SOA-based development requires a strong commitment to a `build-for-future-benefit` approach. It requires forward thinking, a vision and complete IT buy-in if the true long-term benefits are to be realised.

Once the above commitment and joint vision have been established, a blueprint of key design and architectural principles needs to be agreed upon. These design goals will directly impact the success of systems built on a SOA foundation, as they are key to the fulfilment of many of SOA`s promises.

As we know, loose coupling allows service providers and consumers to be developed independently using well-defined interfaces. Service implementers can change interface, data, or message versions in the service without impacting consumers. Loose coupling removes the need for tight control of both ends of systems.

Each system can be independently managed for performance, scalability and high availability. Implementation changes are hidden, giving providers and consumers independence.

However, in order to achieve this, interfaces need to be standards-based and an intermediary is required to actively manage and broker requests between end systems.

It requires forward thinking, a vision and complete IT buy-in if the true long-term benefits are to be realised.

Edward Lane, Technical Manager, BEA Solutions Africa

`True` industry standards are endorsed by technology leaders such BEA, IBM, Microsoft, Sun, Oracle, W3C and Oasis. SOA is widely accepted because it can be implemented using standards-based technologies.

By using standards-based technologies, vendor lock-in is eliminated and best-of-breed combination of vendor products is enabled. As mentioned above, the concept of loosely coupled layers depends heavily upon broad support for standards both internally and externally.

As services are published in a directory and available over a network, they become more easily discoverable and reusable. Services can be reused by re-combining them for different purposes, at varying degrees of granularity.

Reuse of services eliminates duplicate development efforts and promotes consistency in implementation. Reuse of services is easier to accomplish than component or class reuse, which have been tried without much success in the past. Obviously, reuse is one of the keys to the kingdom, allowing businesses to bring products and services to market in a far shorter time frame.

In a synchronous service call, the caller makes the call, passes the required parameters, blocks and waits for the response. Synchronous services calls provide immediate response to a request if the service provider is available.

Synchronous services are essential for applications requiring real-time response, for example, services exposed and utilised on a customer self-service portal or in a call centre.

Just as synchronous calls are important, so is it important that asynchronous service calls are also supported. Here, the caller posts a message with full context to a messaging service that delivers it to the recipient. The recipient processes the message and returns the response to the caller via the message bus. The caller does not block while the message is being processed.

With the use of coarse-grained messages and a messaging service, service requests can be queued and processed at the optimum system speed. This approach provides high scalability as the messaging system can queue as many requests as its queue depth allows.

Callers do not hold network connections for the processing duration, and as callers don`t block, they are not negatively impacted by processing delays and problems in the execution of an asynchronous service.

Existing software components should not need to be modified to expose their functionality as services. Services are developed or generated using the interface definition of a component. This eliminates the need for modifying, testing and maintaining existing software.

With composite services, the functionality from existing investments can be reused and recombined to create new value for the enterprise. This again dramatically impacts time to value.

When shared services are used in applications, the rules specific to each application are externalised as policies. Policies must be managed and applied for each service at design and run time. Policy-based computing promotes the creation of generic reusable services. As customisation of services for specific applications is externalised, application implementation changes are minimised.

An organisation`s operations and support group rather than the development group typically enforces policies. Without the use of policies, application developers and operations and support groups have to work together during development time to implement and test policies. Using policies allows developers to focus on application logic while the operations and support group focuses on rules.

Common services used by all applications built using SOA are called shared infrastructure services. Using a shared infrastructure to provide common services prevents each application from building similar services.

Shared infrastructure services also provide consistency and allow a single point of administration.

A fine-grained service implements minimum functionality and consumes and returns a minimum amount of data.

Fine-grained services can be implemented using Web services, or distributed objects using RMI, .NET, or Cobra. Fine-grained services have the benefit of imposing strict security and access policies at a granular level. Implementation and unit testing are simple and independent.

Coarse-grained services implement more functionally than fine-grained services, and consume different amounts of structured data or messages. They return similar data or messages, possibly with embedded context. Coarse-grained services could comprise an aggregation of a number of fine-grained services.

Coarse-grained services do not require multiple calls over the network to provide meaningful business functionality.

The list of design goals or key characteristics above is by no means finite nor are they all mandatory. It is rather a guideline of key features and design principles that need to be taken cognisance of. None of these should be overlooked and the merits of each should be debated and considered within specific environments. It is not a foolproof remedy, but it is the starting point of a SOA initiative blueprint and business case.

BEA sponsors ITWeb`s Java industry portal. Java has emerged as a premier technology for building and deploying Web-enabled and multi-tier applications for e-commerce. This technology does, however, present unique development challenges. ITWeb`s Java industry portal looks at the pros and cons associated with its use.