Service-oriented architecture: Realizing tangible benefit from SOA in the near term

This tip is an excerpt. Click here to download the full white paper.

Introduction

While the purpose of this paper is to help demystify the concept of service-oriented architecture (SOA) and the technology that supports this architectural approach, it also provides a starting point for organizations to realize tangible value in the short term from their investment. In doing so, this paper addresses the following questions: What exactly is a loosely coupled process? A composite application? What are you supposed to make of the alphabet soup that describes the standards involved in enabling services as reusable process components, or Web services as a communication protocol? What is a service really? In other words, what is a loosely coupled, reusable, composable, published, discoverable and transport-protocol-independent "thing" that allows organizations to react rapidly to changes in market conditions?

Technology, definitions and vision

In the interest of achieving a common level of understanding, we will briefly review a few definitions and introduce the technology that makes SOA feasible. We'll begin by defining a "service" and illustrate a few examples of "real services" as applied within an enterprise relationship planning (ERP) software suite.

A service is a component of an automated subprocess representing a unit of work (e.g., "Get Customer Record") performed as part of a business function, such as verifying customer contact information or validating recent customer purchasing activity.

The idea is to design services so that they not only function within your ERP system, but also serve as cross-platform and cross-organizational components. The service "Find Recent Customer Activity" might very well execute across your sales order management application, order processing and sales forecasting, but would also look at your customer relationship management (CRM) solution for customer activity, and perhaps your call center software and issue tracking applications. This information would be displayed on a browser at your desktop computer or on a PDA from the field just before you go into the customer's office for a meeting. From a cross-organizational perspective, the very same service "Find Recent Customer Activity" might be re-utilized by your vendors and service providers to discover the purchasing activity of your organization, or to check the status of an outstanding purchase order they have with your accounts payable group.

Service-oriented architecture (SOA) represents the "big picture" view as to how business and technology architectures can be integrated, and how composite application functionality is delivered to a portal or Web browser. SOA enables end-to-end application integration across the enterprise and among business partners, providing a flexible model permitting the enterprise to respond to market changes quickly and efficiently. It is a concept that has evolved from enterprise application integration (EAI), allowing us to more easily and effectively integrate data and applications across the value chain. It constructs applications from the ground up, taking one or more services like those described above and connecting them to form a complete, cross-functional, end-to-end business process such as "procure-to-pay" or "quote-to-cash." This is fundamentally different from today's packaged applications, in that services are delivered in a much more granular structure (e.g., "Get Vendor Number") rather than the fully delivered process in today's electronic procurement module of an ERP system. This architectural style is dependent on the Internet, and is a combination of business architecture, application architecture and software architecture. This architectural style allows users to rapidly build, reuse and reconfigure automated workflow processes (services) as business priorities, regulatory requirements or market conditions change.

Composite applications, as mentioned above, are the desired end state of a full-scale SOA implementation. These virtual applications are a connected, process-based set of independent services existing inside or outside (i.e., service providers or outsourced functions) the enterprise. They are applied to a set of business requirements much like a custom software solution would be, except without the hard-coded integration logic.

SOA has at least three primary software components that are typically classified as middleware:

• Business process management (BPM) suite and Business Process Execution Language (BPEL) engine: The BPM software suite provides a unified process modeling environment for all aspects of your organization. It generates a graphical representation of how, and in what order, services and human workflow are executed as part of process activities. The BPEL engine is a tool that generates an XML file which tells the message router (service bus) the rules associated with each service. Using BPMS/BPEL, you will create and modify business processes on the fly using graphical tools such as the designer application from the BPM suite.
• Enterprise service bus (ESB): The ESB is a message router and rules engine that performs validations on messages, transformations on data and ensures message delivery from one system to the next, and eventually the delivery of information to your portal or browser. A message is simply the packet of data requested by any service.
• Service registry: A service registry is a repository, or library of sorts, for the descriptions of services available on your network or from other providers who have published services for public consumption on the Internet.

A number of standards make all of this possible. The following are just a few of those most commonly discussed, although there are hundreds published:

• Extensible markup language (XML): XML is a flexible format for defining information exchange between companies and computers. It is especially useful in the exchange of data via the internet, where there is no pre-defined interface.
• Simple Object Access Protocol (SOAP): SOAP is an XML-based messaging protocol that can be used with HTTP or Java Messaging Services (JMS). You'll recall from above that a message is a packet of data being exchanged between two or more systems. SOAP is one of the messaging standards that makes this data exchange possible.
• Web Services Description Language (WSDL): WSDL is an XML-based language that is used to define a wervice available on the network.
• Uniform Description, Discovery and Integration (UDDI): UDDI refers to the way services are accessed and integrated from within the service registry. An analogy could be drawn to the way the Dewey Decimal System allows you to locate a book in most any library in the world, or the way a taxonomy allows you to identify content on a Web site through directories.
• Business Process Management Notation (BPMN): BPMN is a modeling style by which processes are defined and documented. Often, the documented business logic can be generated into XML workflow by a BPEL engine, thereby defining logic and business rules within the enterprise service bus.

Understanding Web services, services and SOA

First, we draw a clear distinction between three terms that are commonly used interchangeably.

• The term Web services refers to several "platform-independent" communications protocols that use messaging (i.e., SOAP over HTTP or JMS) with XML to deliver data or functionality to a Web browser.
• A Web service, on the other hand, is a set of functionality (or mini-application) delivered to a Web browser using Web services. Common Web service applications include lightweight software solutions such as the stock ticker on Yahoo Finance, a shopping cart from Amazon or the localized weather report that you can select from the MSN Portal. Other Web service applets are utilized in Google Maps, eFax services, eBay's auction site, photo hosting sites and PayPal's payment processing services.
• A service, in the context of SOA, is a discrete function, or automated subprocess, that can be defined and applied to multiple enterprise software systems. Similar to Web service applications, services also utilize Web services (the communications protocol) to transmit data in XML format via messaging from application to application, or to your Web browser.

Service orientation takes these concepts a step further by allowing groups of services to be defined and maintained within a service registry. From there they can be exposed, located and invoked across enterprise systems and throughout the value chain as business requirements and priorities change. That is to say that certain services might be extended to your strategic partners, the same or other services extended to key suppliers and still others to your customers. Extrapolate this concept a little further and it becomes easy to imagine the Internet as a whole taking the place of today's local area network (LAN).

SOA allows a level of reporting and insight into business operations that we have not previously experienced, which is becoming essential in order to remain competitive as a business enterprise in an increasingly dynamic and regulated marketplace.

Click here to download the full white paper.

About the author

Jay Beecham's professional career encompasses architectural solutions design, process optimization, enterprise-wide system/application implementations and network/ communications infrastructure design for healthcare, insurance, retail, media, telecommunications and government entities in the U.S. and abroad. He has leveraged technology and process to facilitate cross-functional workflow enhancements, improve productivity and enhance reporting relevance while generating cost savings for clients. Mr. Beecham has extensive management-level experience with merger/acquisition integration, organizational restructuring, partner/alliance development, vendor management, IT/business alignment and staff development. He is currently serving as director of enterprise architecture services for CherryRoad Technologies.