Architecture & DesignService-Oriented Architecture Introduction, Part 1

Service-Oriented Architecture Introduction, Part 1

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

With the introduction of Web Services over the last year or so, there has been a renewed interest in service-oriented architecture (SOA). An SOA is an architecture that has special properties. It is an architecture made up of components and interconnections that stress interoperability and location transparency. The term service has been used for more than
two decades. For example, leading transaction monitoring software has used the term "service" in the early 1990s. Many client-server development efforts in the 90s used the term "service" to indicate the ability to make a remote method call. Web Services has given the term service more prominence in the last few
months. Services and service-oriented architectures are really about designing and building systems using heterogeneous network addressable software components. In this article, I will explore the evolution of SOA, make a case for SOA, and describe some of the properties of SOA.

Software Architecture in General

Before getting too far into the details of SOA, the term software architecture needs to be defined. Software architecture is a fairly new practice in the field of software engineering. The software architecture of a system consists of the large-grained structures of the software. It describes the components of the system and how those components interact at a high level. The interactions between components are called connectors. The
configuration of components and connectors provide both a structural and a
behavioral view of the system.

Brief History of Software Design

Over the last four decades, the practice of software development has gone through several different development methods. Each method shift was made in part to deal with greater levels of software complexity. The way we have managed complexity is to
continuously invent coarser grained constructs, such as functions, classes, and
components. We can think of these constructs as software “black boxes”.

A software black box hides its implementation by providing controlled access to its behavior and data through an interface. Think of it as a software
integrated circuit. At a fine level of granularity, we use objects to hide behavior and data. At a coarser level of granularity, we use components to do the same. Having
information hiding only at the object level works well for small systems, and
it allows us to create constructs in software that map onto the real world objects.

A problem arises when we try to group a large number of objects together.
Although access to the objects is controlled through their interfaces,
the granularity at the object level still makes dependencies between them
difficult to control in a large system.

Introducing the component concept gives us a better way of managing these dependencies in large systems. A component is a smaller group
of objects working together to provide a system function. For example, a claim, automobile and a claimant object can work together in a claims component to provide the claim function for a large insurance application.
The claim component becomes another black box at the level of a large
system function. The claim and automobile objects are not known to any other part of the system, except for the claim component. This means that no
other part of the system can become dependent on these objects since they are
completely hidden.

This is the point we are at today in software development.
Technologies such as Enterprise Java Beans, .NET and CORBA are effective
ways of implementing components. The method of component-based development has allowed developers to create more complex, higher quality systems faster than ever before because we have a better way of managing complexities and dependencies within a software system.

The Case for Service-Oriented Architecture

So are we done? In software engineering — of course not! Now that we have developed all of these heterogeneous components for one system or another, we need to be able to use them together. But there is a problem: developers built some components using EJB, some CORBA, and many of the resources we need for our systems are on mainframe computers running COBOL. Using Enterprise Java Beans requires that method invocation be done via RMI. CORBA uses IIOP. And many times the component is located across the Internet, behind a firewall and the message cannot get through. Although each has tried to be interoperable with the other, small inconsistencies cause developers a lot of pain when trying to figure it all out.

In addition, even if we did not have these problems, the components still have to know too much about each other. For example, if I want to use a Claims
component, I have to know not only what transport and payload type to use, I
also need to know exactly where it is. I also need to have intimate knowledge about its interface so that if the interface changes, I have to change the way I call it. Since these components have network addressable interfaces and the number of clients can be large, this creates dependencies on an enormous scale. So how do we solve this problem?

The Service-Oriented Approach

A service is behavior that is provided by a component for use by any other component based only on the interface contract. A service has a network-addressable interface. A
service stresses interoperability and a service may be dynamically discovered and used.

Web Services consist of four technologies in combination that provide an implementation of an SOA. You can use Web Services to provide all of
the properties necessary to build a service. Web Services include HTTP as the primary network protocol, SOAP/XML for the payload format, UDDI for service registry, and WSDL to describe the service interfaces.

However, a service-oriented architecture does not require Web Services.
An SOA is a design and a way of thinking about building software components.

Use-Based Solely Published Contract

Contract design between components is a critical activity in a service-oriented architecture. The difference between a public interface and a published interface comes into play. A public interface is an interface that can be used by components within
a system. The public interfaces of a component are easier to change, because they are only used by known clients. A published interface is one that is exposed to the network and may not be changed so easily, because the clients of the published interface are not known. The difference is analogous to an intranet-based site only accessible by employees of the company and an Internet site accessible by anyone. Languages and tools have not stepped up yet to enforcing this concept, but it is important to understand the distinction when building published service interfaces.

Network Addressable Interface

A service must have a network addressable interface. This means that a client on a network must be able to invoke a service. A service may be configured for use by a
component in the same machine. However, the service must also support a network configuration.

Stresses Interoperability

A service-oriented architecture, first and foremost, stresses interoperability. That means that each component must provide an interface that can be invoked through a payload format and protocol that is understood by all of the potential clients of the service.

Dynamically Discovered and Used

A service must be dynamically discovered. This means that a third party mechanism must be used to find the service. Hard coding of a machine location is not consistent with a service-oriented approach.

Conclusion

There are a lot of benefits to using a service-oriented architecture approach, but there are also some risks involved. In future installments, I will discuss these and more.

References

  1. L. Bass et al., “Software Architecture in Practice,” Addison-Wesley, 1998
  2. M. Fowler, "Public versus Published Interfaces," IEEE
    Software,
    Vol. 19, No. 2, March/April 2002, pp. 18-19.

About the Author

Michael Stevens is an independent consultant specializing in service-oriented architectures for the enterprise. He has over fourteen years of experience in information technology architecting and developing software systems, most recently focusing on J2EE solutions. He founded a software company that developed solutions for the mailing industry. He is a certified Java programmer, a member of the IEEE Computer Society, and of the ACM. He may be reached at mike@mestevens.com.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories