Marcia L. Stockton

Service-oriented architecture: programming model and product architecture

IBM products increasingly implement a service-oriented architecture (SOA), in which programmers build services, use services, and develop solutions that aggregate services. IBM Software Group middleware products and tools support the development and deployment of SOA solutions, and increasingly make functional interfaces between components and products visible through a service model. Software Group components will increasingly use SOA standards for intracomponent communications. Our move to SOA encompasses both the programming model and lower-level infrastructure software, for example, systems-management and storage-management application programming interfaces and functions. This paper concisely defines the IBM SOA programming model and the product architecture that supports it. We provide the motivation for our programming-model and design decisions. This paper also focuses on the architectural concepts that underlie our programming model and product architecture.

Toward a programming model for service-oriented computing

The service oriented paradigm is, at its core, a model of distributed software components, built around the idea of multi-protocol interoperability and standardized component contracts. The Web Services Interoperability (WS-I) profiles provide standards for runtime interoperability, and the Web Services Description Language (WSDL) and WS-Policy define service contracts that support interoperability between developer tools. A major goal of Service Oriented Architectures (SOAs) is to enable an abstraction layer that integrates and bridges over platform and implementation technology differences, effectively providing a universal business software component and integration framework. Achieving a complete solution requires a portable component model and well-defined patterns for components types. This paper examines the main requirements for a SOA programming model and identifies its most relevant characteristics. In line with SOA’s goals, such model must allow a broad community of users (including non-programmers) to create service-oriented applications by instantiating, using, assembling and customizing different component types that match the user’s goals, skills, and conceptual framework. Moreover, these component types must be portable and interoperable between multiple different vendors’ runtimes.

Enterprise business process management: architecture, technology and standards

All enterprises’ operations require integrating information, and processing information with applications. This has been true for decades, if not centuries. Information and application integration has evolved from completely person centered verbal communication (blacksmith to apprentice), through paper documents-mail-fax, email and Web page interactions. The information and applications control the flow of goods and operations on them. These are the business processes of the economy. Coming from vastly different starting points, the evolutionary paths of business designs and IT architectures are converging, in a striking example of convergent evolution. In some cases, enterprises are almost purely information processing businesses, e.g. insurance. The past few years have seen explosive growth in direct program-program interaction for application integration, removing manual steps to yield tremendous improvements in reliability and efficiency. Controlling the sequence of program interactions and information flow, and knowing the status of the flows, are fundamental to an enterprise’s functions. Automating, monitoring and optimizing the flow is the field of business process management. The past two years have seen the emergence of several architectural and standards based innovations. This paper, with a focus on the end-to-end model, provides a technical overview of the standards, architecture, programming and runtime models that make modern BPM possible.