February 28, 2021
Hot Topics:

Q&A with Mark Colan Evangelist, SOA and Web Services: IBM Corporation

  • By Developer.com Staff
  • Send Email »
  • More Articles »

Q: The premise of a SOA is being able to have your applications work like services. Describe how software would work as a service.

A: Without SOA, software packages are written to be self-contained, with many application functions tied together in a complete package. The code to accomplish integration of application functions is often mixed into the code for the functions themselves. We call this approach to software design "monolithic applications". It is tightly-coupled, in the sense that changes to one part of the code will have a big impact on code that uses it, and this leads to complexity of systems and expense in maintaining them. It also makes it difficult to re-use application functions, because they are not packaged for reuse.

SOA seeks to separate individual application functions from each other so that they can be used separately, as individual application functions or "building blocks". These building blocks can be used to create a variety of other applications inside the enterprise, or if desired, exposed externally for business partners to use in their applications.

The notion of a "service" is to construct these "building blocks" with standardized interfaces that are independent of the implementation details. The Web Services Description Language document for a set of application services describes the names and types of data that need to be passed as inputs to request a particular service (for example, a "check inventory" function may require a part number) and the details of the response from the service (it may return an integer representing number of units in stock). These details would appear to be the same whether the function is implemented in Java, C++, COBOL, etc, so the requester of the service does not need to know which language was used, and the requester can be written in any required language. This allows services from one platform to be integrated in an application written for another platform. The key to interoperability is the request and response message, for example using SOAP messaging where messages are coded in XML.

Q: Give an example of how an SOA works to benefit an enterprise.

A: A key benefit is interoperability, which is the ability to use the functions between any kinds of platform, regardless of programming language, operating system, computer type, etc.

In the example above, the "check inventory" function may have been written as a service that was required for one application, for example one that monitors inventory and automatically reorders when required, but we could find later that the same service can be used without modifications to support a Web-based inventory monitoring tool used by a human clerk.

Internally, the reuse of application functions is a key benefit, because it leads to reduced development costs. A long-term implication of reuse of services is the reduction of redundant functions in the enterprise, a simplification of the infrastructure, and thus a lower cost of maintaining code. By organizing applications as users of services, we get a much more flexible and agile model of integration, allowing us to quickly revise the business process model, compared to traditional programming techniques.

Externally, the well-defined "contract" for interacting with a service leads to a "loosely-coupled" style of interaction between business partners that provides the required stability of integration, and a solution to the problem of changes to underlying software. When the message format stays the same, the software that supports it can change as much as required, so long as it still supports the message contract. The system could even be completely replaced with an implementation in another programming language; so long as it supports the same message format, the requester application would not require changes. When message contracts evolve and must change, it is easier to support multiple versions of application requests as a transitional strategy using versioning, compared to the rather difficult task of supporting multiple versions of program APIs and file formats.

Page 1 of 3

This article was originally published on August 3, 2004

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date