Developing Collaborative Editing Applications using Web Services Muhammad Younas School of MIS Coventry University, Coventry CV1 5FB, United Kingdom
[email protected]
ABSTRACT
This paper presents a new approach for developing collaborative editing applications (CEAs) using Web Services technologies and protocols such as SOAP, WSDL, and UDDI. In the proposed approach, CEAs can be developed using different services available from various autonomous and heterogeneous collaborative editing systems which are distributed across the Internet. A new transactional approach is also presented so as to ensure the consistency and correctness of CEAs. Transactions ensure the concurrent execution and reliability of CEAs during systems and communication failures. Keywords
Web services, collaborative consistency, transactions
editing
applications,
INTRODUCTION
Web Services (WS) provide a new paradigm for developing Internet-based applications using standard technologies and protocols such as Extensible Markup Language (XML), Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) and Universal Description, Discovery and Integration (UDDI) [19, 20]. WS provide a standard means of communication and collaboration among different distributed systems and applications running on a variety of platforms. Though WS are mainly used for developing and integrating business systems and applications (such as B2B, supply chain) [7, 10] they provide promising prospects for developing collaborative editing applications (CEAs). With WS, CEAs can be developed using geographically distributed collaborative editing systems that may provide specialised or cheaper services. In the subsequent discussion we use the word ‘systems’ to represent ‘collaborative editing systems’.
Rahat Iqbal School of MIS Coventry University, Coventry CV1 5FB, United Kingdom
[email protected]
For instance, a CEA for developing a software product, may require specialised and cheaper services provided by different software engineers and programmers, which are remotely located and connected via the Internet. This enable companies such as Microsoft to acquire some services from programmers in India, while others from China. Using WS technologies and protocols such as SOAP, WSDL, and UDDI, systems can easily be integrated and utilised for a variety of services in ComputerSupported Cooperative Work (CSCW) applications, such as electronic conferences and meetings, collaborative CAD and CASE applications, and collaborative documentation systems. Surprisingly, existing approaches do not consider WS for the development of CEAs. In this paper we present a new approach for developing CEAs using WS technologies and protocols such as SOAP, WSDL, and UDDI. WS enable CEAs to be developed using different services available from various autonomous and heterogeneous systems. We also present a new transactional approach in order to ensure the consistency and correctness of CEAs. This enables a group of users to consistently view and edit the shared documents at the same time from geographically dispersed sites. The potential features and contributions of the Web Services-based CEAs (WS-based CEAs) are summarised as follow: •
•
•
WS-based CEAs can be developed using distributed, heterogeneous, and autonomous systems. WS provide a seamless interoperation and cooperation among those systems while maintaining their autonomy and heterogeneity. WS-based CEAs provide dynamic interaction, and collaboration among different systems. Similar to ebusiness applications, service requester of a CEA can find services through UDDI that provides description of the required services. Thus CEAs can dynamically be developed using a variety of services available from different systems. In WS-based CEAs, different systems may cooperate for the duration of a particular CEA. Once that CEA is
•
completed, the systems are no longer required to continue cooperation/contract. For example, one system can be used for the design of user interface in one CEA but it may not be chosen for other CEAs if there are alternative service providers that provide high quality or cheaper services. A new transactional approach is presented. This enables WS-based CEAs to maintain consistency and correctness. Transactions also provide CEAs with reliability in the event of systems and/or communication failures.
The paper is structured as follow. Section 2 reports on the related work. Section 3 illustrates basic concepts and definitions. Section 4 is classified into three subsections. The first subsection presents the proposed approach of using WS for developing CEAs. The second subsection illustrates the features and issues of WS-based CEAs. The final subsection presents a new transactional approach for WS-based CEAs. The paper is concluded in Section 5. RELATED WORK
A significant literature is available on the collaborative editing or CSCW applications. The approach in [6] investigates into the interoperability aspects of collaborative applications. This approach incorporates ‘blackbox’ technique so as to maintain the heterogeneity and autonomy of the respective applications. In order to maintain autonomy, applications are not allowed to undergo any modification for integration purposes. In [12], a transactional system, called JpernLite, is developed for Web-enabled software engineering applications. JpernLite can be extended to provide concurrency control (CC) for extended transactions through the use of plug-in codes. That is, application developers have to write plug-in codes to support the CC features required by the extended transactions. To accomplish CC activities, JPernLite downloads data items from the underlying data resources and stores them in its internal database, called object base. Client applications then access data items from the object base according to the CC rules employed by JPernLite. When a client requests a lock, JPernLite first locks the corresponding object in the object base and then locks that object in its home data source. Another classical approach, as in [2], also aims at addressing interoperability issues of heterogeneous collaborative applications. This work integrates floor control mechanism with locking system of the collaborative applications. Such integration aims at facilitating the interoperation between systems, which are synchronously coupled and fully replicated with those of loosely coupled and partially centralised system. This approach is based on the concurrency control mechanism, which allows single
user to use the system at any given time. This approach is limited as it does not provide support for multiple users. A coordination mechanism for collaborative applications is presented in [5]. This approach enables the interoperability of heterogeneous single user applications such that they can be converted into groupware. Further, the authors in [8] propose a cooperative concurrency control mechanism for Web-based cooperative applications. In the proposed mechanism concurrency is achieved through the introduction of cooperative locking — which is based on the assumption that users are required to be collaborative and not competitive. Thus users can ask each other for the release of the locks (on the data objects) whenever they need locks. Actions (or processes) can be used to perform any specific activity, for example, editing a file, etc. Cooperating actions can simultaneously hold cooperative locks on the same objects but other actions (which are not cooperative) are precluded from accessing the locked objects. Moreover, the use of CGI routines is incorporated enabling Web server to access the cooperative concurrency control service. The authors suggest that the proposed system can also be implemented using the CORBA transaction service, and OMG OTS (Object Transaction Service) [23]. Current approaches use different techniques and technologies in the collaborative editing applications. However, to our knowledge, none of them consider WS technologies in developing CEAs. Though WS are mainly used for e-business applications (e.g., B2B, supply chain), they provide a natural environment for collaborative editing that may distribute across the network using different software and hardware platforms. Thus distributed and autonomous systems of heterogeneous nature can be integrated using WS technologies such as XML, SOAP, and WSDI. Recently several standardization initiatives and frameworks have been developed to provide Web services with transactional capabilities. These include, for example, business transaction framework (BTF) [10], WSTransactions by IBM and Microsoft [1], and business transaction protocol (BTP) by OASIS [9]. However, these are limited to the e-business applications which have different requirements as compared to CEAs. For example, CEAs may use cooperative locking in order to ensure consistency while e-business applications usually do not enforce such locking mechanisms. BASIC CONCEPTS AND DEFINITIONS
In this section, we describe the basic concepts and definitions used in the remainder of this paper. First, we illustrate the Web Services, and then describe transaction models which are used in different applications.
Web Services
Web Services (WS) platform is built on existing and emerging standards and technologies such as HTTP, XML, SOAP, WSDL, and UDDI. These technologies and standards are organized into the different layers of network, messaging, service description, service publication and service discovery (as shown in Figure 1) [3, 4, 19, 20]. The lowest layer of WS is the network. WS that are publicly available on the Internet use commonly deployed network protocols such as TCP/IP, HTTP, FTP, and IIOP. HTTP is commonly used protocol in WS. In WS, messages are communicated between participating systems using XML-based SOAP protocol. SOAP provides enveloping mechanism so as to communicate documentbased messages, and to represent remote procedure calls (RPCs). A SOAP message is an XML document. It comprises different parts such as SOAP envelope, a SOAP header, and a SOAP body. SOAP envelope is the top element of the XML document, which represents the message. Header is used to add features to a SOAP message. Features are added to the message in a decentralized manner without prior agreement between the participating systems concerning the message. SOAP body is a container for the information which is sent from the sender to the receiver of the message. SOAP defines a few attributes that can be used to indicate who should deal with a feature and whether it is optional or mandatory. SOAP messages are extensible thus they can be customised according to the application needs. They also support operations such as publish, find, and bind; the basic operations used to respectively publish (advertise) services, search for the required services, and invoke operations on those services.
S e rv ic e P u b lic a tio n a n d D is c o v e ry (U D D I) S e rv ic e D e s c rip tio n (W S D L ) XM L - based M essage (X M L ) S e rv ic e P u b lic a tio n a n d D is c o v e ry (T C P /IP , H T T P , F T P , IIO P )
Figure 1. Web Services Technology Stack
WSDL facilitates the process of service description. Each service provider uses WSDL in order to define the details of the services it provides. Through WSDL services are defined as collections of network endpoints, or ports [19]. In order to define services WSDL document uses different
elements such as: types (used for data type definition); message (typed definition of the data); operation (describes an action which is supported by the respective service); binding (defines a protocol and data format specification for a particular port type); port (specifies an address for a binding); service (aggregates a set of related ports). UDDI is used by service requesters and providers in order to publish and search for services [24]. UDDI uses WSDL documents to publish details of the services and also facilitates the searching of services. That is, service provider register information about the services they provide over the Web. Such information can be added to the UDDI registry using different techniques such as through Web site or other tools. The UDDI registry is a logically centralized and physically distributed. UDDI comprises multiple root nodes, which are used to regularly replicate data with each other. Once a service provider registers with a single instance of the registry service, the data is automatically shared with other UDDI root nodes. Such data is then freely available to anyone who needs to discover what Web services are exposed by a given service provider. Transaction Models
Transaction technology is originated from databases [15, 16] and has widely been used for a multitude of applications such as banking, e-commerce, mobile computing, CASE, and CAD applications. Transaction is defined as a unit of work wherein several operations can be treated as a single logical unit of work performed. There exist various transaction models in the literature. The classical model of transaction is based on the criteria, called ACID [15]. ACID is an acronym that represents the properties of atomicity, consistency, isolation, and durability. These properties are described as follows: Atomicity: This property requires an “all or nothing” ethos [16, 17] such that a transaction must either appear to execute in its entirety or not at all. Other transactions can not be exposed to a database state caused by a partially completed transaction. Consistency: Consistency demands that transaction must transform a database from one consistent state to another consistent state. Maintenance of the consistency property is dependent on the constraints placed on the database, which is also known as integrity constraints. The database is said to consistent if it satisfies all its integrity constraints. Isolation: It is the property of transactions, which provides each transaction with the consistent state of database all the times. In other words, an active transaction can not expose its intermediate results to other concurrent transactions before its commitment. Transactions are therefore isolated from each other with respect to the database states so that they can preserve the database consistency.
Durability: Durability means that the effects of the committed transactions must not be erased and should be made permanent in the respective databases. Durability must be exercised for the committed transactions even in the case of failures. Various commit protocols have been developed in order to enforce the ACID properties for a transaction in a distributed computing environment. The most common protocol is the two-phase commit (2PC) protocols [16]. Other variants of 2PC protocol include, for example, presumed abort and presumed commit protocols. ACID criteria are inappropriate for applications that require cooperation or collaboration between different transactions such as CAD, CASE, and other collaborative editing applications. Thus various extended transaction models have been proposed in the literature [14, 18, 21, 22]. These include, for example, nested and open-nested transaction models. The basic aim of the extended transaction models is to relax the atomicity and isolation property of the ACID criteria. For example, in open-nested transaction model, isolation is relaxed by allowing transactions to share intermediate results with each other.
requestors. For example, if Maria provides her component to Emma, then Maria is the service provider and Emma is the requester. As described earlier, WS provide a natural environment for the development of the aforementioned Web-based software system. WS enables the smooth interaction and interoperability of the component systems A, B, C which are used in developing components C1, C2, and C3. The programmers are not required to know each other's underlying platform, programming languages, etc. The service description (in WSDL) combined with the underlying SOAP infrastructure sufficiently encapsulates these details away from the programmers. C2
System B C1
DEVELOPING CEAs using WS
This section is classified into three subsections. The first subsection presents the proposed approach of using WS for developing CEAs. The second subsection illustrates the features and issues of WS-based CEAs. The final subsection presents a new transactional approach for WSbased CEAs. WS-based CEAs
We illustrate the usage of WS in collaborating editing through an example application. Consider an example of CEA in component-based software development in which different programmers develop different components (or modules) of a Web-based software system. The main components of the systems are the user interface, processing logic, and data manipulation. For example, programmer Emma is responsible for component C1 which designs a user interface, and programmer Rice is responsible for component C2 that designs the application logic of a software tool. Similarly, programmer Maria develops component C3 as part of data manipulation of the Web-based system. It is assumed that these programmers use different systems that provide specialised facilities for the development of the aforementioned components of a Web-based system (Figure 2). These programmers also need to share and exchange documents (codes and data) during the course of system development process. For example, Rice may need component C3 so as to coordinate it with component C2. In order to comply with the standard terms of WS, we consider the programmers as service providers and service
System A
C3
System C
Figure 2. Example of Collaborating Editing Application
Figure 3 diagrammatically represents WS-based CEAs. The three major WS standards and technologies used in developing CEAs are described as follows: Service description – WSDL:
WSDL is used to provide the detailed description of the services provided by a particular system such as system A, B or C. Service provider uses service description in order to communicate all the specifications of its service so that they can be invoked or used by the service requestor. WSDL is extensible. Thus different services can be described in different ways depending on system requirements. In general, WSDL is used to define service description such as: the operations (or method signatures), the type of XML messages, and the binding, which describes the protocol, data types and other attributes. For instance, in the above example, the service description of the above systems A, B and C can be defined as: -
type of service they provide such as user interface design, and processing logic design
-
operations (or method signatures) supported by these systems
-
binding such as data types and other attributes
Message communication – SOAP:
SOAP protocol is used to communicate messages between the participating systems A, B and C, as shown in Figure 3. SOAP provides an enveloping mechanism for the request/response messages. For example, if system A requires a service from system B, it creates a SOAP message. This SOAP message is the request that invokes the Web service operation provided by the service provider, system B. This message is sent to system B through an underlying network protocol (such as HTTP) and via UDDI. On system B’s side, the SOAP runtime converts this message into programming language-specific objects if required by the application. Once the request is received on system B’s side, it is processed and response is sent back to the service requester (system A). The response message may be converted into objects in target programming language, if required. An example of a SOAP request about the user interface service provided by system A is shown in Figure 4.
S y s te m A
•
W SDL UDDI
Components of a CEA such as C1, C2, and C2 can be geographically distributed among different systems. These systems may be heterogeneous using different hardware and software platforms. Systems may be autonomous belonging to different organisations. WS-based CEAs provide a seamless interaction and cooperation among those systems while maintaining their autonomy and heterogeneity. For example, systems are only required to define their services using WSDL and are not required to undergo any modification in order to be a part of WS-based CEAs.
POST /UserInterface HTTP/1.1 Host: www.System-A.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" System A User interface design other details
S y s te m B
W SDL SOAP N e tw o rk P ro to c o l
•
SOAP N e tw o rk P ro to c o l
N e tw o rk P ro to c o l SOAP
W SDL S y s te m C
Figure 3: Architecture of WS-based CEAs Figure 4: Example of a SOAP Request Service discovery and publishing – UDDI:
UDDI provides a mechanism for holding descriptions of Web Services. That is, the services provided by Systems A, B, and C. Thus any service requester finds the required services using UDDI. UDDI is considered as a directory mechanism such as yellow pages. It represents the details of the service descriptions (defined in WSDL). For example, programmer Maria can use UDDI to find services such as user interface, application logic. In order to ensure that, the respective systems A, and B must publish their services (using WSDL) to the UDDI. Features and Issues of WS-based CEAs
WS-based CEAs are characterised by the following distinguishing features:
•
•
WS-based CEAs provides dynamic interaction, cooperation, and contract among the respective systems. Service requester can find services through the UDDI that provides description of the required services. Thus CEAs can dynamically be developed using a variety of services. Systems may cooperate for the duration of a particular CEA as in the above Web-based software development. Once a particular CEA is completed the systems are no longer required to continue cooperation/contract. Similar to e-business, application developers may prefer to use different services offered by different systems depending on the type and nature of CEA. For example, system A can be used for the design of user interface in one CEA but it may not chosen for other CEAs if there are alternative service
providers — that provide high quality or cheaper services. In addition to the above features, a number of complexities and issues arise that must be addressed in order to fully exploit WS-based CEAs. These are summarised are follow. -
-
-
WS-based CEAs are characterised by uncertain duration and uncertain developments. That is, the duration of CEA may take hours or days to complete. Uncertain development implies that the system cannot determine in advance the nature of CEA; whether the execution of CEAs need cooperation, or they might violate consistency of data, except by actually executing them. Consistency of CEAs is also a major issue in such highly dynamic and distributed environment. Different components (such as C1, C2, C3) must be consistent when shared by the respective systems. WS-based CEAs must be resilient to systems and/or communication failures. These failures severely affect the CEAs by interrupting their progress. Such interruption may result in roll backing or cancelling the worked performed as a part of CEA. However, such cancellation of the long-lived CEAs is not acceptable as a valuable piece of completed work might be lost. Instead, a CEA must be able to proceed (and eventually succeed) even if it partially completes.
Transactional approach for WS-based CEAs
In order to deal with the aforementioned issues we propose a transactional approach for developing WS-based CEAs. As described earlier, transaction technology is originated from databases [15] and has widely been used for a multitude of applications such as banking, e-commerce, mobile computing, CASE, and CAD applications. Transaction technology provides a facility wherein several operations can be treated as a single logical unit of work performed as a part of one application. Transactions ensure the correct, consistent, and reliable execution of various applications despite failures of systems, distribution of data, and concurrent execution of such applications. Transaction technology ensures these guarantees using a variety of mechanisms such as ACID (atomic, consistent, isolated, durable) criteria, two-phase commit protocols, and extended transactions models. ACID criteria are based on the strict isolation and atomicity policy such that active transactions are not allowed to exchange shared data. ACID criteria are therefore inappropriate for applications that need data sharing such as CEAs [8, 12]. For WS-based CEAs, we therefore, propose new correctness criteria, called SACReD (semantic atomicity, consistency, resiliency, durability) [13, 14], and supplement these criteria with join transaction model [11].
SACReD criteria are based upon semantic atomicity which require transactions to either commit or abort using alternative and compensating transactions. Thus transactions can commit unilaterally and therefore expose their intermediate states to other transactions. This enables cooperation among different applications. SACReD do not enforce classical isolation, as it is undesirable when transactions involve co-operation and negotiation between users. For example, programmers Emma, Rice, and Maria can exchange documents/data during the development process of the Web-based system. Further a resilience property is defined that allow the definition of alternative transactions. In WS-based CEAs, resilience property is important as alternative services can dynamically be defined. For example, if system A is unable to provide the service of user interface, then it can be acquired from another alternative system. We also propose the use of join transactions [11] for WSbased CEAs. This model is used to merge multiple independent transactions into a single transaction. Jointransactions are useful for WS-based CEAs. For example, components C1, C2, and C3 from programmers Emma, Rice, and Mari can be merged together in order to develop Web-based system. Due to the openness and uncertain developments of WS-based CEAs, the flexibility to join independent transactions is required. In the following we illustrate the applications of SACReD and join transactions through the example CEA of designing a Web-based software system (as described in the preceding section). In order to maintain the correctness of CEA, all the components (such as C1, C2, and C3) must be completed in a consistent way. That is, all of the components are successfully designed in order to develop the required Web-based software system. We see that the execution correctness of such CEA can be achieved if the respective systems process each component by executing a component transaction for it. Thus each of the individual component (e.g., user interface design or processing logic) of CEA can be modeled as a component transaction. The main requirement for component transactions is that they must adhere to the SACReD correctness criteria. That is, all of the component transactions (performing different operations) must complete successfully. This all-or-nothing characteristic will provide them with semantic atomicity property. Similarly, each of the individual transaction must maintain the consistency of the component (e.g., user interface design). Further, it is required that the affects of the successfully completed transactions must be made permanent in the persistent storages so as to meet the requirement of the durability property and to ensure fault tolerance in the event of systems or network failures. Finally, the resiliency requirement is that transactions must replace the failed or unavailable components so as to take an alternate action. As described earlier, if system A is
unable to provide service of user interface, then it can be acquired from another alternative system.
4.
Kreger, H: Web Services Conceptual Architecture (WSCA 1.0), May 2001.
Since SACReD criteria do not enforce the isolation property, thus different users can jointly work on the shared documents. Common techniques for working on shared documents are the locking mechanisms such as exclusive or shared locks (there exist other techniques which are not described here). Thus depending on the nature of the CEAs, users may use shared or exclusive locks in order to perform their tasks. However, in an open and distributed environment such as Web, users need to exchange the required information for working on the shared documents. Such information include, for example: which parts of the document need to be processed (jointly) by multiple users, the type of the required operations, the locking mechanism required, and so on. In the proposed approach the exchange of such information is facilitated through the SOAP messages. For instance, if Emma and Maria are working on the shared document, they exchange the required information through the SOAP messages. As described earlier, the beauty of SOAP messages is that they are extensible. Thus users can define such messages according to the requirement of the CEAs.
5.
LaMarca A., Edwards K.W., Dourish P., Lamping J., Smith, I., Thornton, J., (1999), “Taking the Work out of Workflow: Mechanisms for Document-Centered Collaboration”, European Conference on Computer Supported Cooperative Work (ECSCW ’99).
6.
Li D., Li R., (2002): ‘Transparent sharing and interoperation of heterogeneous single-user applications’, ACM Conference on Computer Supported Cooperative Work (CSCW'2002), pp. 246255.
7.
Medjahed, B., Benatallah, B., Bouguettaya, A., Ngu, A. H. H. and Elmagarmid, A., ``Business-to-Business Interactions: Issues and Enabling Technologies'', The VLDB Journal, to appear, 2003.
8.
Mock, M., Gergeleit, M., Nett, E.,: “Cooperative Concurrency Control on the Web” 6th IEEE Workshop
In our previous work [13] we have formally specified and implemented SACReD criteria for transactions in Webdatabase and e-commerce applications using CORBAcomplaint software, called Java IDL. In this research, we are currently implementing those criteria in the WS-based CEAs, using WS technologies such as SOAP, WSDL, and UDDI. CONCLUSION
In this paper we have presented a new approach for developing collaborative editing applications using Web Services. We have identified that current research ignores the use of Web Services in developing collaborative editing or CSCW applications. We have illustrated the development of CEAs using Web Services through a case study of a software engineering application. In addition, a new transactional approach for WS-based CEAs is also presented. This enables the development of consistent and reliable CEAs using Web Services. REFERENCES
1.
Cabrera, F., Copeland, G., Cox, B., Freund, T., Klein, J., Storey, T., and Thatte, S., “Web Services Transaction (WS-Transaction)” 2002.
2.
Dewan, P., and Sharma, A., (1999): “"An experiment in Interoperating Heterogeneous Collaborative Systems"”: 6th European Conference on Computer Supported Cooperative Work - ECSCW'99, Copenhagen, Denmark.
3.
http://www-106.ibm.com/developerworks/library/wstranspec/.
on Future Trends of Distributed Computing Systems (FTDCS '97), Tunis, October 29-31, 1997.
9.
OASIS, Business Transaction Protocol, Version 1.0, 2002.
10. Papazoglou, M.,: “Web Services and Business Transactions” World Wide Web, Vol. 6 (1), pp. 49-91. 11. Pu,
C., Kaiser, G.E., Hutchinson, N.,: “Split Transactions for Open-Ended Activities” In proceeding of 14th VLDB Conference, 1988.
12. Yang, J., Kaiser, G.E., “JPernLite: An Extensible Transaction Server for the World Wide Web” IEEE Transaction on Knowledge & Data Engineering, 1999 pp. 639-657 13. Younas, M., Eaglestone, B.,: “A Formal Verification Strategy for Crash Recovery in Web-Database Applications” 3rd International Conference on Web Information Systems Engineering - Workshops, IEEE CS Press, December, 2002, Singapore, pp. 113 – 119. 14. Younas, M., Eaglestone, B., Holton, R.,: “A Review of Multidatabase Transactions on the Web: From the ACID to the SACReD” British National Conference on Databases (BNCOD), Exeter, UK, Springer LNCS, 2000. 15. Gray, J. and Reuter, A. ‘Transaction Processing: Concepts and Techniques’ Morgan Kaufmann Publishers, 1993 16. Berstein, P.A., Hadzilacos, V., Goodman, N.: “Concurrency Control and Recovery in Database Systems” Addison-Wesley, USA, 1987 17. Elmagarmid, A. K. (eds.) (1992) “Database Transaction Models for Advanced Applications’
Morgan Kaufmann Publisher Systems” Prentice-Hall Inc., 1992 ISBN 0-13-715681-2 18. Chrysanthis, P.K., Ramamritham, K. :“Synthesis of Extended Transaction Models using ACTA” ACM Transaction on Database Systems, Vol. 19, No. 3, September 1994, pp. 450-491 19. “Web Services Activity” http://www.w3.org/2002/ws/ 20. http://www.webservices.org/ 21. Barghouti, N. S., Kaiser, G. E.: “Concurrency control in advanced database applications” ACM Computing Surveys, 23 (3), 1991, pp. 269-317
22. Kaiser, G. E.: “A flexible transaction model for software engineering” In Proc. 6th International Conference on Data Engineering (ICDE), Los Angeles, CA, February 1990, IEEE Computer Society, Invited paper, pp. 560-567 23. OMG “CORBAservices: Common Object Service Specification” http://www.omg.org/corba/ 24. “UDDI Technical White Paper”, September 2000 http://www.uddi.org/pubs/Iru_UDDI_Technical_Whit e_Paper.pdf
