CHAPTER

Business Process Integration

Chapter 4 discussed the integration of Enterprise Information Systems (EISs) applications
via the Java 2 Platform, Enterprise Edition Connector Architecture and the Sun Open Net
Environment (Sun ONE) architectures native support for Web services. Chapter 5 considered
service integration via the asynchronous reliable messaging systems such as the iPlanet
Message Queue for Java. This chapter explains the top-level federated software system
integration capability provided by the Sun ONE architecture.
The generally accepted industry definition of integration can be paraphrased as the
controlled sharing of data and business processes among any connected applications and
data sources within an enterprise and between trading partners. To make economic sense
for today's IT organizations, this must be possible without having to make sweeping
changes to the corporations existing information assets, including applications and data
structures.
Such flexible system integration of diverse clients and services requires a comprehensive
infrastructure, especially when those clients and services are defined and limited by others
outside the control of the local enterprise. Typical real-life examples are off-the-shelf
packages and vendor-supplied external services.
Because the needs of application systems are often as diverse as the source, age, and
technology of their implementations (as with programming languages such as, C++, CICS,
or Java), system integration product architectures often include a plug-in approach in the
data translation and messaging layers. This plug-in approach allows the basic framework to
be extended in the field to encompass a wide variety of situations.
For example, the system integration infrastructure must be capable of integrating services
and applications within the firewall, as well as those that are resident anywhere on the
Web. The iPlanet Integration Server product facilitates the integration of services and
applications in both types of locations. It is described in Section 6.4, iPlanet Integration
Server.

6 Business Process Integration

77

6.1

The Integration Challenge

Increasingly over the recent years, IT departments have focused less on building new
applications. Instead they have devoted more effort to connecting existing applications.
Mergers and acquisitions have increased, while corporations have found that they cannot
continue to leverage their accumulated IT assets.
New technologies and product releases often leave these business assets on orphaned,
legacy infrastructure islands. Over the next decade, integration will continue to be the
dominant challenge facing IT and corporate software development experts.
The following three example settings illustrate how integration plays a significant role in
all development projects, no matter how small:

6.1.1

Business document exchange

Connecting internal applications

Establishing new partnerships and businesses

Setting 1: Business Document Exchange

A corporate objective is to connect separate systems within an enterprise. For example, an
enterprise might need to make a Customer Relationship Management (CRM) package and a
financial application package such as Oracle Financials communicate with each other.
The development strategy here might be to devote IT resources toward reviewing each of
the application interface libraries for these packages, developing a connection strategy that
is unique to the two systems, and finally implementing the project. This strategy works well
until another, separate system needs to interact with one or more of the two integrated
systems. As new systems are added to the mix, the process can become unmanageable.

6.1.2

Setting 2: Connecting Internal Applications

In this setting, a corporation needs to establish connectivity between internal applications
within its own corporate environment. These applications have key corporate business
functionalities implemented in relatively isolated technology islands. These functionalities
may include, for example:

78

Typical transaction-style systems, perhaps running in large corporate data centers.

Systems built on specialized business-oriented technologies from various vendors such

as SAP, PeopleSoft, and Siebel.

Home-grown applications that provide unique business value such as financial portfolio
analysis, or insurance risk or rating applications.

Sun ONE Architecture Guide

The corporate objective here is to tie these applications together to provide a more uniform
or expanded capability to a larger organizational or business function. Often the tasks are
driven by the need to simplify or regularize repetitive functions, such as updating customer
contact information, or using a single application to perform a common business function.
As in the Business Document Exchange setting, often these tasks are handled as unique
projects. Each project is concerned only with connecting the systems and applications
currently of interest to the project. Because the average enterprise has at least 50 unique
and disparate business applications, before long these types of projects become so
intertwined and complex that it is almost impossible to effectively manage them or predict
how changes at one end might impact another.

6.1.3

Setting 3: Establishing New Partnerships and

Businesses
As business becomes more global, the quantity of available partners has dramatically
increased in recent years. It is now possible to interact with consumers and suppliers
across the globe as if they were around the corner. In addition to the usual business
relationship concerns, global associations are often dramatically affected by rapidly
changing and often unforeseen events, such as public policy, monetary fluctuations, and
available labor. As the available marketplace of consumers and suppliers grows, so do the
possibilities for creating partnerships. From an electronic exchange perspective, effectively
managing and supporting global associations and partnerships is an enormous challenge
to any company.
At the time of this writing, only one reliable and effective integration strategy can address
this type of a dynamic, international marketplace of collaboration. That strategy is
embodied by the Electronic Business for eXtensible Markup Language (XML) Interchange
collection of specifications, referred to as ebXML. For more information, see Section 6.3,
ebXML.
The Sun ONE architecture embraces both the Web service native specifications and the
business extensions offered by ebXML. In many cases, these standards can coexist, but
certain compromises may not be acceptable for a reliable business.

6.2

Existing Styles of Integration

Integration-based products can be categorized into a number of useful types. The following
three are of primary interest to the discussions in this chapter:

Integration between businesses, often called Business to Business, or B2B.

Integration between applications within a business, often called Application to Application

or A2A. When A2A is coupled with a process-oriented sequencing engine, it is often
referred to as Enterprise Application Integration (EAI).
6 Business Process Integration

79

E-Commerce Integration, an emerging new style of integration whereby businesses establish

and change collaborations in a highly dynamic and rapidly changing environment.

These three styles of integration are discussed in the sections that follow.

6.2.1

B2B Integration
B2B integration provides some methodology that allows businesses to share data between
their respective information systems This data-sharing generally consists of the exchange of
documents between business partners. Typically accomplished using pre-defined documents
or forms, this type of integration is referred to as Electronic Document Interchange (EDI).
While there are many specification standards, the most prominent is the X.12 standard,
which is defined by the Accredited Standards Committee or http://www.x12.org.This
committee defines a collection of documents that can be used as exchange media between
partners. Many categories of documents are standardized by this organization and their
international partner, which is part of the UN/EDIFACT (United Nations rules for Electronic
Data Interchange for Administration, Commerce, and Transport). These organizations define
the document to be exchangedincluding the format, fields and their contextual relationship
with extensions and updates are released annually.
Widely varying messaging protocol formats have grown up as technologies have advanced.
Support for private Value Added Networks (VANs), simple File Transfer Protocol (FTP),
Multipart Internet Mail Extension (MIME), and other formats are commonly used. Originally
the exchange documents were pure text. As technologies have evolved, however, they have
evolved to use XML.
B2B integration, or document exchange, tends to be relatively staticbusinesses know the
identity of their partners beforehand. Based on these partnerships, mutual interest drives
both sides to invest in the information infrastructure to support this exchange.
How each company chooses to implement its business behind the exchange end-points is
entirely up to that company. The standards say nothing about this. Further, with the
exception of efforts such as RosettaNet PIPs, the standards generally do not attempt to
describe how or in what context the exchanges could or might fit into the overall
application.
However, the dividing lines are clear. Each organization has its inputs and outputs. Each is
free to implement and host these exchanges in any fashion they desire. So long as the
overall partnership remains in good business health, so do these exchanges.

80

Sun ONE Architecture Guide

6.2.2

EAI Integration
Within an enterprise, applications have been developed to provide various service functions
for the organization. These may include functions such as customer tracking or account
management systems, or they may be more inwardly focused employee management
systems. Even in a conservative organization, applications that were once considered
completely isolated from the rest of the business eventually interact with other systems
and information technology assets within it. Adding mergers and acquisitions into this mix
simply increases the certainty that there will be overlap, redundancy, and a need for
interconnections between information systems.
Traditionally, systems connections have been built on a per-project basis. Often, the first
effort combines all the applications that reference customers using the common element
(or abstraction) of the customer, along with a customer-tracking system. These projects
start with a team of IT staff that research the combination of the application interfaces.
This effort might then be followed by a project that connects abstractions like Orders,
Claims, or Trades.
As enterprises are forced to grapple with the ever-increasing need to respond to business
changes, they must come to terms with this legacy of information assets and the need to
maintain these connections in a fashion that allows for dynamic, agile system upgrades.
Maintaining agile and dynamic connections between corporate assets is critical to an
organizations ability to rapidly respond to business climate changes. To effectively support
such requirements, systems must be loosely connected. Furthermore, the process
specifications must have the capacity to support migration from today's processes to
tomorrows as-yet unknown needs.
The personnel that are most uniquely positioned to understand how the enterprise
accomplishes its business are most often domain experts, sometimes called business
analysts. They have expertise in how the enterprise accomplishes its goals. Typically valued
for their ability to understand what is important and to provide key business value to the
particular enterprise, these business analysts often have little or no software development
background. Nonetheless, they have expertise in core aspects of the business such as
Medical Management, Portfolio Risk Analysis, or Claims Administration. They work with
concepts that are even more abstract than the collaboration exchange documents of B2B
integration systems. These abstractions may not even have a real-world analog.
A graphical process-specification tool is essential to effective management of information
assets in conjunction with business abstractions. Such a tool can specify how the system is
to manage, coordinate, and drive to conclusion all the information and personnel aspects
of a system. Graphical process specifications allow domain experts to route work to
automated services such as credit check and print check, as well as to send messages to
human users based on events such as documents received and pending deadlines.
EAI is the overall term that encompasses this effort to draw together, manage, and control
the overall enterprise application as a collection of independent yet loosely connected
system components and services.

6 Business Process Integration

81

6.2.3

e-Commerce Integration
When B2B and EAI integration are combined, then confronted by the need to integrate with
partners rapidly, reliably, and securely, the result is Electronic Commerce (e-Commerce)
integration. In this environment, partners rapidly move in and out of business collaborations
via the dynamic relationships that are commonplace across the Internet.
The e-Commerce flavor of integration relies on utilization and ubiquity of common standards
that allow for reliable interaction and discovery between partners. These standards must
provide complete business functions with authentication, signatures, nonrepudiation, and
business context. Furthermore, they must be ubiquitous, reliable, and well-understood
across the entire class of potential partners.
When working with standards for the Web, open forum standards committees with
corporate sponsorship are the norm for developing this part of the interconnection
requirements. These processes can take months or possibly years to complete. It is
important to choose standards that perform to the requirements of the enterprise in order
to accomplish reliable, predictable, and safe interactions can be accomplished. While many
proposed specifications for XML-based interactions are in development, the Sun ONE
architecture and emerging ebXML standard are the only collection of e-Commerce
standards that are ready for business use at the time of this writing.

6.3

ebXML
Initiated in 1999, the Electronic Business eXtensible Markup Language (ebXML) collection
of specifications was initiated by a consortium of businesses, vendors, and governments.
The 1.0 set of completed standards was released in 2001, and many of them are well into
their second revision.
ebXML is sponsored by UN/CEFACT and OASIS. UN/CEFACT is the acronym for United Nations
Centre for Trade Facilitation and Electronic Business, headquartered in Geneva. OASIS is
the Organization for the Advancement of Structured Information Standards, a nonprofit
organization dedicated to the creation of international interoperability specifications based
open, public standards.
As a collection of standards, ebXML builds on top of the same collection of requirements
and prerequisites that have driven other Web-services standards, such as Simple Object
Access Protocol (SOAP), Web Services Description Language (WSDL), and Universal
Description, Discovery, and Integration (UDDI). However ebXML picks up where these
standards leave off, providing many features that are still only in the formative stages as
alternative specifications.
ebXML comprises a collection of key system components, each of which can be implemented
or adopted independently or in conjunction with the other components. This allows for easy
adoption of the technology in a gradual, controlled fashion.

82

Sun ONE Architecture Guide

6.3.1

ebXML Objectives and Architecture

The core objectives of ebXML are to build a collection of standards that lower the expense
associated with reliable electronic interchange for small- and medium-sized business.
Implementation of these standards will allow organizations that may not have dedicated
development staff (and may have only a single desktop platform) to participate in these
electronic business exchanges. Another goal of ebXML is to allow these exchanges to be
performed across the open Internet and provide an alternative to using EDI VANs.
Figure 61 illustrates the overall architecture of ebXML.

Figure 61:

ebXML System Architecture

Each of these blocks is discussed in the following sections.

6.3.2

ebXML Messaging
As discussed in Chapter 5, Asynchronous Reliable Messaging, messaging is the heart of
any business exchange. Exchanging messages can take many forms. These include sending
application binary, text, or XML payloads within EDI, MIME, or SOAP envelopes sent via
e-mail, FTP, or HTTP, with or without encryption.
Reliable messaging requires that message deliveries are acknowledged and delivered onceand-only-once per message. Reliable messages may need to be processed in the order they
were sent. They also depend on security mechanisms to prevent inadvertent or intentional
modification, to validate the source and sender, and to provide an audit trail of what was
sent and received prevent a partner from repudiating a transaction.

6 Business Process Integration

83

Secure messaging requires that the message contents cannot be revealed to unintended
recipients. Secure messaging includes encrypting application data as well as message
routing metadata.
The ebXML messaging specification provides the framework for reliable messaging, allowing
for a wide range of service levels, authentication, and record-keeping options. Key elements
of the ebXML specification include:

6.3.3

D e l i v e r y g u a r a n t e e s These guarantees range from best-effort delivery to

guaranteed once-and-only-once delivery. They include support for missing
acknowledgement timeouts, retransmissions, retry intervals, maximum retry attempts,
and duplicate elimination as necessary.

O r d e r e d m e s s a g e d e l i v e r y This messaging element guarantees that messages with

sequence identifiers will be delivered to the partner application in the proper sequence.

S e c u r i t y p r o f i l e s These profiles range from none to various combinations of digital

signing and encryption.

C o n t e n t a g n o s t i c s p e c i f i c a t i o n s This messaging infrastructure can be used by

collaborators for exchanging any data they like, from EDI X.12 documents to XML
documents to the more mundane business documents, often binary, such as drawings,
spreadsheets, or scanned images

M u l t i p a r t m e s s a g e s These types of messages allow multiple documents to be

clipped together into a single message package.

ebXML Collaboration Elements

In order to effectively perform electronic commerce, it is critical to know the capabilities of
each collaborator, how to exchange messages, and, most importantly, when the specified
exchanges are appropriate. Once these capabilities are reviewed and the collaboration
begins, a record of the agreement used during the collaboration is required. This agreement
contains the subset of the intersection of two capability profiles and defines exactly how
the exchanges are going to take place.

6.3.3.1

Collaboration Protocol Profiles

The first collaboration element is the Collaboration Protocol Profile (CPP). This document,
as described in the ebXML specification, defines the capabilities of a specific partner. It can
simply describe what forms of messaging can be utilized, or it can contain a complete,
detailed view of an entire collaboration offering.
For example, a simple CPP document might specify:

84

An end-point URL

The types of messaging capabilities that business wants to use (for example, encrypted
Multipart SOAP messages with trusted signatures)

Sun ONE Architecture Guide

A more complex CPP might also specify:

Once-and-only-once delivery

Sequence ordering

The process specification

The business document schemas to be exchanged

These profiles can list alternatives supported. For example, a business might accept
messages over a specific HTTP port, or via FTP or via SMTP.

6.3.3.2

Collaboration Protocol Agreements

When businesses come together to engage in business, they form agreements. These
agreements can comprise technical and mechanical details, as well as describe business
issues, response time-frames, problem remediation, and other matters.
With ebXML, the business-technical aspects of these agreements are described in the
Collaboration Protocol Agreement (CPA). This document refines the profile capabilities found
in the CPP document for each business. It also establishes an agreement that provides
resolution to any optional or mismatched capability provisions. For example, if Partner A's
profile lists HTTP and FTP as allowable messaging protocols, but partner B's profile
identifies only HTTP, then the CPA would identify only HTTP as the messaging transport.
Beyond messaging details, CPAs can contain response timeframes. An example response
timeframe is: Whenever document A is received, the recipient must send a message
acknowledgment within 30 seconds, or the document will be sent again. After five re-tries,
the message will be considered undeliverable and the exchange will be aborted.
CPAs can also specify the business documents that will be used for exchange. Such
business documents can even specify complete multi-exchange process descriptions.

6.3.3.3

Document Exchange Processes

Document exchange processes are an important facet of e-Commerce system design. This is
a key differentiator between ebXML and other currently approved standards available for
general Web-services development. The process specification allows collaborators to
provide contextual organization for collaboration sequences. These sequences can be as
simple as describing a single document exchange as outlined above. Alternatively, they can
be as complex as describing a complete process such as bid, acceptance, purchase order,
funding, type of auction, and means of exchange.

6 Business Process Integration

85

6.3.3.4

Business Process Schema Specification

Business process definitions and descriptions are captured in the ebXML Business Process
Specification Schema (BPSS). While this XML schema document can describe arbitrarily
complex processes, in practice the BPSS often merely describes simple exchange procedures
such as how to send and acknowledge a document, and what to do if certain error
conditions occur.

6.3.3.5

Registry Repository
It is a given that any company will participate in any number of CPAs. These collaborations
may be with one or more organizations and may describe one or more related or unique
business opportunities. Users have the need to store and categorize these CPAs in a logical
and extensible manner that allows their applications to reference these documents when
messages arrive. For example, when a message containing document X arrives, the
message references a CPA ID. The system can consult the corresponding CPA to determine
how to process the document, how to respond, how to ascertain if the message has been
properly sequenced, and how to acknowledge receipt.
ebXML provides a complete specification for a repository that can store and retrieve these
documents and artifacts. The documents may contain the public, advertised portions of the
system or the private portions of the system that describe, for example, how a particular
company adds its own unique business value.
Another core value that ebXML adds to the e-Commerce palette of system development is a
framework that allows collaborations to be established with the same type of dynamic
behavior characteristic of the Internet (with respect to Business to Consumer or B2C styles
of interactions). ebXML provides specifications for the repository that allow public access to
the artifacts that the corporation wants to make public. Unlike UDDI, these specifications
provide facilities for determining who has access to what.
The goal is to develop a framework that provides dynamic advertisement and collaboration
so that businesses can enter into partnerships with little or no coding or IT-centric
overhead. This would allow each business system to read, interpret, and respond to
documents with a much higher level of automation than ever possible.

6.3.4

ebXML Core Components Project

The final objective of the ebXML initiative is to solve the vertical impedance mismatch
between documents and terminology of one business domain to another. As an example,
purchase orders for the medical industry are not readily transferable to the automotive
industry. The Core Components project seeks to simplify the crosstalk between different
business vertical industries. The Core Components group has focused on definitions of
schema elements and hierarchies, finding definitions for concepts common across different
industries.

86

Sun ONE Architecture Guide

Another approach to solving this problem is being promoted under the guise of Unified
Business Language (UBL). At the time of this writing. UBL is being run as an OASIS
Technical Committee effort. UBL is an extension to the XML Common Business Library
(xCBL). More information on UBL can be found at http://www.oasis-open.org and
http://www.xcbl.org.

6.3.5

ebXML Functional Overview

As shown in Figure 62, systems developers construct specialized business logic, interface
elements, and interconnections between existing and new information technology assets.
Business analysts and contracts administrators, on the other hand, specify the business
profiles (CPPs), agreements, Business Documents (BD), Workflow and Collaboration
definitions (BPSS), Core Components, and other elements. These are all stored in a
repository that allows them to be referenced at runtime, reused for new collaborations,
and referenced for historical and statistical work. All the actors can work with development
parallelism to achieve optimum system development performance.

Figure 62:

ebXML Functional View

Global-sized organizations might implement their own business logic, applications and
components by developing Java and other applications. On the other hand, a small business
may simply use the ebXML messaging for document exchange, creating and manipulating
documents with off-the-shelf forms and page editors.

6 Business Process Integration

87

6.3.5.1

Reliable Electronic Business Exchange

A reliable electronic system for exchanging messages is essential to an enterprises process
of engaging in business with partners. Reliability is absolutely critical. For any system to
become widely accepted by an enterprise, it must reliably solve the needs of that enterprise
and do so at a cost that is attractive, especially when compared to current systems for doing
business.
For enterprises, reliability includes not only the standard features associated with highly
scalable systems, but also extends to the ability to reliably track, reconstruct, and drive
business exchanges. Message tracking, guaranteed-once delivery, message sequencing,
and nonrepudiation must all be available to assure collaborators that their processes will
work smoothly. Collaborators also demand assurance that they will be able to reliably
defend their actions if needed, as well as to reliably find and track down problems easily.
While content is critical to the ultimate success of any business system, the designers of
ebXML had the foresight to focus on the internal infrastructure and architecture, regardless
of the document payloads that are to be exchanged.

6.3.5.1.1

Advantages over Fax Messaging

ebXML messaging is, by its definition, multi-point aware. Transmission, Reliability, and
Packaging (TRP) specifications provide a complete suite of specifications that define the
spectrum of available options that must be supported for any compliant messaging service.
While server-side services require high-volume, multi-staged routing capabilities, smaller
scale businesses are more concerned that their messages are secure and can be reliably
exchanged with their partners using a simple, straightforward methodology.
The most common messaging solution in use by business today is the FAX machine.
Because most business have at least one desktop computer, ebXML messaging can replace
this functionality at similar or lower cost. The messaging infrastructure can add levels of
tracking, authentication, nonrepudiation, and secrecy that are simply not possible via FAX
documents. When XML documents are exchanged, the added benefits of an easily machinereadable exchange medium make this a combination that has clear compelling value to
business of any size, so long as the price of entry is sufficiently low.

6.3.5.1.2

Differentiation from Web Browser Messaging

It is important to differentiate the solutions discussed in this chapter from today's
most common, Internet-based messaging solutionthe Web Browser form. Easy and
straightforward to implement, for many user-style consumers (and even corporate users),
the Web Browser form offers a sufficient level of quality. However, these exchanges have low
reliability and add little, if any, of the additional value that ebXML messaging specifications
provide. Basing an automated exchange on the reliability level of browser-based forms is
simply not a reasonable starting point.

88

Sun ONE Architecture Guide

6.3.5.1.3

Importance of Quality of Service

Guaranteed once-delivery of messages is a critical feature of ebXML TRP. Additional features
provide for scaling back this option to levels such as best effort (if it fails, try it again) and
at least once (if duplicates are received, the receiver can eliminate them).
When people drive the end-point applications, the elimination of duplicates, the confirmation
of messages, and message missing (NAK) procedures are relatively easy for people to sort
outbut problems do occur. For example, customers submit orders from HTML forms and
receive duplicate shipments or nothing and critical documents get lost in FAX hoppers.
Businesses have become accustomed to these types of problems and have developed
management processes and procedures in the face of these issues. However, building
automation systems that must react to such low service quality are difficult to design and
hard to maintain. The ebXML messaging system can reliably deliver messages at nearly any
level of service quality necessary for efficient, automated operation. Furthermore, they can
do this with complete security.

6.3.5.2

Authentication and Audit

Users must be certain that the message has actually been received from the party that is
expected to have sent it. Messages need to have secure authentication schemes for the
message packages, the payload documents need to be authenticated, and message exchange
must be accomplished using secure encryption.
Furthermore, audit tracking must be an integral part of the messaging system. Tracking
must extend to each of the collaboration partners as well. Message exchanges must be
monitored and tracked even after the container package has been received. Each payload
section may have a unique destination within the ebXML application. Furthermore, the
messaging system must be able to provide a complete record of what was received, how it
was processed, and what the credentials of the message actually were.
This is critical to the support of nonrepudiation. However, nonrepudiaton is not as simple as
archiving each and every step of the message-processing chain. Some businesses operate in
environments in which documents can be rescinded. For example, a customer may sign a
contract for a loan, then decide that he or she does not want the loan. (In certain
jurisdictions, rescinding a loan is legal within a cooling-off period.) Such requirements must
be allowed in order to support effective commerce. In other words, the systems need to
support the business, rather than making the business alter its practices to conform to the
demands of the systems.

6.3.6

Profiles and Agreements in Practice

It is unlikely that corporations will quickly accept the notion of rapid dynamic collaboration
environments. However, if there is sufficient value, it is quite possible that users will rapidly
adopt this strategy.

6 Business Process Integration

89

In any case, the results of profile lookup must be reliable, consistent, and well understood.
At present, a competing technology, Web Services Description Language (WSDL), is also
designed to provide capability descriptions. However, at the time of this writing, there is
insufficient specification and common agreement about how exactly to define a service
and, perhaps more interestingly, no common mechanism for reliably searching and finding
a service. Much of the selection criteria has been reserved and may be withheld from the
specification so that the repository service providers can choose how to respond to underspecified queries.
With ebXML, there is a clear specification of how to describe the service, as well as of how
to retrieve the service definition. Messaging specifications are clearly defined; exchange
procedures can be described and used in automated systems; and business documents can
be written in formats that can be readily interpreted electronically.

6.3.7

Exchange Processes
Once the appropriate set of collaboration profiles are assembled, the stage is set for the
actual business exchange. With the ebXML specifications included in this architecture, it is
always possible to determine when and how it is appropriate to perform this interaction in
a reliable and automated fashion. Generally, the exchange processes can be of a simple
pattern: Send document, await acknowledgment, finish. However as outlined above, these
transaction processes can be arbitrarily complex.
With SOAP and UDDI alone, the interactions must be implemented independently by the
separate applications. If there are discrepancies between these implementations, error
signals and system administrators must be used to sort it out. WSDL can help, but it does
not identify the roles nor the documents to be exchanged in the collaboration.
Table 61 summarizes the level of capabilities associated with each of the methodologies
and standards that have been discussed above.
Table 61:
Function or
Quality of Service

90

Human Agent

Paper Contract

FAX

Web Service

ebXML

Machine
Readable

N/A

Audit Trail

Authenticated

Choreography

Nonrepudiation

Reliable

Sun ONE Architecture Guide

Function or
Quality of Service

Human Agent

Paper Contract

FAX

Web Service

ebXML

Secure

Tamperproof

Validation

Given time, Web services specifications will undoubtedly provide equivalent features and
functions to ebXML. However, ebXML is ready for business use today.

6.4

iPlanet Integration Server

The iPlanet Integration Server is designed and built to incorporate many of the features
described by the ebXML specifications discussed in previous sections. It is described here as
an example of an ebXML application that enterprises can use for both collaboration and
reliable messaging in the dynamic, international marketplace.
Note that the iPlanet Integration Server is an optional component of the Sun ONE
architecture. The facilities needed by the clients and servers can be provided by any
software that meets the messaging, data, and delivery requirements of the enterprise.
From an external perspective, this can be as simple as XML and HTTP Web-service-only
integration, using, for example, integration based on Simple Object Access Protocol
(SOAP), Universal Description, Discovery, and Integration (UDDI), and Web Services
Description Language (WSDL). However, this could be a completely arbitrary collection of
collaborations for e-commerce, internal applications with specialized API requirements, or
business logic available from a suite of Java components. The architecture described in this
book presents this integration structure and illustrates how to select the proper building
blocks for runtime and tools to meet the requirements of any type of integration
architecture.
The externally visible architecture of the iPlanet Integration Server appears in Figure 63.

6 Business Process Integration

91

Figure 63:

iPlanet Integration Server Architecture

As Figure 63 shows, the main components of the iPlanet Integration Server architecture
are as follows:

Controller/Coordination Layer

Transformation and Translation Layer

Messaging Interface Layer

Clients and servers

These components are discussed in the following sections.

6.4.1

Controller/Coordination Layer
This layer includes three separate controllers that can be deployed and used separately or
concurrently:

92

Private Business Process Engine

Message Routing Table

Document Exchange Process Engine, operating in accordance with Business Process

Specification Schema (BPSS) Business Signals

Sun ONE Architecture Guide

6.4.1.1

Private Business Process Engine

A business process is a sequence of operations and the associated data. The classic
example is order processing. In this case, the operations may include steps such as:

Credit check

Order validation

Inventory check

Back order hold

Shipping

Customer notification

The above sequence of operations includes decisions such as if a part is not in inventory,
generate a back-order request. It also may also include timers, which can be either
periodic, such as wait until 8 AM to notify shipping or elapsed, such as if the part is on
back-order for more than two days, send an e-mail to the customer. While most operations
are automatic and carried out by services, some may be manual. If the amount is large,
send to a manager for further verification is an example of a manual operation.
The data associated with a business process typically includes:

Order details, which consist of a description of the order, including line items and the
name of the customer.

Data that changes as the order is processed; for example, the order status and the name
of the order processing clerk.

Each business process is defined using a graphical tool that allows a business analyst to
specify the complete map or sequence of operations, as well as the data that is needed to
complete every operation. That tool also allows the analyst to make decisions about which
path in the map is to be performed. A map may be named, for example, Shoe Order, and
stored in a repository that is available to the engine.
Either a client or a service that specifies both the name of the business process and its
associated data can initiate a business process. The engine uses the name to find the map
for the process and saves a copy of the data in a database. It then begins to interpret the
process definition, starting at the defined entry point. Each operation is invoked in its turn.
As this occurs, decisions are made that select various paths within the process. The process
terminates when the exit point is encountered.
The role of the Private Business Process Engine is to act as the central traffic cop of the
application system. It invokes services and interacts with clients in a controlled manner, as
specified by the business analyst. Each of these services and clients simply responds to the
process engine; it does not communicate directly with any other service or client. This
enables effective encapsulation of the services and clients, thus providing maximum reuse
of these software components.

6 Business Process Integration

93

6.4.1.2

Message Routing Table

The Message Routing Table is simpler than the Private Business Process Engine in several
ways:

It employs the fire and forget paradigm, which means that the Message Routing Table
does not maintain any state associated with the operation or sequence of operation.

The service or application invoked does not return a result. Therefore, the process map
that is interpreted by the Private Business Process Engine is absent. Instead, the business
analyst creates a simple table of operations. Each entry in this table contains:

An optional identification of one or more message senders

A message content pattern

A message destination, which is almost always a service

When a message is received, the integration server consults the Message Routing Table.
For each row that matches the identity of the sender, the message content is compared to
the corresponding content pattern. If a match is found, the message is sent to the specified
message destination.

6.4.1.3

Document Exchange Process Engine

The Document Exchange Process Engine manages document flow between the integration
server and external sources according to rules specified using ebXML. Most often, these
rules are used to control information passed among trading partners. They can also be
used for information flow between departments or entities in a single business. These rules
are constructed by a business analyst or imported from definitions supplied by industry
trade groups.
Exchange processes, or choreography, are published as BPSS and are available for use by
the partner as well. Typically these are associated with specific CPAs, but choreography can
be used independently if needed.

6.4.2

Data Transformation and Translation Layer

If necessary, messages are passed through the Message Transformation layer. This layer is
responsible for converting data from one dialect to another. A unity transform requires will
bypass this layer. Simple transformations may consist of stripping out unnecessary data for
the next action, or simple reorganization of the fields into an alternate schema. Complex
transformation may require splitting elements apart or performing lookup operations to
convert from one series to another.

94

Sun ONE Architecture Guide

This layer is typically used to transform data to and from the end-point applications into
the common, regular format that is used within the enterprise. This canonical
transformation is useful in the following scenarios:

Messages arriving from clients and services

Messages sent to clients and services

The Data Transformation and Translation Layer solves the problem of matching the data
format and content requirements of the service or application to the available data format
and content. Consider this example: In the order-processing scenario described above, the
data provided by the initiator of the order includes order details comprised of the customer
identity, the list of shoes being ordered, and the total value of the order. This is encoded in
XML. The credit check service expects only the customer's credit number and the amount
of the purchase. In such a situation, the Data Transformation and Translation Layer would
be used to perform three operations:

Remove the extraneous data and pass only the customer's credit number and total
purchase amount.

Change the field names as needed in the likely situation that the order details XML
document contained different field names compared to the credit check service.

Convert the information from the XML document maintained by the process engine into
the EDI format needed by the credit check service.

In addition, the response from the credit check service would be translated and then
merged with data held in the Private Business Process Engine:

Convert the arriving Electronic Document Interchange (EDI) format to XML.

Translate the simple numeric response (1 means yes and 0 means no) into Good or Bad.

Move the translated value into the CreditStatus field of the XML document held by the
Private Business Process Engine.

Because most messages can be translated using XML Stylesheet Language Transformations
(XSLT), this is the primary data translation and transformation facility. In cases where more
complex translations are needed, the architecture provides for a general-purpose plug-in
capability.

6.4.3

Messaging Interface Layer

Just as with the Data Transformation and Translation Layer, all received and transmitted
messages pass through the Messaging Interface Layer. Three message interface types are
supported:

Java API for XML Messaging (JAXM)

Extended JAXM for ebXML

6 Business Process Integration

95

Java API for XML-based RPC (JAX-RPC)

Java Message Service

A variety of message handling plug-ins are provided for each, including the capability for
customers to provide additional custom plug-ins.
For outbound messages, the layer uses a destination descriptor attached to the message by
the Controller/Coordination Layer to select a message interface type and plug-in. Inbound
messages are tagged by the Message Interface Layer to identify the sender. In both cases,
the information in the tag varies according to the particular plug-in. For example, a
message arriving via Java Message Service would include the name of queue it was retrieved
from and other associated information.

6.5

Future Directions for Messaging

Universal Business Language (UBL) is an emerging standard for providing a more canonical
framework for the document payloads for electronic commerce. At the time of this writing,
the architecture neither includes nor excludes use of UBL documents. For more information,
refer to the discussion of The Next Step for Global e-Commerce white paper at
http://www.oasis-open.org.

6.6

Process Integration Interfaces

The following table lists the requirements for the Sun ONE architecture conformance for
process integration components.

96

Interface Name

Level

Status

Reference

Comments

EbXML Messaging
Specification, 2.0

Application

Footnote 2

http://www.oasisopen.org/committees/ebxmlmsg/documents/ebMS_v2_0.pdf

Approved in January
2002

CPP and CPA

Specifications

Application

Footnote 2

http://www.oasisopen.org/committees/ebxmlcppa/documents/working_drafts/inde
x.shtml

Index of draft
Specifications and
Schemas

Collaboration
Exchange Processes

Application

Footnote 2

http://www.ebxml.org

EbXML Business
Process Schema
Specification (BPSS)
is currently at
version 1.01 and was
approved in May
2001.

Enterprise Process
Exchange

Application

Footnote 2

UMM - Published by UN/CEFACT, July

2001 at http://www.unece.org and
Wf-XML - Published by the Workflow
Management Collation (WfMC).
Published January 2002 at
http://www.wfmc.org

EbXML Business
Process Schema
Specification (BPSS)
is currently at
version 1.01 and was
approved in May
2001.

Sun ONE Architecture Guide

Interface Name

Level

Status

Reference

Comments

Registry - Repository

Application

Footnote 2

http://www.oasisopen.org/committees/regrep/docume
nts/2.0/specs/ebrs.pdf

2.0 specification was

approved in Dec.
2001.

XML Digital Signatures

Application

Footnote 1

http://www.w3.org/TR/xmldsig-core/

See Chapter 11

Java API for XML

Registries 1.0
(JAXR) (JSR 93)

Application

Footnote 1

http://www.jcp.org/jsr/detail/93.jsp

See Chapter 3.
Supporting
Specifications
Provides an API for a
set of distributed
Registry Services
that enables
business-to-business
integration between
business
enterprises, using
the protocols being
defined by
ebXML.org, Oasis,
ISO 1117

Java API for XML-based

RPC (JAX-RPC) (JSR 101)

Application

Footnote 1

http://www.jcp.org/jsr/detail/101.jsp

See Chapter 3

Table Footnote Legend

Footnote 1: This interface is a standard, and support of this standard is required for products conforming to v1.0 of the
Sun ONE architecture.
Footnote 2: This interface is a standard, but support of this standard is not required for products conforming to v1.0 of
the Sun ONE architecture. Support of this standard will be required in a future version of the architecture.
Footnote 3: A standard interface is being developed for this component, and that standard will be required in a future
version of the Sun ONE architecture.
Footnote 4. This is a published proprietary interface, and support of this interface is required for products conforming to
v1.0 of the Sun ONE architecture.
Footnote 5. This is an unpublished proprietary interface. A published definition for this interface will be provided in a
future version of the Sun ONE architecture.
Footnote 6. This interface is not yet defined. A definition for this interface will be provided in a future version of the
Sun ONE architecture.

For definitions of the acronyms and technical terms used in this and other chapters, see the Glossary at the
end of this book.
For supporting references regarding the topics discussed in this and other chapters, see the Bibliography
that follows the Glossary.

6 Business Process Integration

97

98

Sun ONE Architecture Guide