Professor Martin Healey on evolving e-business
There are two basic e-commerce architectures maturing, one for
interactive consumer-to-business (C2B) applications, and the other
for business-to-business (B2B). There are of course many variants,
refinements, and combinations. B2B applications can be interactive,
but most involve some interaction between business applications
over a network. These latter ones are usually based on messaging
services. Some are point-to-point, but many are in effect the new
generation of EDI, and as such are networked (many-to-many). This
class of systems must also have a service provider to handle the
translation and distribution of messages.
The core technical architectures are now in place, using Web
browser technologies for interactive C2B, and transaction messaging
technologies for B2B. The relational database is still the common
back-end.
The basic C2B architecture is a thin client one with an
'Application Server' providing the business-logic between the
browser client and the database. This could be based on existing
transaction techniques, but instead a new generation of Application
Server platforms has been created, some based on proprietary
Microsoft technology, but most on server side Java systems. B2B
systems are maturing around XML based services, which interface to
existing applications by extracting data at one end, and posting at
the other. With the aid of specific Schema and API, the B2B service
is becoming standard, although the interface to the existing
applications will always need specific attention.
With these architectures becoming defacto standards, there has
also been some healthy progress with development tools. The lower
level programming tools such as C, VB, Java, etc are supported, but
there are some higher level development systems akin to older 4GL
techniques which can generate Java, etc eg Aptivity, SilverStream,
Cold Fusion, etc, as well as tools around WebSphere, WebLogic, et
al. There are tools for editing and testing XML and Schema as well,
eg StiloWebWriter.
And so most organisations are already involved in the use of
some of these systems to develop their own e-commerce applications.
But in the same way as normal business applications were either
developed in-house or implemented using a 'package', the same thing
is happening. Again there are various flavours. Some are packages
in the established sense, targeted at specific requirements, but
others are more flexible, and fit in at a level above a 4GL
concept. In particular, they provide the infrastructure and
libraries of re-useable components, in order to make implementation
easier and quicker. Some of these are high profile, such as
Commerce-one, Ariba, i2, etc, because they are being wooed by IBM
et al to port their system to WebSphere, or whatever.
But there is a potential problem. All these higher level systems
were developed to get to market as quick as possible. Most, in
fact, were derived from applications built for specific customers
(or specific industrial sectors such as banking). While the product
is usually based on the now accepted architectures mentioned above,
there were no core products or standards available beyond an NT
Server or a Java Virtual Machine. As a result, each product had to
provide the more comprehensive run-time support, such as a Java
component manager and transaction recovery services. All had to
provide 'adapters' to handle the specific features of the databases
in use, eg Oracle, DB2, Sybase, etc.
The current proprietary nature of these e-commerce systems is
not a criticism, because at the time they were developed the
standards were incomplete. It is the next phase that is more
critical. Key to the future is Enterprise Java Beans (EJB). The
current EJB version 1.0 is not comprehensive enough to provide all
the run-time functionality needed, so that there must still be
proprietary features. However, version 1.2 is due now, and version
2 by early next year. By mid 2001 there should be a satisfactory
range of products providing full EJB services. What is needed then
is the development environments, component libraries, and the
application level products, but not the run-time.
It is clear that most companies producing Application Servers
and higher-level application tools are porting their products to
EJBs, but it is difficult for a company which has developed its own
run-time systems in the early days to throw them away. It requires
some serious repositioning of the current companies. Those who can
bite the bullet and eliminate their own run times will survive,
those who can't will drag themselves down. This in turn means
further blurring of the distinction between companies with a focus
on development environments, and those who focus on applications.
IBM, Microsoft, BEA, et al, will obviously favour those who can add
value to WebSphere, etc.