An Architectural Framework for Electronic Commerce Applications L. Fiege, G. Mühl, A. Buchmann {fiege, gmuehl}@gkec.tu-darmstadt.de,
[email protected] Department of Computer Science - Darmstadt University of Technology 64283 Darmstadt, Germany
ABSTRACT Electronic commerce applications have been developed as a reaction to specific business opportunities. Their architectures, so far, have been dominated by implementation concerns, without much consideration given to the cooperation model. In this paper, we describe an application independent framework to classify service interaction. It relies on four basic dimensions service topologies, cooperation models, implementation techniques, and quality of service. The framework is applied to some typical e-commerce scenarios. We conclude that most existing implementations rely on a tier-based client-server architecture disregarding the actual demands of the underlying application. The presented framework helps to identify the essential structures of applications and facilitates robust designs by successively looking at basic cooperation characteristics, different levels of abstraction and implementation issues. Keywords: Electronic Commerce, Cooperation Models, Implementation Techniques, Event-Based Cooperation
1 Introduction The explosive growth of many e-commerce applications has been dominated by the need to minimize the time to market. Unfortunately, this has lead to systems being crafted with whatever means are available at the moment rather than being properly engineered for scalability. Many of the resulting systems have become victims of their own initial success and have run into robustness and scalability problems that finally required either a major redesign and redeployment or caused the demise of the systems (and the companies running them). A typical case in point are information dissemination systems, such as PointCast, that faded after an initial boom because their resource-intensive information delivery mechanisms on the client side caused companies to ban their installation. This example leads to another major factor characterizing the Internet-economy: the change towards an user-centric
model, changing the focus when dealing with the delivery of data, information, and services. In the Internet-economy the view of data and information flowing freely from sources to sinks and being consumed in unanticipated ways is becoming more and more accepted. Traditionally, data has been viewed as stationary in a repository, such as a database, with inquiries directed to the system in a request/reply mode of interaction. This shift in how data in networked systems is viewed has a major impact on the mode services interact. While in a static view where data is stationary at a node a request/reply interaction is adequate, an event-based interaction better supports user-directed information flows. In this paper we show that a clear distinction between service interaction and the underlying implementation is possible and a necessary first step towards the engineering of robust and scalable e-commerce solutions. The same pattern can be observed at each level of abstraction in a complex ecommerce system: at the application level, the applicationoriented middleware layer, the middleware platform, down to the actual backend servers. In Section 2 we introduce the framework to classify service interaction. In section 3 specific examples of e-commerce applications are addressed and classified in order to illustrate mismatches between current implementations and inherent architectures. We show that event-based cooperation models emerge as good candidates for a variety of demanding, large-scale e-commerce applications. Section 4 discusses the cooperation primitives and the implications of the use of the framework on system design. Section 5 presents conclusions and addresses future work. Pointers to related work are given at the corresponding place.
2 Categorization of Service Architectures In the following we present a framework that refines the one presented in [21] and that allows to categorize service architectures. We consider four dimensions: service topologies, cooperation models, quality of service, and implementation techniques.
2.1 Service Topologies Cooperation Model
In a service-based architecture there arise dependencies among services resulting from cooperation. Two services may depend either unilaterally or bilaterally on each other or they are independent of each other. Moreover, transitive dependencies arise from intermediary services. If a system is designed strictly using services exhibiting unilateral dependencies, a tiered architecture is the result. Tiered architectures provide a clear layering of functionality at different levels of abstraction. Strict layering greatly reduces the number of service dependencies but it can seldom be achieved in pure form. If a system is designed using services that exhibit bilateral dependencies, a peer-based architecture is the result. Peer-based interaction frequently occurs at the same level of abstraction. Hybrid topologies are common. In these architectures, tiers that represent the various levels of abstraction in a system are clearly identifiable. However, each tier may be implemented recursively with tier- or peer-based services.
2.2 Cooperation Models A cooperation model describes the way interdependencies are established by cooperative (inter-)actions. We identify two basic roles services can play: consumers and providers. The former depend on data or functionality provided by the latter. As one major characteristic of a cooperation model we consider whether the cooperation is initiated by the consumer or by the provider. The second main distinguishing fact is whether the initiator uses direct or indirect addressing. Initiator = Provider: The provider initiates the cooperation and sends information about its own state. Therefore, it makes no assumptions on the consumer’s functionality separating their respective functionality and sustaining loose coupling. Initiator = Consumer: Here, the cooperation is initiated by the consumer that requests data or/and functionality from the provider. The state of the consumer is of no interest to the provider, because any requested functionality is not affected by further state changes of the consumer. The consumer depends on the provider’s state resulting in tight coupling. Addressing = Direct: The initiator of a cooperation primitive specifies its counterpart. In this case the former can incorporate information about the identity of the latter into its own functionality resulting in tight coupling of the cooperating services. We do not consider the number of responders, because it is not relevant to the characterization. Addressing = Indirect: The initiator of a cooperation primitive does not specify the responder(s). Instead, the ac-
Initiator
Addressing
Specific Request/Reply
Consumer
direct
Anonymous Request/Reply
Consumer
indirect
Callback/Logging
Provider
direct
Event-Based
Provider
indirect
Table 1: Cooperation Models tual responders are chosen transparently to the initiator. This facilitates a detachment of functionality and service interconnection resulting in loose coupling. The conceivable addressing schemes include groups as well as subject-based [23] and content-based addressing [14]. The combination of two basic properties initiator and addressing lead to four cooperation models (see table 1) which are not influenced by any implementation techniques. 2.2.1 Specific Request/Reply Initiator = Consumer
Addressing = Direct
The basic cooperative actions of many client/server systems and object platforms belongs to the specific request/reply cooperation model. The initiator issues a request to a specified responder, conveniently the services can be called client and server. The server processes the request and passes back a reply that corresponds to the initiating request. This means that requests and response are matched in pairs. Specific request/reply is mainly used to delegate subtasks to servers. The client depends on the server’s functionality resulting in a tight coupling. In contrast, the server does not rely on the client, it merely uses the data embedded into the request as parameters to perform the requested function. A reply composed by a server refers to the context of the request which is known to the client. Other parties are not able to interpret the reply without the request. Request/Reply is also often referred to as demand driven computing because a server only acts on demand of a client, or as pull-based information dissemination [10]. Specific request/reply is widely used today because it is simple and well known. It can be easily mapped to various low-level primitives (e.g. remote procedure calls, remote method invocation, or messaging implementations). Although the cooperation model does not force the interaction to be synchronous, request/reply has been used mainly in synchronous mode. Recent developments facilitate asynchronous request/reply (e.g. CORBA AMI) to relieve some disadvantages of synchronous interaction [25].
2.2.2 Anonymous Request/Reply Initiator = Consumer
Addressing = Indirect
The anonymous request/reply cooperation model also uses request/reply as basic cooperative action but the client does not specify the server that should process the request. Instead the delivery to the appropriate server(s) is done transparently. One request can be forwarded to an arbitrary, dynamically changing set of servers. This offers added flexibility and facilitates a looser coupling. One request, however, can result in an unknown but fixed number of replies which can be handled in various ways. Several possibilities exist to handle the replies: any subset of the replies can be handed to the client ranging from one reply (single or integrated), a subset of them (k out of n) to all of them. Of course the clients must be able to handle multiple replies and policies for integrating replies must be defined. On the server-side policies can also be specified that define various properties of request consumption. 2.2.3 Callback Initiator = Provider
Addressing = Direct
In a callback-based system consumers registers at a specific provider to be notified if some condition becomes true. The provider continually evaluates the condition and initiates a callback if necessary, notifying the client. Moreover, the provider is responsible for administering its callback list which is used to address consumers specifically and separately. A single registration causes an unforeseen number of future notifications. The registration has to be cancelled explicitly or alternatively leases can be used to avoid further notifications. To choose the appropriate provider the consumer must know which service supports its interests and how to describe it. If multiple callback services are of interest, a consumer must register separately for all of them. The consumer can exploit knowledge about the offered callback to keep the registration simple because it knows the specific provider. Although the knowledge a provider has about the consumer enables customization, typically only simple interests (e.g. stock symbols or “yes/no”) are supported. In any case, a sophisticated implementation of callback-handlers in terms of adaptability and constraints on callback invocation leads to the event-based approach that is described next. 2.2.4 Event-Based Initiator = Provider
Addressing = Indirect
When using the event-based cooperation model consumers and providers do not specify their counterparts: consum-
ers announce their interests through subscriptions without specifying a provider. Reversely, producers publish undirected events without specifying a consumer. The events relate to the state of the provider only. Moreover, providers make no assumptions about actions triggered by the published events nor do they await a reply. A consumer can receive events of many providers because a subscription is in general neither directed nor limited to a particular one. If a produced event matches the subscription it is delivered. It is important that a consumer specifies its interest precisely to avoid the delivery of irrelevant events. Providers are not aware of the consumers. In contrast to the callback model the provider are relieved from the task of interpreting and administering registrations i.e. subscriptions and can limit themselves to their actual task of publishing events. This greatly simplifies the structure of producers but favors complex subscriptions. Because it is not known what events are of actual interest it is essential that all potentially interesting events be published. The event-based model introduces new degrees of freedom. Event-based systems are loosely coupled and minimize dependencies among services. On the other hand, because of the missing knowledge about their counterparts cooperation among services is only feasible if supported by a sophisticated infrastructure.
2.3 Quality of Service A number of parameters in different subdomains such as Synchronization, Transactions, Reliability, Security, etc. further constrains cooperation. These are orthogonal in the framework and we do not consider them here due to space limitations. A detailed overview of the realization of quality of service demands in conjunction with cooperation models is given in [21].
2.4 Implementing a Cooperation Model At a given level of abstraction a cooperation model is realized using the functionality offered by the next lower level. The latter provides the necessary implementation techniques. This relationship can be recursively identified on all levels of abstraction. A cooperation model can be implemented with various techniques which may have different properties with respect to QoS and scalability. For example, remote invocation mechanisms, such as remote procedure call (RPC) and Java remote method invocation (RMI) constitute a particular bundling of invocation, termination and synchronization semantics. The same semantics can be implemented using message passing. What combinations are appropriate depend on the application and the environment in which it is
deployed. Similarly, an event-based cooperation can be implemented using message passing or it can be based on remote invocation mechanisms. The former is more flexible but less comfortable, while the latter is easier to handle but will exhibit limited scalability. The cooperation model is induced by the application’s architecture while the implementation depends on the intended use.
3 Classifications of EC-Applications In this section we will analyze and classify a set of representative e-commerce applications in order to elaborate on the applied and the inherent cooperation models.
3.1 Catalog-Buying and Procurement Catalog-buying and procurement are examples of B2C and B2B electronic commerce. They use ‘classical’ client/ server systems with tier topologies (DB-server, application server, GUI frontend). Users browse through article categories or utilize search engines to find the product of interest, and information about pricing and availability. The cooperation is specific request/reply, the initiator is the client. Further support for the customer will likely use customization techniques to increase the value of the service. Asynchronous notifications about product availability and offers provide a higher value to the customer than repetitive, possibly pointless requests. Here, a request/reply cooperation model is no longer feasible and a callback or an event-based model is necessary. Any hidden customer-side polling that essential applies request/reply limits scalability, as the examples of the channel definition format (CDF) and Pointcast showed [10]. If user profiles are clustered to groups of similar interests, event-based cooperation might be applicable, depending on the granularity and the number of these groups. If a small grained customization is pursued, delivery is not anonymous and a callback cooperation model must be used.
3.2 Electronic Markets Electronic markets are an extension of the catalog-based procurement mentioned in the previous paragraph and provide a generalized functionality. Although similar solutions can be applied they must be extended to account for the inherent n:m interactions. Marketplaces bring together an arbitrary set of buyers and sellers. Moreover, electronic marketplaces often facilitate transactions that involve logistics, settlement, and trust issues [3]. Service and product descriptions with corresponding offers/requests might be available via smart catalogs [17] or brokers. We consider two functions of electronic markets, requesting offers and placing orders.
Requests by potential buyers are directed to sellers and result in offers, applying an anonymous request/reply cooperation model. A buyer can use an anonymous request to ask for offers which are essentially replies matching his request. In a second round the buyer could use specific request/reply to do further negotiation. The implementation of the first round could be based on a broker and a remote invocation mechanism, or a sophisticated publish/subscribe technique is used which corresponds to an event-based model where a buyer publishes her interest to buy. The market model of stock exchanges is based on a more liquid market. Matching of supply and demand in one place facilitates price transparency and extends the breadth of a market. Buy and sell orders are placed into an order book and they are matched according to the underlying market model. Placing orders follows an event-based cooperation model but can be implemented using remote invocation. Information about the current state of the order book, however, is crucial for the market participants. The delivery of this information also follows an event-based information model, but due to the high information load a feasible implementation should use publish/subscribe or multicast technique.
3.3 Information Dissemination Applications Stock quoting, news tickers and many other applications are about dissemination of a data item to many interested parties. An event-based cooperation model meets the requirements of this class of applications perfectly. Unfortunately, today stock quoting in a non-professional context is mostly realized using the specific request/reply cooperation model. If tracking of a certain stock or a portfolio is done, the client periodically polls for new quotes regardless whether or not new quotes are available. This approach is induced by the available implementation techniques (e.g. remote invocation, HTTP). An exemplar of refining implementation techniques while retaining the cooperation model are content delivery networks. For example, the NASDAQ stock exchange pushes graphical data onto a network of servers (from Akamai [2]) to reduce load of their web servers. A notification infrastructure is needed to realize this, in turn mirroring the inherent event-based model. In fact, professional trading partners may participate in an event-based notification system as it is used by the Xetra system of the German Stock Exchange [8]. Decreasing IT costs and increasing interest in online brokering demand a solution for the ambitious private user [18].
3.4 Auctions and their Generalizations Auctions are a classic way to search for buyers and are a main matching mechanism in electronic markets [5, 19].
They are becoming popular both in private and in business environments [24]. In a classical auction a seller announces a binding promise to deliver the good to the highest bid; in reverse auctions buyers announce to buy on the lowest bid [27]. In the following we consider only the classical case because they do not differ in respect to a classification of service architecture. C2C and B2C auctions mostly use the specific request/reply cooperation model in a tier-based topology. A bidder requests information about new bids and issues a higher bid if necessary. In order to automate the auctioning process an event-based approach facilitates the natural interaction pattern of auctions in that the participants react to published/announced new auctions and to new bids. Since in a B2B environment the participants are probable known a priori a message passing implementation technique may be feasible there (resulting basically in a callback model). But in most cases the fact that an auction operates in a closed group of known participants is not of interest to the actual auctioning application. Instead, it is a constraint that is determined at a higher level of abstraction. An eventbased cooperation may therefore be applicable here, too, if the respective grouping mechanisms are provided. In [4] an infrastructure for ‘meta-auctions’ was introduced which utilizes a publish/subscribe-infrastructure to enable searching and bidding for offers on different auction sites.
3.5 Virtual Enterprises Virtual Enterprises (VE) are fine exemplars of serviceoriented computational infrastructures. The basic distinction of the underlying cooperation models is important, and we considered VEs in [21].
3.6 Workflows In all of the previous examples only subsystems are sketched. They are part of an organization’s IT infrastructure, and workflows combine the different processes [12]. Since the framework presented in section 2 only relies on very basic distinctive characteristics, it can also be applied to workflow definitions. It helps to characterize the basic model of process interaction and, therefore, facilitates design and reconfiguration of a workflows.
4 Implications on Application Development In this section, we analyze the implications of the framework on the development of applications. The framework identifies a basic set of cooperation models that can be recursively applied at different levels of abstraction, utilizing primitives of the next lower level. Therefore, explicit, appli-
cation-independent primitives that support a specific cooperation model and offer efficient abstractions seem to be necessary. The design of large e-commerce applications will become more enduring if the fundamental model of cooperation, which varies only infrequently, is identified and explicitly leveraged by cooperation primitives.
4.1 Cooperation Primitives Cooperation primitives provide the functionality and the corresponding QoS of a cooperation model. They represent convenient abstractions that avoid that a cooperation model of a given level of abstraction is implemented directly with primitives that have too low a level of abstraction and may not properly support a given cooperation model. RPC is a prime example of a cooperation primitive: it provides the functionality of a function call that is transparent with respect to location; it further provides marshalling and unmarshalling functionality. RPC has well-defined begin, end, and synchronization semantics. RPC can be regarded as one possible cooperation primitive that is particularly well-suited for the realization of a request/reply cooperation model (although it is not limited to that cooperation model). Remote Method Invocation (RMI) can be regarded as the object-oriented counterpart to RPC. As an example of convenient cooperation primitives in the area of event-based systems, we can cite coupling modes [7]. Coupling modes specify the begin and termination semantics of triggered transactions in event-based transactional systems. Although they could be regarded as syntactic sugar because they are expressible in terms of more basic constructs, such as method-invocation events, BOT (Beginof-Transaction), and EOT (End-of-Transaction) events, they have become established concepts with generally understood and accepted semantics. The approach of providing generic functionality that can be composed into more sophisticated services or facilities is pursued in CORBA [22] and Java/EJBs for the request/reply model. The event-based model of cooperation, although known for a long time [16], has gained renewed interest recently [1, 15, 13, 20, 23, 26] but lacks well-structured, generic primitives.
4.2 Influencing Design The influence on design is twofold. First, the APIs between the layers of abstraction will additionally focus on cooperation models. And second, robustness of design will be improved. The effects of a mismatch between the primitives supported by the middleware (lower level of abstraction) and the requirements of the application developed on top of it (upper level) has been convincingly shown in [9]. To avoid
3. coop. specific interface Interface
Technique
2. induce interface
Interface 1. prescribed interface Fig. 1 Different ways to design cooperation primitives
such a mismatch, it is important to analyze how the primitives are derived. Figure 1 identifies three different ways: 1. No explicit cooperation primitives are available in the upper layer. The interface which is provided by the implementation techniques is used, and often hard-wired in the application. 2. An analysis of the techniques is used to determine the functionality and semantics of the primitives which are defined in the upper layer. 3. An analysis of the cooperation model yields, independent of a specific application, the generic primitives that are reasonable and feasible on this level of abstraction. We do not consider case 1. The second case (bottom-up induced design) is often used today, a misconception in our view that is the result of selecting a middleware platform and then shoehorning the applications onto that platform. An analysis of the techniques yields an understanding of which cooperation semantics are feasible to implement [9], but the feasibility is additionally determined by the specific environment (WAN/LAN, number of nodes, available network protocols) in which it is to be deployed. Therefore, the second case is not able to cope with different or changing environments. The third case is motivated by the framework presented in section 2 and distinguishes between a cooperation modelspecific design of generic primitives and deployment-specific constraints of the underlying implementation techniques. The primitives are determined by the characteristics of the cooperation model and the considered level of abstraction alone. The possible implementation techniques are constrained in a second step when the environment is known. In this way, the selection of primitives may be affected but not their design, yielding a separation of cooperation and implementation issues.
This discussion leads to the second influence of the framework on application design: it will become more robust and enduring [6]. Since the framework relies on very basic characteristics only, a classification made during design is not likely to change. In an implementation that follows this design and uses the specific primitives the deployment-specific part is more easily exchangeable than it would be if two cooperating services or two layers do not firstly agree on the basic cooperation model. This approach resembles design patterns [11]. The patterns identify functional parts and their interaction. Behavioral and communication patterns describe the interaction, resembling cooperation models in their intent to characterize cooperation, but issues of cooperation and implementation techniques are typically confused.
5 Conclusion In this paper, we presented a framework for categorizing service architectures, which are common in e-commerce applications. The framework consists of four dimensions: topologies, cooperation models, implementation primitives, and quality of service. Essentially, the basic characteristics of (specific) request/reply and event-based cooperation are identified. The framework relies on very basic characteristics and emphasizes the essential structures of applications. In order to realize applications according to the framework, we suggest to define application-independent primitives which are appropriate and feasible in a specific level of abstraction. They are separated from implementation issues, concentrate on the inherent features of a cooperation model, and shall provide useful abstractions. Only after having identified the primitives, application- and deployment-specific constraints refines the design and determine the respective implementation techniques. This approach ensures a robust, enduring design and facilitates system evolution. It considers the most abstract issues in a service- and communication-oriented approach first, and then successively looks at different levels of abstraction and, finally, on implementation techniques. A representative set of electronic commerce applications is analyzed and classified. It is pointed out that inappropriate and often implementation-induced choices for the cooperation model leads to inflexible, unscalable solutions. Especially in the area of EC applications, the general service-centric design greatly benefits from the presented graduation of design steps. Future work will concentrate on the definition of cooperation primitives for event-based environments. While much effort has been invested on the request/reply model (CORBA, RPC, etc.), many important issues in the field of event-based cooperation are still unresolved. Adequate cooperation primitives have to be defined, because this model
is a prerequisite for many future applications and also seems to be adequate for extending current applications. Further insights are necessary so that (e-commerce) applications are able to fully exploit the event-based cooperation model.
6 References [1]
[2] [3] [4]
[5] [6]
[7]
[8] [9]
[10]
[11]
[12]
[13]
ACT-NET Consortium. “The Active Database Management System Manifesto: A Rulebase of ADBMS Features.” SIGMOD Record, 25(3):40–49, September 1996. Akamai Technologies, Inc. Homepage. http://www.akamai.com. Yannis Bakos. “The emerging role of electronic marketplaces on the internet.” CACM, 41(8):35–42, August 1998. C. Bornh"ovd, M.A. Cilia, C. Liebig, and A.P. Buchmann. “An infrastructure for meta-auctions.” In Second International Workshop on Advance Issues of E-Commerce and Web-based Information Systems (WECWIS’00), San Jose, California, June 2000. Ralph Cassady Jr. Auctions and Auctioneering. Univ. California Press, 1979. Marshall Cline and Mike Girou. “Enduring business themes.” Communications of the ACM, 43(5):101–106, May 2000. U. Dayal, B. Blaustein, A. Buchmann, S. Chakravarthy, and et al. “The HiPAC project: Combining active databases and timing constraints.” SIGMOD Record, 17(1):51–70, 1988. Deutsche B"orse Group. Member Front End Development Guide, 2000. Volume 1 - Call Interface. Elisabetta Di Nitto and David S. Rosenblum. “On the role of style in selecting middleware and underwear.” In Proceedings of the ICSE ’99 Workshop on Engineering Distributed Objects (EDO ’99), pages 78–83, Los Angeles, CA, USA, 1999. Michael J. Franklin and Stanley B. Zdonik. ““Data In Your Face”: Push Technology in Perspective.” In Laura M. Haas and Ashutosh Tiwary, editors, SIGMOD 1998, Proceedings ACM SIGMOD International Conference on Management of Data, June 2-4, 1998, Seattle, Washington, USA, pages 516–519. ACM Press, 1998. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns. Addison Wesley, Reading, MA, USA, 1995. Dimitrios Georgakopoulos, Mark F. Hornick, and Amit P. Sheth. “An overview of workflow management: From process modeling to workflow automation infrastructure.” Distributed and Parallel Databases, 3(2):119–153, April 1995. R.E. Gruber, B. Krishnamurthy, and E. Panagos. “The architecture of the READY event notification service.” In Proceedings of the 19th IEEE International Conference on Distributed Computing Systems Middleware Workshop, Austin, Texas, USA, May 1999.
[14] Manfred Hauswirth and Mehdi Jazayeri. “A component and communication model for push systems.” In Proceedings of ESEC/FSE 99 – Joint 7th European Software Engineering Conference (ESEC) and 7th ACM SIGSOFT International Symposium on the Foundations of Software Engineering (FSE-7), volume 1687 of LNCS 1687, pages 20–38, Toulouse, France, September 6-10, 1999. Springer-Verlag. [15] Richard Hayton, Jean Bacon, John Bates, and Ken Moody. “Using events to build large scale distributed applications.” In Proceedings of the ACM SIGOPS European Workshop, 1996. [16] C. E. Hewitt. “PLANNER: A language for proving theorems in robots.” First International Joint Conference on Artificial Intelligence, pages 295–301, 1969. [17] Arthur M. Keller. “Smart catalogs and virtual catalogs.” In R. Kalakota and A.B. Whinston, editors, Readings in Electronic Commerce, pages 259–274. Addison Wesley, 1996. [18] Prabhudev Konana, Nirup M. Menon, and Sridhar Balasubramanian. “The implications of online investing.” Communications of the ACM, 43(1):34–41, January 2000. [19] M. Kumar and S.I. Feldman. “Business negotiations on the internet.” In Proceedings of INET’98, Geneva, Switzerland, July 1998. Internet Society. [20] C. Liebig, M. Cilia, and A. Buchmann. “Event Composition in Time-dependent Distributed Systems.” In Proc. of 4th Intl. Conference on Cooperative Information Systems – CoopIS’ 99, September 1999. [21] G. M"uhl, L. Fiege, and A. Buchmann. “Evaluation of cooperation models for electronic business.” In Information Systems for E-Commerce, Conference of German Society for Computer Science / EMISA, University of Linz, Austria, November 2000. ISBN 3-85487-194-5. [22] Object Management Group. The Common Object Request Broker: Architecture and Specification. Version 2.3. Object Management Group, Framingham, MA, USA, 1998. [23] Brian Oki, Manfred Pfluegl, Alex Siegel, and Dale Skeen. “The information bus—an architecture for extensible distributed systems.” In Barbara Liskov, editor, Proceedings of the 14th Symposium on Operating Systems Principles, pages 58–68, New York, NY, USA, December 1993. ACM Press. [24] Priceline.com. Homepage. http://www.priceline.com. [25] D. C. Schmidt and S. Vinoski. “Programming asynchronous method invocations with corba messaging.” C++ Report, 11(2), February 1999. [26] TIBCO, Inc. “Tib/rendezvous.” White Paper, 1996. http:// www.rv.tibco.com/. [27] Elmar Wolfstetter. “Auctions: An introduction.” Journal of Economic Surveys, 10:367–420, 1996.
