| Reaching for the Wider World of Ecommerce Abstract
This paper describes ecommerce (electronic commerce) in terms of two fundamental challenges: the challenge of state, and the challenge of semantics. It explains how the ecommerce arena is a much larger, more complex and more diverse landscape than the tame business-to-consumer ecommerce neighbourhood. It explores the issues of system-to-system interaction in ecommerce applications, and the problems of shared semantics for transacting partners. The paper considers EDI and XML as potential technologies for dealing with the semantic gap. It concludes by advancing the case for agent technologies in the dynamic resolution of semantic disconnect. The paper does not dwell on the technical details of EDI, XML or indeed any technology. It is intended to indicate a business development path for enterprises readying themselves for a world of ecommerce that is substantially wider, wilder and rewarding than the constrained applications of today. 1: The state of ecommerce Ecommerce is one of the most discussed, most hyped, and least understood topics of our times. There are lots of good definitions of ecommerce, and they all revolve around the idea of conducting business transactions between remote partners. We'll use that as a basis, but it's worth bearing in mind that much of what we class as 'commerce' doesn't directly involve making monetary transactions. We transact all kinds of values in the name of commerce - but that's another theme, for another day. Most people equate ecommerce with the consumer experience of 'buying something on the web'. This paper goes on to call attention to some other applications of ecommerce, and argues that business-to-consumer catalogue retailing is the tip of the ecommerce iceberg. But we'll start by looking at the technical basis of ecommerce, and its origins in the bringing of state to the web. It's an important place to start, because as we shall see, the key to unlocking the wider world of ecommerce is a concept allied to that of state, which is semantics. (That's about as scary as this paper gets! I promise that 'semantics' is the most exotic word in it.) If you're going to publish, then publish a catalogue The web reached the wider public consciousness as a publishing medium. As software solutions providers began to explore its potential as a true computing platform, they hit their first big problem: the web is stateless. That is, when a client (such as a browser) requests a resource (such as an HTML file) from a server, the server simply throws the resource back at the client. The client and server don't establish a session with each other. In other words, no state information is maintained for the client/server relationship. The industry has developed lots of ways round the problem of short-term state, starting with scripts invoked through CGI, right up to embedded server scripts such as Microsoft's ASP, and Java servlets. It's also solved the problems of long-term state; controversially in the case of cookies, less so in the case of user registration. Ecommerce is often seen as a simple application of stateful web computing. A user finds a site that offers him something he wants. The application behind the site creates some local state so that the visitor can fill his shopping basket as he coasts the store's virtual aisles. It creates some long-term state so that it can remember the customer's address and usage preferences between visits. Problem solved. As long as your technical strategy for preserving state scales to the millions of potential users you're dreaming of attracting, then you're in business. But that's not really what ecommerce is. This kind of mass-market consumer shopping is of course an important part of the ecommerce world. It's what most of us instinctively understand by the term 'electronic commerce'. However, business-to-consumer transactions are only a part of the whole ecommerce picture. They may not even be the most significant part. 2: The business-to-business of ecommerce The majority of transactions carried out in the commercial world are between businesses. Most of them are enacted by people, but they're of a different quality to the transactions people carry out in their private capacities. It's not for nothing that recreational consumer shopping is called retail therapy: few of us would seek to ease our anxieties by ordering stacks of capital equipment for our employers. For a start, when we transact on behalf of an employer, we abide by its decision-making processes, which usually include some obligation to justify our purchases. No one builds a new warehouse because 'it goes with the red trucks we bought last month'. Furthermore, not all business-to-business transactions fall into the catalogue-shopping mode. Many important business goods and services can be well described and sold through catalogues. Arguably, more should be sold this way. But generally speaking, the more complex, individuated or abstract the goods or services under transaction, the more the process shifts from shopping to consultation. We might be happy to order stationery from a website. We're less likely to hire a bank to advise us on a hostile takeover bid on the strength of its HTML skills, or its ability to remember our name from page to page. At the consultation end of the scale, the role of the corporate website falls back to its traditional one of marketing vehicle. It can inform the prospective customer of its services, deliver some useful and relevant additional information, and bolster its brand values. It can't really deliver a complex offering. So if catalogue-shopping is the tip of the commerce iceberg, does that mean that electronic commerce is fated to apply only above the waterline? No. But it does mean that we have to reassess the current capabilities of ecommerce, and begin to explore how new technologies can expose more of the mass of transactions to electronic intervention. 3: Business-to-business means system-to-system Consider two enterprises that have partnered in order to better serve their end customers. Let's make them partners in a supply chain: a small manufacturer and a delivery company. The delivery company has given its partners access to its logistics systems through a web-based system. Partners, such as our manufacturer, can access the system using a login name and password. They can then check on the whereabouts of their deliveries. That's great, until you consider whose business processes benefit the most in this situation. The manufacturer gets quicker access to information, but the delivery company gets to run its disposition queries desk without human intervention. If the manufacturer needs to act on the information he learns from the delivery system, he has to interpret some screen output, and make an intervention in his own systems. He might have to reschedule a process in his own plant, and query the delivery status with a representative at the delivery company. (Who've all been redeployed since the system was thrown open to the partners.) Ideally, we want the manufacturer's systems and the delivery company's systems to converse with each other. We want them to update each other on all the routine stuff as the situation changes at either end. We want them to throw exceptions to some kind of monitoring system that can prioritise problems and alert the correct individuals to deal with them. Essentially, we want floor-level co-operation between the partner companies in the business processes that they have contracted to share. 4: Companies are already wired up to each other Many large enterprises already behave this way - with each other. Vehicle manufacturers and steel producers, employers and their banks - it's not a novel idea. What's different is that the technologies of the *nt*rn*t have brought the potential for such system-to-system relationships within the reach of many, many more players. EDI - the abbreviation for the quaintly-named Electronic Data Interchange - gives way to ecommerce. Except that EDI is, believe it or not, actually the wave of the future. 5: Deconstructing EDI 'EDI' is used to cover at least two aspects of traditional business-to-business commerce. It used to imply the dedicated 'value-added networks' (VANs) that linked up businesses who wished to transact with each other using EDI. Indeed, before the commercialisation of the Internet, EDI the model was meaningless without EDI the transport mechanism. If you had a system spitting out EDI messages, then you needed to be hooked up to a carrier that would deliver them to a remote system capable of digesting them. Today, we can see EDI simply as a candidate representation for structured business data. (Or in fact, since there are many EDI standards, a class of candidate representations.) If we choose an EDI standard, or another abstract model of business data, and we transact messages in it across an Internet-standard network, then we have met - and solved - the Second Great Problem Of Web Computing: the problem of semantics. 6: First state, and then semantics Making the web stateful allows us to conduct sessions and create virtually permanent relationships across the network. But state alone doesn't guarantee that the interactions we engage in conform to any set of meanings. It's as though we can talk (since we are connected to each other), and we can understand the same words (since we can render data intelligibly), but we remain unsure about what many of the words refer to. Imagine that a web page shows me a table of items that I can buy. It's likely that the columns will be labelled with attributes such as size, colour and price. Each row might contain a different product in the range. I understand the semantics of the offers through the layout and the labelling, and the implied comparison that the table makes. But now imagine that it's not a human who is reading the web page, but another system. Maybe it's not even rendered as a web page, but it's some other kind of resource containing products, sizes, colours and prices. How does the client system interpret the server system? 7: Agree, or be told There are basically two ways of solving this problem. The first solution involves the two system owners agreeing on a shared definition of the data they will transact with each other. They might design their own shared representation, or sign up to a model that has been standardised for their industry (if they share an industry). They might sign up to an EDI variant. This works well as long as The second solution involves the transactional stream taking the responsibility of describing its own meaning. A transaction might begin with a manifest that describes its structure and appoints a label to each subsection of the stream. The receiving system can then compose a container to collect the data as it arrives. This is really a marshalling/demarshalling strategy, and is as old as data transfer itself. It's also a false solution. Self-describing data still leaves the receiving system with the problem of interpreting the meaning of the incoming data. There's no other way of doing this than by referring to a model that the receiving system has already adopted. 8: XML alone is not enough XML is the current high-point of self-describing data strategies for the Internet-enabled world. XML brings semantics into web-based computing, and it is going to have important consequences for developers of web-based systems. XML - very roughly - is a markup language that allows authors to include meaningful tags within documents, rather than tags purely concerned with the document's rendering. So, instead of using an h1 tag to mark a heading, we might use a product tag for the same item. A stylesheet would then map product tags to h1 tags for the purposes of rendering in a browser. The key is that the meaning of the data item is declared and preserved, rather than lost in the process of displaying it for the human reader. The semantic structures of XML documents are described in DTDs - Document Type Definitions. A DTD can be a standalone document or a constituent part of an XML document. For most practical purposes, the standalone DTD is the most significant, since it allows many dispersed documents to refer to the same semantic structure. We can think of a DTD as being a shared semantic model which transactions can reference. However, for the purposes of true ecommerce - that's business-to-business, system-to-system - XML is not the total solution. We can be sure that people will use XML to implement ecommerce systems: it's a natural way of preserving data structures and exposing them to rendering, searching and totalling behaviours at the client side. We can also be sure that there won't be one true, trusted, ubiquitous DTD for ecommerce. We're likely to see a proliferation of candidate ecommerce DTDs that makes the plethora of EDI standards look manageable. 9: Our agents are armed They're not trendy any more, but their day is here: agents, or bots, will make the wider ecommerce world work. Intermediary goal-seeking agents will negotiate semantic gulfs amongst potential commerce partners. Where buyers are unable to find suppliers, or don't know where to look, agents will gently probe the interfaces the buyer exposes to the marketplace, evaluate these against the buyer's goals, and line up prospective suppliers based on its market knowledge. It may make use of other, more specialised agents to complete the transaction path. It may present alternative resolution paths, prioritise and price them for the decision of the buyer (or another of the buyer's agents). Intermediaries and arbitrageurs will set their agents to explore the connected world for market opportunities. These agents will pitch stalls where they find nascent opportunities, choosing their territories by inference. They may be licensed by their owners to make loss-leader offers to attract new business. They may be empowered to identify transactional opportunities, pump them dry, and then self-destruct. 10: Timeline Business-to-business, Internet-based ecommerce is a growing marketplace. XML is a maturing technology which is well placed to absorb or succeed EDI. The likelihood of a single DTD for ecommerce is vanishingly small. Existing agent technology is well advanced and will translate readily to the XML world - indeed, we could argue that XML has been defined precisely to make the agent's life easier. Expect ecommerce agent services to appear in late 1999, and to start making a real impact in 2001. 11: Conclusion Commentators, marketers and entrepreneurs are right to see the Internet's greatest future impact as being in electronic commerce. That impact won't just be created by a simple expansion of consumer catalogue shopping. The world of commerce is migrating to the network. It'll take some time to get there, and it'll need appropriate soft analogues of the intermediaries who lubricate the physical commercial world. These intermediaries will manifest themselves as intelligent agents. The lessons of EDI's role in bringing shared semantics to business-to-business systems, and the breaking technology of XML, point the way towards a network-centric, semantically-live ecommerce environment.
|
© 1999 Paul May