Beginning SOA Using BEA WebLogic Workshop
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Isn't service-oriented architecture (SOA) just another buzzword in an infinite stream of buzzwords? Roughly defined, SOA is using proper design to develop a system composed of a number of potentially-independent distributed subsystems, some using services provided by others. Sound familiar? Think components written with RPC, EDI, Corba, DCOM, RMI, and, more recently, SOAP and web services (to name a few). For example, the 25-year-old EDI-based reservation systems of partner airline companies are a bit like a SOA, aren't they? The technologies to develop SOA systems aren't new at all. What are relatively new are the term itself and modern design patterns that surround it.
This article discusses SOA and provides an example of an SOA system using the BEA WebLogic Workshop development environment.
SOA Principles
The most basic SOA architecture would look somewhat like Figure 1.
)
Figure
1 Basic SOA architecture.
Most SOA systems have many users and providers. Certain users also act as providers to other users. Most SOA systems are much more complex than the one in Figure 1, but they all follow the same basic principles:
Proper design. Experience, application of the right design pattern for the right context, and careful planning are the major tools to help you in this area.
Autonomy. Each service has the potential to be used individually.
Simple, well-documented interface. This principle matches the concept of a component, except that components can also be running inside a single application or can have a visual interface. Services are more specific, as they're meant to be distributed and typically don't have visual interfaces.
Flexibility. The definition of the service must meet the system's requirements while being flexible enough to accept unusual requests. Not all users will use the service in the same way; thus, the service should adapt to accommodate the user's needs. Similarly, through the course of its life, the service will offer more features or changes in its interface. Users shouldn't have to make any changes in order to access the service. For a service to succeed, it must be carefully architected and designed by someone who knows the specifics and direction of the business.
Unity. The services must work together to provide aggregated or assorted services, as if the user were dealing with a single service. Having one interface for ordering and a completely different one for payment is confusing.
A good example of SOA is a business-to-business (B2B) electronic marketplace application, in which many companies provide similar services to many other companies. Another example would be a service aggregator, in which a single company provides a single façade to many other companies' services, simplifying its customers' lives. A bad example of an SOA might be an airline that can't access its partner company's customer reservation system. In this system, you can't confirm or change your reservation at a foreign airport. I know; I've seen it.
There is no single prescribed technology for developing an SOA system. But with the advent of web services, new SOA systems are usually implemented using SOAP for the sake of platform independence, interoperability, loose coupling, and so on.