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. This paper provides an overview of IBM’s programming model and product architecture in support of service-oriented architecture (SOA). The profound implications of SOA and Web services for IBM products and programmers who use them are too sweeping for a single paper to cover in detail. Instead, this paper focuses on a broad overview of the concepts and architecture. We refer the reader to other sources, in this issue and elsewhere,
The programming model concept A programming model defines the concepts and abstractions that developers build and use. In this paper, we use the terms developer and programmer loosely. A key element of our SOA programming model and supporting development tools is to enable nontraditional roles to implement services and assemble solutions by using services. A business analyst defining business processes and a marketing specialist defining policies that classify customers and compute product discounts illustrate what we mean by role.

Although there is no generally accepted definition for a programming model, for the purposes of this paper we define it to be a set of part types that programmers build and a set of roles grouping members of the development and administrative community who have similar skills and knowledge. Part types encompass the diversity of programming model artifacts: Hypertext Markup Language (HTML) files, database stored procedures, Java** classes, XML (Extensible Markup Language) Schema definitions, C structs (C programming language syntax for defining data structures) defining MQSeries* messages, and so forth. Categorizing developers by role helps us produce role-appropriate tools that enable nonprogrammers to implement services and assemble solutions from services. This enables the participation of new kinds of developers, such as a business analyst defining business processes and a marketing specialist defining policies that classify customers and compute product discounts. For each role, a set of skills is defined, for example, a user interface developer develops interfaces presenting the functional artifacts of the application or solution. This role is assumed to know the application under development and its business goals, to understand the application’s users and their tasks, to be an expert in several user-interface design methods, and to create easy-to-use user interfaces by choosing the right kind for each task. Each role is associated with part types and application interfaces with which the role interacts (consumes or produces). For example, those in the role of designers of dynamic pages produce the part type JavaServer Pages** (JSPs**) and consume the part type JavaBeans**. These part types wrap existing sources of information and applications. Each role is also associated with the tools that the role uses; for example, a role-appropriate tool for a Web developer is a ‘‘what-you-see-is-what-you-get’’ page design tool for building dynamic pages, using controls associated with HTML and JSP tag libraries, and wiring the controls to JavaBeans. This paper focuses primarily on the part types comprising the SOA programming model. Incremental extension of a person’s existing skills and knowledge is the key to making Web services easy to implement and use. A service in the form of CICS COBOL transaction programs bears little resemblance to one written in the Business Process Execution Language for Web Services (BPEL4WS or BPEL, for short).

Calling a service from a database stored procedure differs from calling it from a JSP; the skills and expectations are different. We offer an assortment of tools to adapt the part types to various skills and to the stages of the development process. Product architecture Products supporting IBM’s service-oriented architecture fall into two broad categories: service endpoints and the message transport fabric interconnecting them. This general architecture, populated by many products, which jointly constitute the delivery vehicle for IBM’s SOA, is illustrated in At the core is an Enterprise Service Bus (ESB) supplying connectivity among services. The ESB is a multiprotocol bus and supports ‘‘point-to-point’’ and ‘‘publish/subscribe’’-style communication, as well as mediation services that process messages in flight. IBM WebSphere MQ, WebSphere MQ Integrator Broker, and WebSphere’s support for Web services and Java Message Services (JMS)

Free download research paper