![](bg4.png)
how the architecture enables full automation;
business processes are described in a machine-
readable document, which is executed by the BPE.
The machine-readable document is generated at
build time through a process definition tool. Of
course, there are cases at this level that human
intervention may be inevitable, hence the inclusion
of the document-based worklist browser as an
element of the architecture.
Integration at business process level is attained
because of the fact that the BPE operates with users,
applications and trading partners in a transparent
manner. This is feasible due to the existence of the
CMS that is responsible for invoking the necessary
applications for the accomplishment of a business
process, as well as the existence of the B2B engine
that hides the communication and B2B protocol
details from the BPE. As a result, the BPE can
efficiently execute end-to-end processes, since the
B2B transactions are integrated with the internal
enterprise activities. Also, regarding integration at
the application component level, it is reminded that
this is addressed in the architecture by an EAI
implementation based on the principles of the
NGOSS framework. As far as data integration is
concerned, this is achieved through the
transformation mechanism described above.
Flexibility at process level ensues from the
abstraction of the business process flow into an
entity separate from the components themselves. As
a result, business process steps can be easily
rearranged or altered, since the only action required
is to update the process definition document. The
underlying component interactions will be
automatically reconfigured. As far as data format
transformations are concerned, the transformation
mechanism we mention in the next section enables
also run time transformations. Finally, in a NGOSS
infrastructure, new components can be easily
embodied into the infrastructure and communicate
with the already existing applications via the
common communication vehicle. Due to this
abstraction, components can also be re-used across
multiple business scenarios.
4 ENABLING TECHNOLOGIES
The key enabling technology for the architecture
presented in the previous section is the eXtensible
Markup Language (XML) (Bray et al, 2000). XML
can help (a) to automate the execution of business
processes, and (b) to form the foundation for both
EAI and B2B integration.
Automation of business process execution is
enabled by the fact that XML-based business
process definitions are machine-readable and thus
can be executed by a BPE. More specific, XML acts
as the bridge between the human-readable versions
required for modeling activities and the machine-
readable versions required by the run time
environment, filling thus the gap between business
processes and application components. Currently,
there are various XML-based business process
definition languages, such as the Business Process
Modelling Language (BPML) (BPMI, 2001), Web
Services Flow Language (WSFL) of IBM
(Leymann, 2001) and XLANG of Microsoft (Satish,
2001). Also, ebXML (2001b) has defined a Business
Process Specification Schema (BPSS) (ebXML,
2001a) that provides a shared view of the
interactions between trading partners regardless of
the actions that lead to any particular interaction.
The issue here is whether each of the three business
process definition languages suffices for the
description of an end-to-end process or they will
have to include BPSS for the implementation of
B2B collaborations. As a matter of fact, BPML,
WSFL and XLANG do not support basic business
notions such as mutual non-repudiation and
authentication between parties. Nickull et al (2001)
present how BPSS can be bound to each of the three
leading business process specification languages
(BPML, WSFL and XLANG).
During the execution of the business process, the
BPE communicates with the CMS, which in turn
invokes the appropriate components. At the
application components level, messages sent by the
BPE are transformed into an appropriate format, for
example into CORBA IDL. An efficient
transformation mechanism that can be used for such
transformations is XSLT (Clark, 1999). XSLT is
used for the transformation of an XML format to
another XML format, to aware non-XML or to any
arbitrary format (Holman, 2000).
As far as integration is concerned, XML is not an
integration solution in itself – it is just a definition
language, as explained earlier. For XML messages
to be interpreted by other companies, both trading
parties need to agree on common XML-based B2B
standards, which will specify the document
structures and the process descriptions. Such
standards have already been developed by various
B2B initiatives. Two major B2B initiatives are
RosettaNet and ebXML (2001b). Hence, the B2B
engine must be able to support any B2B protocol so
as to provide for more flexibility.
For EAI, a candidate XML-based technology is
Web Services (Fremantle et al., 2002). Web
Services enable interoperability via a set of open
standards such as WSDL (Web Services Description
Language), SOAP (Simple Object Access Protocol)
and UDDI (Universal Description Discovery and
Integration).
MANAGING INFORMATION FLOW DYNAMICS WITH AGILE ENTERPRISE ARCHITECTURES
457