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.

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.

<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:

<?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.

Back to top

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:

1. A service needs to be published to one or more public repositories in order for it to be located by potential users.
2. A service needs to be located in order to be invoked by potential users.
3. A service needs to be invoked in order to be of any benefit.
4. 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.

Back to top

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.

<?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>

Back to top

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:

WSDL design elements are present in the WSBC constructs and can be mapped as follows:

Table 1.

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.

Back to top

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

• Read the rest of the Web Services Architecture Overview.
  
  
• See the current version of the Web Services Description Language (WSDL).
  
  
• Visit the developerWorks Web services special topic for more information about Web services.
  
  
• Find out more about WebSphere Business Components.
  
  

About the authors

Rate this article

Comments

Back to top

Table of contents

• Advanced Components, their definition, implementation and deployment
• Web Services architectures
• WSDL Document Example
• WebSphere Business Components and Web services
• Summary
• Resources
• About the authors
• Comments

Next steps from IBM

With the WebSphere Application Server you can benefit from the simplified EJB 3.0 development experience, new persistence model, and interceptors.

---

• Try: Download a free trial version of WebSphere Application Server Community Edition, the lightweight Java 5 application server with robust EJB 3.0 funtionality.
• Article: Learn how call patterns and components involved in making calls to EJB components deployed in the EJB container operate in WebSphere Application Server.
• Tutorial: This tutorials shows you how to create an enterprise J2EE application that implements both Plain Old Java Object (POJO) and EJB Web services endpoints.
• Demo: Watch this demo and learn how to configure and use the WebSphere Application Server and the Eclipse IDE with the Web Tool Project Platform.
• Buy: WebSphere Application Server