Level: Intermediate Brent Carlson, WebSphere Business Components Architecture and Development, IBM
James Carey, WebSphere Business Components Architecture and Development, IBM
Pablo Irassar (pirassar@ca.ibm.com), WebSphere Business Components Architect, IBM Software Group
Paul Lee (paul@ca.ibm.com), I/T Architect, IBM Global Services
01 Oct 2000 Component-based architectures are currently thought of only within the context of a single application; in particular as a way of decomposing, functionally or structurally, an application into an assembly of decoupled components. As technologies and software engineering techniques have matured, these component-based systems can effectively be built today on well-defined technology bases such as EJB technologies and the J2EE APIs.
When component technologies are combined with Internet based technologies like XML, the highly distributed nature of the
Internet, and the standards being driven by industry groups wanting to more effectively communicate over the Internet, what results
is strong momentum towards connectivity across all boundaries and the definition of new system computation models -- like the one
presented by the Web services initiatives. Stepping back and looking at the big picture, we can see that the potential for an
overreaching end-to-end architecture definition for inter- and intra-enterprise software interoperability is tremendous. This article describes IBM_s component model for application construction in concert with IBM_s Web services initiative. It also describes the complementary nature of the component and services models. Component and services models can be viewed as two sides of the same coin, and we
present a preliminary analysis of these two initiatives, exploring the differences and similarities between these two models as
complementary elements of a complete architecture.
WebSphere Business Components
WebSphere Business Components (WSBC) combines two basic principles: the need for a software interoperability architecture
and the applicability of distributed OO technology to speed up development times in server-side applications for e-business. IBM WebSphere Business Components architecture and reusable components are a product of the evolution of extensive
Java technology-based development assets and products converging over a technical architecture based on open standards, XML, Java technologies, the
Enterprise JavaBeans technologies, and their respective programming model. Its strengths are a product of the combination of the
experience obtained on the development on some of the most extensive server oriented enterprise-wide Java technology-based applications
and IBM_s depth on enterprise wide software offerings. From a software interoperability architecture point of view, WebSphere Business Components provides an EJB technology-based and XML-based
component environment which allows disparate programming models to communicate using distributed black-box encapsulation,
ensuring a uniform technology framework that allows new and existing applications to work together seamlessly. Within this
programming model, WSBC recognizes the need for well-engineered and already developed sets of core e-business componentry
implemented on the EJB programming model, which was designed to help organizations develop e-business applications quickly. WebSphere Business Components_ component definition is summarized by the following description: "A component is defined as a coherent package of software implementation that:
- Performs a set of functions or services
- Can be independently developed, delivered and installed
- Has explicit and well specified interfaces for the services it provides
- Has explicit and well specified interfaces for services it expects
- Will only allow access to data and behavior through the interfaces it provides (is encapsulated)
- Separates its interface from the implementation used to support it
- Optionally, supports controlled customization"
Several points of the previous definition differentiate the WSBC component model from traditional object oriented concepts and
services and clearly define the concept of a "black box" encapsulation model. WSBC defines two basic component models: Advanced Components and Base Components. In a nutshell, an Advanced Component is a black box defined by its external appearance (the services it provides, the services it requires from other components and its customization points) independent from its technology. Technically, Advanced Components are encapsulated by EJB SessionBeans and present both method-based and XML-document based versions of their functional interfaces. An Advanced Component_s implementation may be based on Base Components, other Java programming techniques,
or alternative infrastructures. Base Components, on the other hand, are extensive sets of Business Objects, configurable business processes, and patterns
developed on the EJB programming model as combinations of EntityBeans and supporting Java classes, with ample cross-industry and industry-specific functionality.
Figure 1.
Any given enterprise application can be defined as a set of Advanced Components working collectively to provide a given functional element (for example, support a set of business processes). As applications and application topologies evolve, the technology independent nature of the Advanced Component composition model allows enterprise systems to evolve in independent functional
units as components are integrated into the particular installation. Advanced Components, their definition, implementation and deployment
Installed Advanced Components are fully described by the combination of three XML Schema instantiations that correspond to
the different aspects of a component: its interface definition, component implementation, and component deployment. First, the
'definition' of a component describes its interfaces, external data representation, and dependencies that the component has with
other advanced components in a system. A second XML document describes the implementation bindings each element of the
definition has with a particular implementation. Finally, an Advanced Component deployment descriptor describes the required
instantiation and registration elements that must be present in a component to effectively target and utilize components in a deployed
system. These schema definitions ensure that individual Advanced Component definitions and implementations are managed and versioned
independently to ensure full replaceability and optimization of implementations to their target environments.
Listing 1. Excerpt of the AC definition schema
<xsd:schema xmlns:xsd="http://www.w3.org/1999/XMLSchema">
...
<xsd:element name="AdvancedComponent" type="ACDefinition"/>
...
<!-- Advanced Component Definition -->
<xsd:complexType name="ACDefinition">
<xsd:element name="name" type="xsd:string" minOccurs="1" maxOccurs="1"/>
<xsd:element name="specVersion" type="xsd:string" ... />
<xsd:element name="interface" type="ACInterface" minOccurs="1" .../>
<xsd:element name="functionGroup" type="ACFunctionGroup" ... />
<xsd:element name="dependency" type="ACDependency" ... maxOccurs="unbounded"/>
<xsd:element name="prerequisite" type="ACPrerequisite" ... maxOccurs="unbounded"/>
<xsd:element name="comments" type="xsd:string" .../>
</xsd:complexType>
...
<xsd:complexType name="ACFunction" base="ACInterface" derivedBy="extension">
<xsd:element name="exception" type="ACException" .../>
<xsd:element name="requestSchema" type="xsd:uriReference" ... />
<xsd:element name="responseSchema" type="xsd:uriReference" ... />
<xsd:element name="comments" type="xsd:string" .../>
</xsd:complexType>
...
<!-- ACEvent Definition ->
<xsd:complexType name="ACEvent" base="ACInterface" derivedBy="extension">
<xsd:element name="contentSchema" type="xsd:uriReference" minOccurs="1"
maxOccurs="1"/>
</xsd:complexType>
...
...
</xsd:schema>
|
An Advanced Component (Interface) is identified by a name that can be interpreted as a 'type' of component available to the system. An Advanced Component definition is bounded by a specification version (specVersion), a set of interfaces as
defined by the elements in the ACInterface type, a definition of Function Groups that group the interfaces in named sets, a
description of the dependencies (dependency) between the defined component and other Advanced Components required in
the system, a series of environment prerequisites, and a comments section. Advanced Component functional interfaces are defined by instantiation of the ACFunction and ACEvent elements, which in
turn are specified and defined by the component's XML Schema and namespace. In some cases, these functional interfaces will
be defined by industry standards or consortia (such as OAGIS and RosettaNet); in other cases where stable functional interfaces have
not yet evolved, individual component developers will provide their own interface definitions as part of the component
specification. An instantiation example for a Foreign Exchange component definition will include definitions of the form:
Listing 2. Instantiation example
<?xml version="1.0" encoding="UTF-8"?>
<AdvancedComponent
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
targetNamespace="http//www.ibm.com/software/components/examples/WSBCExchRate"
xsi:schemaLocation="http://www.ibm.com/software/components/ACDefinition.xsd
xmlns="http://www.ibm.com/software/components/">
<name>WSBCExchangeRate
<specVersion>1.0.0</specVersion>
<function>
<name>Convert</name>
<requestSchema>
http://www.ibm.com/software/components/examples/schemas/WSBCExchangeRate/Functions
</requestSchema>
<responseSchema>
http://www.ibm.com/software/components/examples/schemas/WSBCExchangeRate/Functions
</responseSchema>
</function>
<function>
<name>SetExchangeRate</name>
<requestSchema>
http://www.ibm.com/software/components/examples/schemas/WSBCExchangeRate/Functions
</requestSchema>
</function>
<functionGroup>
<name>Operations</name>
<functionName>Convert</functionName>
</functionGroup>
<functionGroup>
<name>Maintenance</name>
<functionName>SetExchangeRate</functionName>
</functionGroup>
<dependency>
<type>WSBCCalculator</type>
<symbolicName>CalculatorForRatesConversion</symbolicName>
<interface>Add</interface>
<interface>Substract</interface>
<interface>Divide</interface>
<interface>Multiply</interface>
<version>2.1.5</version>
</dependency>
<comments>The Operations ACFunctionGroup maps to the ExchangeRateServicePortType in
the WSDL document representing this AC as a Web service. Since maintenance activities
are preserved for use only within the enterprise, the Maintenance function group and
its function SetExchangeRate is not exposed in the WSDL document for this component.
</comments>
</AdvancedComponent>
|
In our example exchange rate component, we reference a functional interface schema (included below) that defines the functions and complex types supported by our component. We will describe how these functions and types, as well as the concepts of function groups introduced by the ACDefinition schema, will be used to define Web services in the remaining sections of this
document. See Listing 3. The following sections introduce basic Web services architecture elements and the utilization of Web Services Description Language model for its realization.
Web Services architectures
Excerpted from "Web services architecture overview," see Resources. The Web services (WS) architecture describes the principles behind the next generation of e-business architectures, providing a logical evolution from object-oriented systems to systems of services. Web Services systems promote radical decoupling and dynamic binding of components: all components in the system are services, in that they encapsulate behavior and publish a messaging API to collaborating components on the network. Services are marshaled by applications using service discovery for dynamic binding of collaborations. Web Services reflect a new service-oriented architectural approach based on the notion of building applications by discovering & orchestrating network available services (Just in time integration of applications). A Web Service is a self-describing, self-contained, modular application that can be mixed and matched with other Web Service applications to create products, processes, and value chains. They can be local, distributed, or Web-based. Previous attempts at distributed computing (CORBA, Distributed Smalltalk, Java RMI) yield systems where the coupling is too tight to be effective for low-overhead, ubiquitous B2B e-business over the Internet. These approaches require too much agreement between business systems from different organizations to be reliable for open, low-overhead B2B e-business. Meanwhile, the current trend in the application space is away from tightly coupled monolithic systems and towards systems of loosely coupled,
dynamically bound components. Systems built with these principles are more likely to dominate the next generation of e-business systems, flexibility being the overriding characteristic of their success. We believe that applications will be based on compositions of services discovered and marshaled dynamically at runtime. Service (application) integration becomes the innovation of the next
generation of e-business, as businesses re-purpose more of their existing IT applications to the Web, taking advantage of e-portals, e-marketplaces, and to leverage new technologies such as XML. Web services architecture is really a meta-architecture. It describes principles for creating dynamic loosely coupled systems based on services, but no single implementation. There are many ways to instantiate a Web service by choosing various implementation
techniques for the roles, operations, and so on described by the Web services meta-architecture. There are also various environmental considerations that must be taken into account when designing Web Services. For example,
the security requirements for services brokers will vary depending upon the deployment environment. Most intranet deployments
have minimal security requirements but in situations where high-value B2B transactions are conducted, much higher security may be
necessary. An approach is to take a risk assessment view of security and design brokers to provide different levels of information
based upon an environment_s security infrastructure.
Why a new architectural approach?
Traditional systems architectures incorporate relatively brittle coupling. The bulk of IT systems, including Web-oriented systems,
can be characterized as tightly coupled applications and subsystems. The CICS transactions, databases, reports etc. are built with
tight coupling using data structures (database records, flat files). Monolithic systems like these are sensitive to change. A change in the output of one of the subsystems, will generally cause the
whole system to break. A switch to a new implementation of a subsystem will also generally cause old statically bound
collaborations (which unintentionally relied on the side effects of the old implementation) to break down. This situation is
manageable to a certain extent through skills and numbers of people. As scale, demand, volume, rate of business change increases,
this brittleness is being exposed. Any significant change in any one of these aspects will cause the brittleness of the systems to
become a crisis: unavailable or unresponsive Web sites, slow to market with new products/services, inability to rapidly shift to new
business opportunities/competitive threats. The IT organizations can't cope with changes because of the coupling; the dynamics of
the Web makes management of these brittle architectures untenable. We need to replace the current models of application design with a more flexible architecture, yielding systems that are more
amenable to change. Web Services reflect a new architectural approach based on the fundamental notion of building applications
by discovering and orchestrating network available services. These new applications themselves become services, thus creating
aggregated services available for discovery and collaboration. Application design becomes the act of describing the capabilities of network services in order to perform a function and describing
the orchestration of these collaborators. At runtime, application execution is a matter of translating the collaborator requirements
into input for a discovery mechanism, locating a collaborator capable of providing the right service and orchestrating message
sends to collaborators to invoke their service.
What are Web services?
Web services (WS) is an evolution in the way of architecting, designing, implementing and deploying e-business solutions. WS,
based on simple architectural concepts, focuses on the interactions of components on the network, not on the details of what
happens within an individual component (service).
Fundamental to WS is the notion that everything is a service, publishing an API for use by other services on the network and
encapsulating implementation details. This is a shift to collaborations between larger (coarse grained) objects on the network and
away from architectures dominated by principles derived from any particular programming language. Fundamental to WS is:
- Encapsulation for servers, clients, proxies, applications and components; all these components can be regarded as services.
- Message Passing that is reliable, asynchronous, transactional, secure with non-repudiation.
- Dynamic Binding based on service lookup and discovery for dynamic collaboration between a service requestor and a service
provider.
- Service description and querying metadata for services.
There are several essential activities that need to happen in any service-oriented virtual environment:
- A service needs to be published to one or more public repositories in order for it to be located by potential users.
- A service needs to be located in order to be invoked by potential users.
- A service needs to be invoked in order to be of any benefit.
- A service may need to be unpublished when it is no longer available.
In addition, there are different views for the service invocation, a design-time view, a run-time view and an operational management
perspective. In each of these views, there are several issues that need to be considered:
- Creation of a new service. (For example in the design time view, creation of a new service means to create code for a service. While in the operational view, a new service must be managed.)
- Publication of a new service.
- Design time view of using an existing service (includes location and invocation)
- Run time view of using an existing service (includes location and invocation)
- Management of services (un-publishing services)
- Creation of a services broker.
- Create/Modify/Delete a service category in a services broker.
- Modify/Delete a service in a category in a services broker.
Web Services implement fundamental operations of Publish, Find, and Bind. Services are published by Service Providers to a
Service Broker. Service Requestors find required services using a service broker. As an example of the languages and constructs being developed in the WebServices environments, Web Services Description Language is
presented in the following section.
Web Services Description Language
Excerpted from "Web Services Description Language (WSDL) 1.0," 25 September 2000; see Resources. As communications protocols and message formats are
standardized in the web community, it becomes increasingly
possible and important to be able to describe the communications
in some structured way. WSDL addresses this need by defining
an XML grammar for describing network services as collections of
communication endpoints capable of exchanging messages. WSDL
service definitions provide documentation for distributed systems
and serve as a recipe for automating the details involved in
applications communication. A WSDL document defines services as
collections of network endpoints, or ports. In
WSDL, the abstract definition of endpoints and messages is
separated from their concrete network deployment or data format
bindings. This allows the reuse of abstract definitions: messages,
which are abstract descriptions of the data being exchanged, and port
types which are abstract collections of operations.
The concrete protocol and data format specifications for
a particular port type constitutes a reusable binding.
A port is defined by associating a network address with a
reusable binding, and a collection of ports define a service.
Hence, a WSDL document uses the following elements in the
definition of network services:
-
Types -- a container for data type definitions using some type
system (such as XSD).
-
Message -- an abstract, typed definition of the data being
communicated.
-
Operation -- an abstract description of an action supported by the
service.
-
Port
Type -- an abstract set of operations supported by
one or more endpoints.
-
Binding -- a concrete protocol and data format specification for a
particular port type.
-
Port -- a single endpoint defined as a combination of a binding
and a network address.
-
Service -- a collection of related endpoints.
It is
important to observe that WSDL does not introduce a new type
definition language. WSDL recognizes the need for rich type
systems for describing message formats, and supports the XML
Schemas specification (XSD) as its
canonical type system. However, since it is unreasonable to
expect a single type system grammar to be used to describe all
message formats present and future, WSDL allows using other type
definition languages via extensibility. In addition, WSDL defines a common binding
mechanism. This is used to attach a specific protocol or data
format or structure to an abstract message, operation, or
endpoint. It allows the reuse of abstract definitions. In addition to the core service definition framework, this
specification introduces specific binding extensions for
the following protocols and message formats:
- SOAP 1.1
- HTTP GET/POST
- MIME
The above language
extensions are layered on top of the core service
definition framework. Nothing precludes the use of
other binding extensions with WSDL.
WSDL Document Example
The following example shows the WSDL definition
of a simple service providing stock quotes. The service supports
a single operation called GetLastTradePrice, which is deployed
using the SOAP 1.1 protocol over HTTP. The request takes a ticker
symbol of type string, and returns the price as a float.
Listing 4. SOAP 1.1 Request/Response via HTTP
<?xml version="1.0"?>
<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/1999/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name="tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types>
<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePrice"/>
</message>
<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePriceResult"/>
</message>
<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput"/>
<output message="tns:GetLastTradePriceOutput"/>
</operation>
</portType>
<binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://example.com/GetLastTradePrice"/>
<input>
<soap:body use="literal" namespace="http://example.com/stockquote.xsd"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</input>
<output>
<soap:body use="literal" namespace="http://example.com/stockquote.xsd"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</output>
</operation>
</binding>
<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
<soap:address location="http://example.com/stockquote"/>
</port>
</service>
</definitions>
|
 |
WebSphere Business Components and Web services
As shown in the previous examples, both the Web Services Description Language (WSDL) and WebSphere Business Components Advanced Components mechanisms expose functional interfaces through a strict XML definition that fully describe their interfaces, data interchanges, and access point mechanisms for elements of an application. Both mechanisms detach completely the implementation details of the exposed interface in a technology-independent way. In fact, these approaches are complementary and provide a natural way for component-based applications to directly expose the components on the edge of the enterprise (or application domains within the enterprise) as services provided over the Internet. The realization of those interfaces in equivalent encoding mechanisms greatly facilitates this step. The main difference between 'services' architectures like the one described by WSDL and components as defined by WSBC is in the nature of the interactions and deployment mechanisms used given the environmental restrictions where they apply. Service-oriented architectures, when deployed in Internet environments, are intended to supply mechanisms like late binding (just in time integration) of the processes (Web services) between business partners. While this represents a very powerful application construction environment, the nature of the deployment technology will limit the control levels (transaction scope, for example) available to
meet to the overall system_s nonfunctional requirements. WSBC, on the other hand, has been designed as an intra-enterprise application decomposition technique focusing on elevating the degrees of freedom in the technology providing the 'services' that make up an enterprise application. Because the WSBC architecture is intra-enterprise oriented, it incorporates a deployment environment capable of fulfilling nonfunctional requirement coverage, including transactional semantics and security handling. These two architectures intersect at the _edge_ of component-based applications in use within an enterprise. Applications built using WSBC technology can selectively choose which of their components to expose as services in an inter-enterprise environment (which components represent the _edge_ of their applications when dealing with other enterprises or other divisions of the
same enterprise, for example). The following figure represents this intersection of Web services and component architectures at a conceptual level:
Figure 2.
WSDL design elements are present in the WSBC constructs and can be mapped as follows:
Table 1.
| Advanced Components | WSDL | | AC Definition Schema Construct | WSDL Construct |
- Function Group
- Function (functional interface schema)
- Request Schema
- Response Schema
- Exception
|
- Port Type
- Operation
- Message (IN)
- Message (OUT)
- Message
| | AC Functional Interface Schema | WSDL Schema |
- Element
- Arguments Managed by function
|
| | AC Deployment Definition | WSDL Construct | |
|
|
The WSDL definitions for Binding, Service, and Contract extend and build on the constructs defined by the AC Definition and Deployment Schema. A WSDL Binding relates a Port Type (a particular set of AC functions) to a physical protocol (like SOAP), a WSDL Service links a particular binding (the functions accessible in SOAP format) to a physical port and a Contract is a grouping
of one or more services. As is pointed out in the above table, WSBC component interfaces (as specified by functions and function groups) provide the underlying definitions behind a WSDL service. Advanced Components do not include the notion of binding between components. The 'default' transport mechanism between components is RMI/IIOP but the architecture and its deployment services do not preclude others. RMI over IIOP was chosen given its capabilities and applicability within an intra-enterprise environment. A given component implementation can implement multiple component interfaces, allowing for management of different encoding mechanisms. These multiple definitions clearly facilitate the process for 'publishing' sets of component interfaces (functions or operations) to be part of a given contract (i.e., multiple port types in WSDL terminology). In fact the model also maps a set of components easily to the fulfillment of a given WSDL Contract (given the independence of service definition of a set of Advanced
Components). A mapping example of these services can be viewed by taking the foreign exchange example as defined its AC definition and 'publishing' it as a WSDL construct (over SOAP). See Listing 5. In our example, we chose not to expose the SetExchangeRate function (in AC terms) as a message (in WSDL terms) within our Web service. Setting exchange rates is a function that is reserved for intra-enterprise use (that is, by the owner of the application only) and thus shouldn_t be made available to Web Services clients. In effect, we chose to publish only the Operational function group (as specified in our AC definition) to our WSDL ExchangeRateServicePortType within our WSDL ExchangeRateService.
Summary
This document presents a preliminary analysis of the component and Web Services initiatives, briefly exploring the differences and similarities between them as complementary elements of a complete architecture. Component-based architectures such as WSBC provide a natural integration point into a services architecture via their functional definitions. Specifically, because WSBC relies
heavily on a declarative approach to describing functional interfaces via XML, the information captured for specific components based on WSBC_s architecture can be readily extracted and incorporated into Web Services initiative such as WSDL. By highlighting the strong synergies between the Web Services initiative and WSBC, we have shown that these complementary architectures are key elements of an overarching architecture covering intra- as well as inter-enterprise software interoperability.
These initiatives provide a strong foundation that will evolve to shape the nature of software construction in the future. Why do two separate schema definitions (AC Definition and WSDL) exist? Because these two schemas look at a piece of software from different perspectives. For example, there are specific elements of the AC Definition schema that result from its ties to a component model and infrastructure (specification of software prerequisites, definition of system management interfaces, and so on).
Such information is not meaningful in a Web services environment and is thus not appropriate for WSDL. Likewise, WSDL_s representation of a collection of operations as a Web service is not applicable to all components within a deployed application (or even all functions defined on a particular AC); only those components whose functions are to be exposed to other applications over
the Internet should be characterized in this way.
Resources
About the authors  | | | empty |
| | | empty |
| | | Pablo Irassar is a WebSphere Business Components Architect with IBM Software Group. |
| | |
Paul Lee is an I/T Architect at IBM Global Services, working with customers on their Web-based technology applications.
He can be reached at paul@ca.ibm.com.
|
Rate this page
| 
