There are two basic e-commerce architectures maturing, one for interactive consumer-to-business (C2B) applications and the other for business-to-business.
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., e.g. 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 e.g. 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 e.g. 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.
