1 Introduction
The needs of
software development is as broad as the world
itself leading to a lot of internet jargons and
standards flooding the IT industry. In this article
the focus is on how to leverage the technical
benefits of upcoming web standards (SOAP, UDDI,
and WSDL) and the widely accepted component standards
(CORBA and EJB). The assumption is that the web
technologies defined above are not a threat for
component standards as such but only a means of
exposing the enterprise services to the web. One
can integrate the services provided by different
companies using middleware solutions like EAI
but they only provide a point-to-point integration.
On the other hand if you wish to have collaboration
integration it requires specific development for
each new service that is to be integrated.
This article
discusses on how to tame the complexity existing
in component standards and thus provide an overall
interoperable and Internet friendly solution.
This paper also cites the products available in
the market, which provide such enterprise solutions.
2 Web Services
HTML was the
only Internet standard available for data transfer
across businesses for around two decades through
the Internet friendly HTTP protocol. The problem
with HTML is that both the client and the server
transfer messages based on a predefined agreement.
The data type format used was character based
to avoid interoperability issues across multiple
platforms. With XML coming to the Internet world
around mid of 1998, has provided the flexibility
to define structured data. Since XML is based
on character type data transfer, interoperability
across platforms is not a major issue since XML
Schema provides the data type definition along
with the XML data.
XML booming
up quite fast in the internet and other application
areas as well, few IT companies got together to
define XML based communication protocol. The end
result was XML-RPC and SOAP coming to the rescue
as an Internet friendly and XML based protocol
standard for the Internet. The underlying data
transfer mechanism for both these protocols could
still be HTTP. SOAP specification is not specific
to HTTP binding only, but allows you to specify
the protocol binding of your choice, which could
be FTP or SMTP. SOAP message exchange model is
fundamentally one-way transmissions from a SOAP
sender to a SOAP receiver, but the SOAP message
could be combined to implement a request/response
patterns.
Web Service
Definition Language (WSDL) is an XML way of defining
web services. This language defines services as
collections of network endpoints. This language
relies on XML schema as the type system for defining
the messages being exchanged. This is how an enterprise
will define the services they offer to end clients
or other business partners. There was a need for
a standard mechanism to discover the services
offered by the various companies. This resulted
in the Universal Description, Discovery and Integration
(UDDI) specification. UDDI is a group of web-based
registries that expose information about a business
or other entities. It is a typical yellow pages
directory where companies can advertise their
services for trading partners and customers to
use.
3 Component
Standards and their Limitations
There are three
Component Standard technologies around us. They
include the OMG's CORBA Component Model (CCM),
Sun Microsystems's Enterprise Java Beans (EJB)
and Microsoft's Distributed Component Object Model
(DCOM). Each of these technologies defines a standard
object modeling technique that is widely accepted
in the industry. But they lack in defining the
web interfaces or web support as discussed below.
3.1 Enterprise
Java Beans (EJB)
The Enterprise
Java Beans architecture is a standard component
architecture for building distributed object-oriented
business applications in the Java™ programming
language. The Enterprise Java Beans architecture
will make it possible to build distributed applications
by combining components developed using tools
from different vendors.
The underlying
protocols for inter object communication for Java
objects in EJB are JRMP or optionally RMI over
IIOP. Both JRMP and IIOP are not the right choice
when it comes to web services because they do
not cross standard firewalls. Also they have not
been designed to use HTTP as the underlying protocol.
Apart from this problem, EJB does not provide
direct interoperability with non-Java platforms.
3.2 CORBA
Component Model (CCM)
The CORBA Component
Model (CCM) is a specification for creating server-side
scalable, language-neutral, transactional, multi-user
and secure enterprise-level applications. It provides
a consistent component architecture framework
for creating distributed n-tier middleware.
The Internet
Inter-ORB Protocol (IIOP), which is at the heart
of CORBA objects communication, does not offer
the characteristics required to access Web services.
While IIOP is a high performance protocol, it
does not have the required scalability for Web
services. In addition, it does not pass through
firewalls by default and this is essential for
setting up Web services. IIOP provides means to
overcome this firewall problem but it is considered
to be unsatisfactory in the Web Services context.
3.3 Distributed
Component Object Model (DCOM)
Distributed
Component Object Model (DCOM) is Microsoft's framework
for developing and supporting program component
objects. It is aimed at providing similar capabilities
to those defined in the Common Object Request
Broker Architecture (CORBA). Microsoft's Object
Linking and Embedding provides services for the
compound document that users see on their display.
COM provides the underlying services of interface
negotiation, life cycle management licensing,
and event services.
Some of the
important characteristics exhibited by DCOM include
fault-tolerant reference counting and reentrance
management. But DCOM does not provide the protocol
that is needed by the web services wherein the
protocol has be hyper-scalable, not blocked by
firewalls and should enable simple development
and deployment.
4 Web Service
Architecture (B2B Scenario)
According to
the Gartner Group middleware infrastructure, programming
practices of web service oriented architecture,
Components and Objects are complementary. One
will not eliminate the use of the others.
Web Services is a specification
of an application that can be accessed via the
SOAP/HTTP transport. The illustration shows a
typical B2B scenario where two enterprises exchange
the application specification that is to be integrated
upon successful business agreement between the
two. The business functions that are exposed by
the applications is basically published / accessed
by the web services using WSDL and UDDI compliant
tool. The role of the integration broker is to
enable one application, say the Financial Service
interfaces to communicate with the Payroll System
interfaces.
5 Integrating Component
Standards with Web Services
5.1 Integrating
with CCM
Just as Interface Definition
Language (IDL) describes the service offered by
CCM, Web Service Definition Language (WSDL) is
XML syntax for describing Web Services. One can
integrate CCM with the web services by providing
a mapping rule from WSDL to IDL and vice versa.
The rest of this section describes the mappings
from IDL to WSDL, with a brief description of
both the languages.
Web Services using WSDL are
defined using six major elements as tabulated
below:
| Element
Name |
Description |
| Types |
Container
for data type definitions using some
type system (such as XSD). |
| Message |
Abstract,
typed definition of the data being communicated. |
| Operation |
Abstract
description of an action supported by
the service. |
| Port
type |
Abstract
set of operations supported by one or
more endpoints. |
| Binding |
Concrete
protocol and data format specification
for a particular port type. |
| Port |
Single
endpoint defined as a combination of
a binding and a network address. |
| Service |
Collection
of related endpoints. |
|
5.1.1 A WSDL Example
Consider a
retailer site selling PC's who wishes to provide
services like the price of the various PC models.
The snippet below defines a web service definition
that enables the retailer to expose the necessary
services.
|
<service name="XYZRetailerService">
<documentation> Request for
the Current Price of the Branded PC
Model you prefer. </documentation>
<port binding="tns:XYZRetailerBinding"
name="XYZRetailerPort">
<soap:address location="http://xyz.com/soap/
"/>
</port>
</service>
<binding
name=" XYZRetailerBinding"
type="tns: XYZRetailerPortType">
<soap:binding
style="rpc" transport="http://schemas.XMLsoap.org/soap/http"/>
<operation
name="getPCPrice">
<soap:operation soapAction="http://www.xyz.com/soap/
XYZRetailerService/ getPCPrice "/>
<input>
<soap:body encodingStyle="htt://schemas.XMLsoap.org/soap/encoding/"
namespace="urn:xmethods-BNPriceCheck"
use="encoded"/>
</input>
<output>
<soap:body encodingStyle="htt://schemas.XMLsoap.org/soap/encoding/"
namespace="urn:xmethods-BNPriceCheck"
use="encoded"/>
</output>
|
|
|
<portType
name="XYZRetailerPortType">
<operation name="getPCPrice">
<input message="tns:getPCPriceRequest"
name="getPCPriceRequest"/>
<output message="tns:getPCPriceResponse"
name="getPCPriceResponse"/>
</operation>
</portType>
<message
name=" getPCPriceRequest ">
<documentation> Type the PC
Model. </documentation>
<part name="isbn" type="xsd:string"/>
</message>
<message name=" getPCPriceResponse
">
<documentation> The Price of
the PC Model is : </documentation>
<part name="return" type="xsd:float"/>
</message>
</operation>
</binding>
|
|
In order to
map the above Web Service definition of XYZ retailer
into CCM Component Model, we need to convert this
WSDL into an IDL. Then it is converted into CCM
and the CORBA Programming Model follows. The above
WSDL definition describes all the messages that
are exchanged across the peers for this service.
The getPCPriceRequest message comes from the Client
to the server whereas the getPCPriceResponse message
is generated by the Server and sent to the Client.
The Binding information and the transport protocol
is also mentioned for these messages, and also
the end point information as to where and on to
which server these messages are to be sent.
The operation
<operation name="getPCPrice">
consist of two elements, namely the input element
and output element. Each of these elements is
associated with the type information. If we recall
any programming language constructs of defining
such operation, the input element could be easily
mapped to the input parameters and the output
elements are mapped to a response structure of
the operation. In CCM and CORBA terminology, the
input elements are in type parameters and output
elements are out type parameter for an operation.
The operation element name attribute gives the
name of the operation. For instance the above
operation could be mapped to an operation in IDL
as indicated below:
| Listing
1.2 |
| void
getPCPrice(in string isbn , out float
return); |
|
The WSDL definition could be
used to generate the presentation layer for the
retailer site as well. For instance, for the above
service definition, the entry point XML file along
with the XSL file is generated as shown below.
The enterprise developer should ideally deal only
with the XSL template file generated for the presentation
of enterprise choice. The server generates the
response XML file for every request in the run
time using some server side SOAP framework. The
presentation logic for the response XML file could
also be written and customized by the enterprise
developer in the same XSL generated. There will
be ideally only one XSL file for the presentation
of entry point XML file plus all the response
structure for the operations defined.
The Entry point
XML File will be XYZRetailerService.XML and can
be accessed using the Retailer server who could
be http://www.XYZ.com/soap/ XYZRetailerService.XML
| Listing
1.3 |
//
XYZRetailerService.XML
<?XML version="1.0" standalone="no"?>
<?XML:stylesheet href=" XYZRetailerService.xsl"
type="text/xsl"?>
<service>
<documentation> Request for the
Current Price of the PC Model you prefer.
</documentation>
</service>
|
|
The default
XSL File for this service is shown below:
| Listing
1.4 |
//
XYZRetailerService.xsl
<?XML version="1.0"?>
<xsl:stylesheet XMLns:xsl="http://www.w3.org/TR/WD-xsl">
<xsl:template match="/">
<html>
<hr/>
<h1>
<font color="maroon">
<xsl:value-of select="service/documentation"/>
</font>
</h1>
<FORM METHOD="post" ACTION="http://xyz.com/soap/
XYZRetailerService / getPCPriceRequest
">
<font color="blue">Type
the PC Model. </font>
<INPUT TYPE="text" NAME="isbn"/><br/>
<INPUT TYPE="submit" VALUE="Click
here to continue"/>
</FORM>
</html>
</xsl:template>
</xsl:stylesheet>
|
|
The enterprise
developer customize the presentation of the existing
XML File as well as the response structure presentation
logic, which will be dynamically generated by
the server side framework.
This approach
of merging the web service definition with CCM
enables the enterprise to rapidly launch their
services with component-based development, has
a simplified deployment and reliable transaction
management. This approach also has an edge towards
rapid business to business communication. For
example, the XYZ retailer can provide value-added
services like shipping and financing to their
customer.
The role of
UDDI registry comes into picture now, which allows
the services description to be published so that
any body can identify these services in the run
time and start doing business; this may be termed
as run time discovery of the services. This aspect
of business to business integration is beyond
the scope of this article.
K2 Component
Server is a product that offers tools to achieve
the CCM to WSDL integration scenario. This server
is CCM compliant and provides the rapid development
tools for integrating CCM Components with the
Web Services, so that any enterprise or company
can easily and rapidly build their business offerings.
At present K2 Component Server holds a reference
implementation of the above integration approach.
Very soon K2 will be providing a complete integration
model for the CCM and WSDL. K2-WSDL Integration
Architecture is shown below:
The K2 Web
Architecture shown above is realized using a K2
SOAP Adapter, which adapts to any SOAP encoded
request either with static or dynamic binding.
The Server Side SOAP Framework responds to the
request using a SOAP envelop that has the XML
structure with the response info. The XML structure
holds the reference of the XSL file for presentation
logic.
The integration
of the K2 Components with the Web Service definition
has two approaches:
- Legacy application wrapped around Component
Interface Definition Language
- q Defining a new Web Service.
The steps involved
in migrating the component IDL and creating a
new web service definition in a K2 Development
are listed below.
Legacy
Application Wrapped around Component Interface
Definition Language
Step 1:
Use the IDL2XML tool to generate the XML Definition
of the Component IDL, the XML Definition includes
the WSDL and XSD for type definition.
Step 2:
Use the XML2HTML tool to generate the entry point
XML file and the XSL File for the Presentation
Logic.
Step 3:
Any Web Developer can edit the generated XSL for
presenting the output of the Component operation
in a customized manner.
Writing
a New Web Service Definition
Step 1:
Write a Web Service Definition ( interfaces to
the external enterprises), this will consist of
the WSDL definition and the XSD definition.
Step 2:
Use the XML2HTML tool to generate the entry point
XML file and the XSL File for the Presentation
Logic.
Step 3:
Use the XML2IDL tool to generate the Component
definition out of the Web Service definition.
Step 4:
Use the K2 specific tools to generate the Component
Executors.
Step 5:
A Component Programmer will implement those Component
interfaces.
Step 6:
Using K2 Deployment tool, deploy the Component
along with the web interfaces into the K2 Daemon.
5.2 Integrating
with EJB
EJB is integrated
with web services in a similar manner as done
in CCM. Just as the mapping of WSDL is done to
CORBA IDL in CCM, the WSDL is mapped to Java Remote
Interface in EJB. We take the same retailer example
here to identify what could be generated for the
WSDL.
Based on the
above logistics the operation defined could be
mapped to Java interface as shown below:
| Listing
1.5 |
//
XYZRetailer.java
import java.rmi.Remote;
import java.rmi.RemoteException;
public interface XYZRetailer extends
Remote
{
float getPCPrice(java.lang.String
isbn) throws RemoteException;
}
|
|
The generation
of XML and XSL will be same as explained in the
previous section. The server side framework will
be required to delegate the request to the corresponding
remote objects and respond back to the client
in a SOAP encoded message.
J2EE vendors
like Weblogic and WebSphere have taken the initiative
to provide tools for generating interfaces out
of the WSDL definition. A partial realization
of the above scenario has been done by a product
namely jbrokerWeb. It provides tools to convert
a remote interface definition into a WSDL file,
and generate Java interfaces out of WSDL definition.
It has a few missing pieces like framework and
tools required to publish the WSDL to some registry.
5.3 Integrating
with DCOM
The general
idea here is to define the COM interface for the
WSDL file detailed above. The other libraries
required to provide a complete integration of
this Component Standard with the Web is provided
by a SOAP adapter library. It takes any SOAP encoded
messages and delegates the request to the object
implementation. This requires a framework to respond
back to the client in a SOAP encoded message.
Some RAD tools will also be required to generate
the XML file and the dynamic generation of XML
response. This is then associated with the XSL
file.
| Listing
1.6 |
|
[
uuid(7371a240-2e51-11d0-b4c1-444553540000),
version(1.0)
]
library Retailer {
importlib("stdole32.tlb");
[
uuid(BC4C0AB0-5A45-11d2-99C5-00A02414C655),
dual
]
interface XYZRetailer: IDispatch {
HRESULT getPCPrice ([in] BSTR isbn,
[out, retval] float * rtn);
}
[
uuid(BC4C0AB3-5A45-11d2-99C5-00A02414C655),
]
coclass Retailer {
interface XYZRetailer;
};
};
|
|
6 Advantages of Merging
Web Services with Component Standards
- Leverage the benefits of Object Oriented techniques
and their infrastructure functionalities.
- Run time discovery of the services offered
by various organizations using a common registry
mechanism.
- Major step for any enterprise moving towards
Business to Business Integration.
- Most of the infrastructure complexities like
load balancing, fault tolerance, security, persistence,
and transaction is taken care of by the vendor's
server. Thus allowing the enterprise developer
to concentrate only on the business logic.
- The enterprise developer can only concentrate
on the presentation logic without the real data,
through the XSL template file generated by some
tool for the Enterprise Service.
- An interoperable solution across any platform.
- One can customize the underlying transport
mechanism to be HTTP, SMTP, FTP etc if the infrastructure
supports that protocol.
- The scope is not only limited to Internet
and could be widely used for other application
areas.
7 References
SOAP Version
1.2 [http://www.w3.org/TR/2001/WD-soap12-20010709/]
WSDL Version 1.1 [http://www.w3.org/TR/wsdl]
UDDI Version 2.0 [http://www.uddi.org/]
EJB Version 2.0 [http://java.sun.com/]
CORBA 3.0 [http://www.omg.org]
XML Schema [http://www.w3.org/XML/Schema]
HTTP 1.1 [http://www.w3.org/Protocols/rfc2616/rfc2616.html]
XML 1.0 [http://www.w3.org/TR/REC-XML]
K2 Component Server [http://www.iCMGworld.com]
- Rupak Kumar, Software
Engineer, iCMG.
|
