Chances are you've heard the term service-oriented architecture (SOA). It describes a software architecture in which reusable services are deployed onto application servers and then consumed by clients in different applications or business processes. If you've tried to find information on SOAs, the chances are also good that you found a description that includes Web services, often exclusively. This might have led you to the conclusion that if you aren't using Web services, you have no need for SOAs. This couldn't be further from the truth.

The problem starts with the definition. SOAs are designed to decouple the implementation of a software service from the interface that calls that service. This allows clients of a service to rely on a consistent interface regardless of the implementation technology of the service. Instead of building big, monolithic applications, developers can build more agile services that can be deployed and reused across an organization for different applications and processes. This allows for better reuse of software functionality, as well as for increased flexibility because developers can evolve the implementation of a service without necessarily affecting the clients of that service.

To this end, the main requirement of an SOA is that the interface to the services is decoupled from the implementation. When you hear this description it might remind you of another technology that is discussed a lot: Web services. Web services allows access to a diverse set of functionality through a standard protocol-and-interface definition. Web services and service-oriented sound like the same thing, but they're not.

SOAs and Web Services
Today's examples of SOAs are mainly in the business process area. These applications are focused on building business process flows where several services are used in conjunction to accomplish a larger task. These processes also require data transformation as different types of data are taken from one service and sent to another service in the flow. In this example, Web services are often used as the services in the process. Web services provide a good mechanism to communicate with a diverse set of technologies that would be much harder to integrate without them; however, a problem arises when a developer needs to add a non–Web service service to a business process that also contains Web services. To handle this case, either the client has to code to multiple interfaces, or the developer needs to add an abstraction layer that shelters the client from the differences in the service interfaces and implementations. This abstraction layer is known as a service-oriented interface (SOI). In the case where all of the services in the process are Web services, the Web service interface is the service-oriented interface.

Web services are one example of an SOI. The problem with using Web services exclusively in a service-oriented architecture is that developers have to wrap any functionality they want to expose as a Web service. This makes sense in cases where the service is built using a foreign technology or is supplied by a different vendor, but ideally you would try to avoid the overhead of packing and unpacking data into XML for services running on the same infrastructure. However, because Web services are one of the few standardized examples of an SOI, they are often assumed to be the only choice when building an SOA.

Beyond Web Services
A non–Web service example of an SOI can be found in the Java Specification Request (JSR) 227. JSR 227 is a standard data-binding and data-access facility for J2EE. The goal of JSR 227 is to abstract the implementation of a data source from a client looking to take that data and bind it to a user interface. Whether you're displaying data from a database, Enterprise JavaBean (EJB), legacy system, Web service, or plain old Java object, the interfaces and data are the same.

This is shown in the "Model Layer" in Figure 1. By providing a consistent interface to any business service, the model layer is implementing an SOI. The functionality provided in any SOI really comes down to the required information. For example, the model layer in Figure 1 doesn't necessarily have to provide full access to all features and functionality of the business service that it represents. Instead it just needs to provide enough functionality for clients to successfully bind that data into user interfaces and then manipulate it.

Inside an SOA
Taking a closer look at how this is done leads us to the DataControl. The job of the DataControl in the model layer is to abstract the implementation of the business service from the client, as well as to act as a mediator between the client and that business service. The DataControl API describes certain functionality of the business service that the developer wants to expose. For all of this to work, the DataControl needs to expose this information in an implementation-neutral manner. Regardless of the implementation of the business service, the description is the same.

It's worth highlighting why a DataControl was chosen over a Web service as the interface for the data- binding SOI. Using an SOI that is focused on a specific job dramatically increases its viability, performance, and acceptance. For example, while Web services typically run on the server, the DataControl runs on the client because that's where the data will be displayed and changed. The DataControl can also represent multiple kinds of services and does not need to package the data as XML in order to send it to the client, as it's already running on the client. Also, while a Web service is designed for calling operations on services, the DataControl can also access attributes, which is a very common way to display data in a user interface. Trying either to change the data-binding architecture or bend Web services in order for them to meet the requirements of the data-binding SOI would have been the wrong decision. Using an SOI that's designed for a specific task allows developers to get the advantages of an SOA without having to sacrifice the design, performance, or ease-of-use to get there.

Let's get back to the DataControl. The DataControl is able to abstract the implementation of the business service by breaking things down into a common form. In this case, that common form is a set of attributes and operations. Any business service has zero or more attributes and operations. Attributes are simple setXX and getXX methods that conform to the standard JavaBean pattern. An operation can be any other method on the business service and can take parameters and return values. The DataControl also describes the data that is returned from an attribute or operation. This description is represented as generic objects with typed attributes. Attributes can be primitives or other objects. This allows for complex data models to be described regardless of where the data comes from.

How It Works
The DataControl processes requests from the client and maps them into the implementation-specific data that it retrieves from the business service. By getting the description of the attributes, operations, and data in a common metadata format, the client no longer cares about the implementation details. The DataControl becomes the contract between the business service and the user interface (client), and the developer has the freedom to change and modify the business service as necessary without having to break the contract.

Figure 2 shows an example of this SOA using an EJB business service. The DataControl sits on the client and communicates with the application server as any EJB client does. When the UI client calls an operation on the DataControl, the DataControl in turn calls the Java Naming and Directory Interface (JNDI) to access the EJB, makes the method call on that EJB, and gets back data transfer objects. The DataControl then passes back a collection of maps describing these objects to the UI client. The UI client can then make get() calls on any of the maps to access the different attributes of the data objects. The get() method of the map delegates to the DataControl, which in turn responds with the actual data from the EJBs. The same is true when the UI client updates the data using the set() method of the map.

Since the DataControl is running on the client, there's no need to repackage the data into XML or JavaBeans. It's all handled in the delegated get() and set() methods of the map right on the client.

What's in It for Me?
The DataControl is completely in charge of how the data is cached, loaded, and managed. That functionality is sheltered from the client because of the SOI. This allows developers to optimize and tweak the implementation of their business service or extend the functionality of the DataControl without affecting the client. For example, we could modify the application described by Figure 2 and add client-side caching. In this case, we would extend the DataControl to cache the data on the client, saving trips to the server for each call. The server would then notify the DataControl when the data is invalidated, causing it to make subsequent calls to the server to refresh its cache. All of this can be done without any affect on, or knowledge of, the clients (other than that they will all start running faster!).

In addition to this improved flexibility in your applications, SOAs are also designed to promote better reuse. Once you've started to provide a set of services for your business, creating new applications or business processes becomes much easier. Simply build on what you have while adding any additional services as you go. This allows organizations to move away from making big version changes to an entire application and instead promote a series of continuous, small changes to the different services, processes, and clients in their environments. This adds a significantly higher level of maintainability to any application.

Finally, let's not forget performance, scalability, and manageability. Companies like Oracle, IBM, and Intel are moving toward grid computing solutions. "The Grid," as it is known at Oracle, is a runtime architecture that's designed to intelligently manage all tiers of all your distributed applications from one unified location. The grid ensures that the right applications get the right resources and computing power at the right time. And while any J2EE application can run on the grid, companies can really increase the benefits they get from the grid by having a supply of reusable business services that are deployed and managed using a variety of different grid policies. As you might have guessed, this is a perfect job for an SOA.

Take another look at service-oriented architectures and decide which are the best service-oriented interfaces for your requirements. By implementing an SOA, companies can gain many benefits over traditional application architectures, regardless of whether or not they have committed to Web services technologies. Developers can start utilizing SOAs today and get increased flexibility and better control over their applications, while at the same time aligning themselves with technologies such as Web services and grid computing to gain added advantages in the future.