Service oriented architecture

From Hill2dot0
(Redirected from SOA)
Jump to: navigation, search

Any discussion of service oriented architectures (SOA) must begin with a definition of the word “service.” Any new trend in computing and software development seems to start with a period of fuzzy terminology, and when it comes to SOAs, we are definitely in that period.

Roger Sessions, CEO of ObjectWatch, offered one useful way to think about services. He suggests they are best understood by comparing them to other software constructs that preceded them: objects and components. A couple of decades ago, the software industry embraced the concept of object-oriented programming (OOP). An object was defined as a reusable piece of a program that could be called on to do its job from any number of contexts. Programming became very modular and much more efficient. OOP is used to this day. We see this construct every time we install a new program under MS Windows and we see the files that get installed with a “.dll” extension. That extension stands for Dynamic Link Library (DLL). These are fragments of code that do specific tasks, but they are only loaded and linked into a program when the program calls for that function. Furthermore, multiple programs can call upon and use the same DLL file, which makes the process of unloading programs a bit more complex. Objects, however, always run on the same computer under the local operating system process.

The concept of a “component” extended that basic idea to permit an object to be reused by other processes and even on other machines, but still within the same development environment (e.g., IBM’s WebSphere or Microsoft’s .NET.)

The concept of “services” takes the component model and frees it from a particular development environment boundary. It opens the door to any application on any system anywhere in the network providing services to any other application on any system anywhere in the network, even when that crosses environmental boundaries.

Services are not merely fragments of code, however. They are actually software representations of business assets that can be made available, and ultimately monetized.

An SOA, then, is an architectural approach to building applications based on services. These services are primarily business-oriented or business-related. The services are described using a standards-based service description language. Services are accessed and communicated with using a standard network-based protocol. Services are specifically designed to be autonomous and implementation-independent. They are said to be “loosely coupled” which is what makes it possible to flexibly bring them together in composite solutions to complex business problems. Services are reusable and shared in that the same service can be called on by different applications to solve different business problems at different times.

SOA is a concept–an idea, a discipline–and it is not a particularly new one. It is not a technology, but the idea can be realized using a collection of technologies. SOA is an idea about how we use computing technologies and bring them together to solve business problems. And that makes SOA an important part of the emerging strategic focus of IT organizations.

Benefits of an SOA

The benefits of using a SOA as an IT strategy are listed below.

  • Reduced time to market (TTM) for new applications: New applications can be developed and launched more quickly when they are assembled from existing services. Consider the automotive assembly line. The line would move a lot slower and be a lot longer if every single piece of the car was being assembled on the line. But that is not the case. Many elements (e.g., engines, seats, doors) are assembled elsewhere and beforehand. These pre-developed elements are then simply assembled to make a new product: a car. For this benefit of an SOA to be realized, however, a well-defined business process model needs to be followed, and services need to be planned within that framework.
  • Flexibility for evolving applications: Many companies have a large pool of legacy applications. Once these applications have been folded into an SOA, and become services in the overall model, the details of the legacy applications become invisible to the users of the application and the programmers who are basing other services or applications on that legacy base. In the future, the legacy application sitting beneath the service can be retired in favor of a newer implementation with no impact to the users or to the developers of other services. That translates to enormous flexibility for evolving the software infrastructure.
  • Reduced IT TCO: That this is true can be seen from the previous benefits: reduced TTM and evolution flexibility. In business, time is money. The longer it takes to build a new application, the more the application ultimately costs. And visibility means training. The more the change of an underlying technology affects the end-users (who now need to be trained and will often see a drop in productivity as they learn the new system) and other programmers (who may need to change their programs to factor in the changed software), the more the cost rises.
  • Reduced time to ROI: Monolithic legacy applications tend to have a serious ROI-related consequence: benefits are not realized until the entire application is implemented. An SOA approach has a different model. As the individual services that make up the application come online, they can provide immediate benefit. This requires services to be part of a well defined overall architecture that emphasizes re-use.
  • Power through aggregation: One of the very real strengths of an SOA is the way that services can be built one on top of another. It is not merely a case of a base set of services being designed that can be combined in different ways to create different applications. The services themselves can be combined to create new services, making the base services even more valuable.

Web Services and SOA

Web Services and SOA

While SOA is not a new concept, the pervasiveness of IP has given new impetus to a very specific SOA known as Web Services. In a nutshell, Web Services is shorthand for an open, IP-based, and Web-based SOA. Web services combines three integration models: information-oriented, portal-oriented, and service-oriented. Web Services requires the definition of a common information structure (i.e., XML), can support a portal-based access into legacy systems, and suggests an overall services-based architecture. Web Services comprises the set of standards below.

  • Extensible Markup Language (XML): Web pages are a combination of text to be displayed and codes (called a “markup language”) that describe how to display the items on the page. For example, wrapping text between the code and the code means “display this text in bold.” So the text, “I really like banana” will display it as “I really like bananas.” The code used on most Web page is called the HyperText Markup Language (HTML). XML is effectively the grandparent of all markup languages. It is highly flexible, and defines mechanisms for extending the markup language by creating new commands “on the fly.”
  • Web Services Description Language (WSDL): If applications are to harness network services, they need to know three things: where those services are located, what the services do, and how those services are communicated with. WSDL is XML-based and provides the complete description of each of these elements for a particular service. These specifications can be maintained in a centralized or distributed registry that applications can access to discover available services in the network.
  • Simple Object Access Protocol (SOAP): SOAP provides a standard messaging structure between applications. Like WSDL, it is XML-based. However, SOAP is focused on providing a flexible, but standards-based framework for data exchange between services or between applications and their constituent services.
  • HyperText Transfer Protocol (HTTP): HTTP is the basic communication protocol of the World Wide Web (WWW). HTTP is a well known and well established protocol supported by every browser in existence. HTTP is also very firewall friendly.

All of this rides on top of the existing network protocols of the Internet: TCP/IP. This has become the dominant protocol suite in use today. As a result, Web Services can be accessed across the corporate network (assuming it is IP-based), but may also be accessible across the public Internet.

The registry model is an effective way to find services in a network. With a simple change in the registry, services can be relocated as necessary without confusing the applications that depend on them. If such a construct is to be used out in the public Internet, a standard registry needs to be created. This is the role of the Universal Description, Discovery, and Integration (UDDI). UDDI is an open industry initiative that makes it possible for businesses to publish their Internet-based services and find other services. The effort is sponsored by the Organization for the Advancement of Structured Information Standards (OASIS).

UDDI is a way to discover Uniform Resource Identifiers (URI). URI is an umbrella term that refers to any structured representation of a particular resource. International standard book numbers (ISBN) numbers are a specific example of a URI, one that tells you what the resource is without telling you where to get it. These are known as uniform resource names (URN). Another form of URI is the Uniform (or Universal) Resource Locator (URL). This provides not only information about the nature of the resource, but also its location, how to communicate with it, and possibly some data for the exchange.