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.
Q: What is the relationship between SOA and Web services; SOA and grid computing?
A: SOA is an architectural design style for business application systems, but it can be applied to other systems, including middleware technologies like grid computing.
Web Services is a set of standards that can be used to create a Service Oriented Architecture. While is possible to create SOA without the Web Services standards (for example, people have used XML over HTTP or JMS to achieve a similar result, before the SOAP standard), for interoperability with external software the use of Web Services standards is the best approach we have today.
Grid Computing is a system management strategy whose goal is to maximize the use of hardware resources. For example, when unexpected demand floods the designated server, it could be possible to direct some of the requests to a less busy server on a temporary basis. Grid computing is designed as a Service Oriented Architecture; in particular the services used to coordinate Grid Computing are called Grid Services.
As we move forward with SOA, we will see this approach used to support a variety of other new systems features. Autonomic computing, or self-managing systems, is another example. In fact SOA is the basis for advanced capabilities in Web Services, such as the WS-Trust and Federated Identity Management specifications.
Q: Isn’t the biggest problem of SOAs still vendor-centricity since there are no universal interoperability standards yet?
A: The basic standards are in place for Web Services, and these can be used to implement a service-oriented architecture. XML and XML Schema have been standards since 1998 and 2001, respectively. SOAP 1.2 has been a standard since June 2003. UDDI was standardized in summer 2003. WS-Security became a standard in April 2004.
Aside from these official standards supported by well-known standards bodies such as W3C and OASIS, many “technology proposal specifications” are well accepted and well supported as interim “de facto” standards. For example, until WSDL 2.0 is finished at W3C, the WSDL 1.1 specification is supported by most vendors who claim Web Services support in their products.
Indeed the support we have today for Web Services standards from major software vendors has lead to widespread implementation of SOA using Web Services. IBM has several hundred customers who have successfully completed prototypes or have Web Services in production already.
Q: How do SOAs impact SLAs? And how do you adapt SLAs to your SOA?
A: Today’s SOA implementations between companies typically focus on improving efficiency of existing business between partners. As such the notion of performance guarantees is not as much of an issue as easy interoperability and loosely-coupled integration, which can be achieved with Web Services standards.
A guarantee of a particular level performance or availability, and other quality of service considerations, comes into play more when service use becomes a product that companies pay for. We can imagine this becoming a common requirement in the future, and work is underway to support this model.
Q: How does one get started on building a SOA?
A: The best approach is to start small, focusing on improving on an interaction that is currently inefficient. For example, consider two computer systems which are tied together using a printed report from one which needs to be re-keyed into the other, which takes time, costs money, and leads to errors and data not being optimally up-to-date. A simple SOA project based on Web Services could be designed to directly link the information, sending a SOAP message with updates to the partner system, instead of printing a report. Starting simple allows companies to measure ROI before making a large commitment, and gain experience with small improvements before taking on larger problems.
CIOs should ask vendors about their support for Web Services and SOA as a key consideration in purchasing new software. New application development should be reviewed to consider whether certain application functions are likely to be required for other purposes, and support for Web Service standards could be built in to allow reuse.
Eventually, to accomplish large-scale enterprise transformation, it may make sense to begin such work by establishing an Enterprise Service Bus, which forms the backbone or nervous system of the SOA. Service providers and service requesters can then be incrementally added to the ESBs at a pace that makes sense for the organization. As the SOA for IT grows, the ESB becomes a powerful way of joining applications at the service level, and mediating message traffic for efficiency and reliability.
Q: What new service management is needed to manage a SOA?
A: Business partner integration prior to the use of Web Services has been severely limited by the lack of standards and a loose-coupling strategy. As we begin to use Web Services and SOA for partner integration, we can see that our IT systems, in using functions from our business partners, have become depending on the availability of these functions. We move from managing the availability of our own services internally to the requirement for monitoring and managing availability between organizations, potentially a large number of them. This clearly adds considerable complexity to the management of IT systems, but it also delivers tremendous value, which is why many of our customers want to move in this direction.
Web application systems, such as IBM’s Tivoli product line, are evolving to support the Web Services standards. A new standard called “Web Services Distributed Management”, or WSDM, is being developed at OASIS, to provide standardized support for management of Web Services, using Web Services to allow management of diverse platforms, to address the requirements for distributed management of large-scale SOA involving independent business entities.