|
eBusiness through EIP and XML
|
 |
 |  | Find |
|
Abstract
|
No abstract was provided for this paper.
|
Contents
|
eBusiness and XML
When people think about business to business communication they often
have machine-to-machine communication in mind. However, we believe there is
more to eBusiness than simply connecting one's internal systems with those
of business partners. For the purposes of this paper, we want to introduce
a different way of looking at eBusiness.
|
|
|
|---|---|
| Transaction oriented | Building connectivity
between an enterprises business systems and the ones of my customers and suppliers,
as well enabling secure and reliable (XML based) messaging lies at the heart
of modern B2B machine to machine oriented solutions. Often you will see this
combined with ability to define and execute complex business procedures based
on configureable inter- and intracompany workflows. |
| Document/content oriented | Document/content
oriented B2B exchange of design drawings, contract negotiations, RFQ, RFP
and RFI development etc. Typically these sorts of operations are conducted
between human participants and involve collaborative work on unstructured
content. Secure and personalized access is of utmost importance in such environments. |
| Business intelligence oriented | Very often
human beings will be involved and have to make quick and informed (!) decisions
to allow a business process to continue smoothly to the next step. High performing,
secure and reliable machine to machine processes are of importance, but what
is the point of high transaction throughput between machines, if the human
being(s) involved take hours/days to do their part? |
A true eBusiness strategy, we believe, will have to take these and many
other aspects of business interactions in order to truly exploit the capabilities
of Internet-based electronic commerce. The following sections will outline
some of the components that, we believe, are necessary for a comprehensive
eBusiness strategy based on XML and related standards.
Previous
Table of Contents
The XML backbone
eBusiness does not start with the pretty-face of a shopping cart application
or with sending around lean XML messages. The real work starts at the heart
of your enterprise. Two important factors,
Building re-usable infrastructure
A typical enterprise will devote 35 - 40% of its programming budget
to develop and maintain‘extract and update’ programs whose purpose
is solely to transfer information between different databases and legacy systems.
(Gartner Group)
Figure 1
To a large extent this problem stems from the fact that developers have
to provide mappings between all the proprietary systems. XML will help us
to build a reusable infrastructure in which, instead of building all the point-to-point
connections, we will be able to only deal with one uniform XML-based abstraction
layer.
Figure 2
Legacy data integration
Only a comparatively small amount of all corporate data is readily available
in database systems and the like. The vast wealth of corporate intelligence
lies in e-mails, pictures, documents and other such data formats. The integration
of these sources and the systems that manage these source is of strategic
importance.
Many of the systems to be considered will not be ready for integration
into web-based delivery. Very often they will have to first be prepared for
delivering XML content and hooked up to some transport infrastructure.
The vision of the XML backbone is one where all relevant corporate data
and metadata (we can't forget about our blobs after all) is being passed around
between systems and humans using XML-based structures. All legacy systems,
databases, content management solutions etc. are being integrated into this
conceptual enterprise-wide layer.
It is important to note that the XML backbone does not make any assumptions
about underlying transport protocols. Whether your environment is based on
http, FTP, some message-oriented middleware (MOM), DCOM, CORBA etc. does not
matter. What is important, is that all the data is XML-based, instead of some
mix of proprietary data formats, like it is often the case today.
XML-based EIP
XML-based EIPs are natural consumers and participants of the XML backbone.
While the XML backbone provides the data and metadata necessary for the portal,
the portal itself regulates secure and personalized access to this information
provided.
Typically, XML-based EIPs will use XML in at least three different ways
:
|
|
|
|---|---|
| XML for data | This ties nicely into the XML
backbone. Having all of our data exposed in XML is a strategic imperative
(where it makes it sense). This not only helps to build better portals, but
also to build better IT infrastructure. |
| XML for metadata | Not all data in an organization
will be XML. We can, however, use XML-based meta-content descriptions to describe
relevant information about the blob items we are interested in managing. Of
course, this metacontent still also applies to XML-based content. |
| XML in the EIP | In a truly XML-based portal
not only the managed resources (and their metacontent) of a portal will be
managed through XML. The software itself will be based on using XML to provide
internal datastructures and abstraction layers. This internal datastructures
(including access control list and user interface controls), once exposed
through XML, create - in conjunction with XSL/CSS stylesheets - a unique user
experience for the customer. Not only for HTML but for any other conceivable
output format. |
EIP functionality
Enterprise Information Portals, whether they are used in an Intranet
scenario to bring information to employees or in an Extranet/e-business scenario,
have a certain set of minimal features.
|
|
|
|---|---|
| Categorization | An EIP needs to provide a configureable
taxonomy (a hierarchical view of all Enterprise data resources). End users
need to be able to introduce their own categorization schemes. |
| Personaliczation | The set of information that
one user works with is not necessarily appropriate for another. Thus, the
system needs to slice and dice data to optimize access for each individual
end user. Also each user (or group of users) has their own ideas about how
the user interface has to be designed. Good personalization allows to control
this on a per user as well as per group bases. |
|
|
|
|---|---|
| Publishing | Everybody can publish. It is of
utmost importance, that everybody, from the worker to the CEO can easily contribute
content to the system (at best in a straightforward drag and drop fashion).
The WebDAV specification appears to be an ideal candidate for a supporting
protocol in the area. |
| Collaboration | We live in a team-oriented environment,
both as internal teams as well as in conjunction with our business partners,
we work collaboratively on tasks. EIP technology needs to help promote such
activities. WebDAV comes in very handy, again. |
| Extensibility | Every customer is different.
Using XML and XSL technology consistently throughout the system allows a portal
vendor - if supported by the sofware - (or any other software vendor, for
that matter), to provide the highest degree of customizability ever. |
| Scripting | The best system cannot anticipate
all rules and extensions a customer wants to see. Server side scripting and
powerful APIs allow to better trim the system towards the requirements at
hand. |
| Notification | It would not be very efficient
if the user of a portal system had to check periodically for updates to existing
content or this arrivale of new information. The portal itself must know about
what is relevant for the user and pro-actively send notifcications which inform
the user about a state change is the system. |
Extend your enterprise
The browser has long lost its status as the most important means to
get access to information. While it still is one of the primary means, a whole
new set of devices are emerging on the horizon. Cell phones, PDA, car based
systems etc. reflect the demands of a modern - very mobile - workforce.
XML to the rescue
Where would we be without XML? Really in trouble, likely! Each of these
new devices has its own ideas and requirements of how data should be structured
to best suite its needs. Imagine what hustle it would be to translate from
the proprietary data formats of your backend systems to all the individual
output formats of mobile devices such as WML, HDML and HTML (just to mention
a few). Actually, also the data formats for output devices would likely be
very complex as well.
Figure 3
The complete picture
In the graphic below you can see what an overall combination of XML
Backbone, XML based EIP and delivery to various output devices can look like,
from an architectural perspective.
Figure 4