Specification and Verification of Web Services Transactions Iman Saleh
Gregory Kulczycki
M.Brian Blake
Virginia Polytechnic Institute and State University
Virginia Polytechnic Institute and State University
University of Notre Dame
Falls Church, VA, USA
Falls Church, VA, USA
[email protected]
[email protected]
[email protected]
Notre Dame, IN, USA
“I have met a problem when I was trying to get the sales rank of digital cameras using the Web service. It showed me pretty different sales ranks from what I saw through Amazon Website.”[1] and, “Can someone explain the precise distinction between 'Completed' and 'Processed' [as the output of a PayPal payment transaction service]?” [13]
ABSTRACT Research in transactions planning has recognized the evolvement of Web Services as an industry standard to implement transactional business processes. Web transactions are formed by integrating services in an ad-hoc manner. Distributed transaction protocols may be used to ensure data integrity. However, these protocols require some level of coordinated transaction management. Moreover, individual services must be transactionaware in order to support necessary compensation operations. These assumptions are unrealistic in the case of the Web. We propose a data modeling and contracting framework for Web services that facilitates the verification of data integrity properties in ad-hoc transactions. The proposed framework enables services’ integrator to plan their transactions while ensuring data integrity conditions.
The Web Services Description Language (WSDL) [20] is currently the de facto standard for Web services. WSDL specification describes a service operation only in terms of its syntactical inputs and outputs; it doesn’t provide a means for specifying the underlying data model, nor does it specify how a service invocation affects the data. Consequently, consumers may use a service erroneously. We believe that aspects of formal specifications as represented in software engineering practices could provide solutions for effectively specified data-centric Web services. Formal methods allow for more rigor than processoriented languages, such as the Business Process Execution Language for Web Services [10] and the semantic-based specification languages such as the Web Services Ontology Language (OWL-S) [12].
Categories and Subject Descriptors D.2.4 [Software]: Software/Program Verification – correctness proofs, formal methods, programming by contract, validation.
General Terms
While application logic varies significantly from one service to another, we are able to capture commonalities and use them to create a generic formal model that describes a service’s data functionalities. We then use the formal model to create a data contract for a service. The contract is a set of formal assertions which describes the service behavior with respect to its interaction with the data. The contract also exposes data-related business rules. Since our model is based on formal methods and design-bycontract principles, it provides a machine-readable specification of the service. This facilitates automatic analysis, testing, and reasoning about the service behavior. We show how our model can be useful in decreasing ambiguity, verifying the correctness of integration of services and also in proving data integrity properties in service-based transactions.
Design, Standardization, Verification
Keywords Formal Methods, Web Services, Data Model.
1. INTRODUCTION Major online organizations today, such as Amazon, PayPal and FedEx, provide services for users and consumers. They also allow third-party vendors to resell their services. Both cases require precise and complete specification of service offerings. Several online discussions demonstrate the challenges faced by these organizations and others while describing their data-centric Web services. Some of the consumers’ feedback on Amazon and PayPal included:
In the rest of this paper, we present our motivation and related work (Section 2), our contracting framework (Section 3), our research hypotheses and their validation (Section 4), and we finally conclude with a summary of our contributions and ongoing work (Section 5).
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Proceedings of the Fourth SIGMOD PhD Workshop on Innovative Database Research (IDAR 2010), June 11, 2010, Indianapolis, USA. Copyright 2010 ACM 978-1-4503-0191-6/10/06... $10.00.
2. MOTIVATION AND RELATED WORK The OASIS Business Transactions Protocol (BTP) [9] and the Web Services Transactions (WS-Tx) [11] specification are two
37
variable between a service request and response. We do not attempt to specify all states of a data store as we focus on correctness and verification of data-related side-effects after a service call. We believe that having our model in place can enable the verification of a data-driven application by reasoning about the collective side-effect of the integration of services based on the individual data contracts.
major efforts in planning Web service transactions. These protocols define interactions between the service consumer and the service provider to ensure that they agree on the outcome of a transaction. It is assumed that compensation transactions are implemented to undo updates upon transaction failures. These protocols employ variations of the two-phase commit protocol to ensure the all-or-nothing property of a distributed transaction. While these techniques are meant to ensure database integrity, they are all based on the assumption that service interactions against the database are well defined and known before planning a transaction. They also assume that service developers will follow protocol guidelines while implementing their data-centric Web services and that a mediator exists to coordinate between service providers. These assumptions are only valid when all services belong to a specific business domain or implemented within the same enterprise with strict conventions. On the Web however, services are typically combined from different providers that potentially employ different implementation conventions and practices. The assumption of a mediator becomes impractical for the Web setting. Moreover, many hidden business rules related to data manipulation may lead to incorrect transaction outcome even if transaction management measures are in place. Since our model formally specifies the data behavior of an individual service by exposing a data contract, it enables the verification of the outcome of the transaction based on the individual contracts of participating services. Our model also helps in identifying unambiguously the exact compensation steps upon transaction failure. Global data integrity is hence guaranteed at the design time of the transaction.
3. WEB SERVICE CONTRACTING FRAMEWORK We propose a framework that enables contract-based composition of services as shown in Figure 1. Service Consum ers
Global Data Contract
Service Composition Code S1 Data Contract
S2 Data Contract
SnData Contract
….
Our work builds on traditional efforts for formally specifying relational databases. A comprehensive survey of this area can be found in [16]. These efforts aimed at deriving relational database programs from formal specification. Since our goal is to expose a data contract and not to build the service logic from the specification, we do not aim at exhaustively specifying the underlying database schema, but rather to abstract this schema in a model that is exposed as part of the service interface. Also, we are extending this work to support transactions spanning more than one database, where it is the responsibility of the service consumer to guarantee integrity while having no control on the underlying Database Management System. Finally, our model is not specific to relational databases. A data source in our case can be any data store exhibiting some structure. We therefore built our model while avoiding constructs that are too specific to relational databases.
DM1
DM2
S1 Code
S2 Code
DB1
DB2
DMn
….
Sn Code
DBn
Service Providers
Figure 1. Contract-based transactional service composition. Based on our framework, a service provider abstracts the data source(s) of a service Si into a formal data model DMi. The model hides the data design and implementation details of the service’s underlying database DBi. The details of the model are discussed later. The data model is used to annotate the service with a data contract. The contract specifies the data requirements and service side-effects without exposing the service implementation details denoted as Si Code in the figure. It is the provider’s responsibility to ensure that a service advertised contract is correct with respect to the service implementation. Automatic verification techniques can be used to achieve this goal. Some tools have been recently developed for that purpose like Boogie for C# [2] and the JML compiler for Java [3].
The authors of [5] address the specification of data-driven Web applications. Their proposed approach help verifying application properties related to reachability, dead-ends avoidance, and redundancy. Consequently, they are specifying the database from a process perspective where the data can have infinite number of states and state transitions. The mentioned work proposes simplifying assumptions in order to make the problem tractable. A similar perspective is adapted in [21] where a high-level programming language is proposed to model data-driven applications. In our work, we are specifying and reasoning about stateless Web services using formal methods techniques. We consider the underlying data store as a global variable that we are including as part of the formal specification of a service. We are concerned with reasoning about the changes of that global
Assuming the correctness of individual service contracts, the service consumer can consult the individual contracts to understand the behavior of each service. The consumer then constructs a global data contract that reflects the consumer’s intentions and the desired composition’s side effects on the underlying data stores. The global data contract is written in terms of the individual data models. The service consumer can formally verify the correctness of his or her composition with the global data contract. Again, automatic verification techniques may be used to facilitate this step.
38
4. RESEARCH HYPOTHESES AND VALIDATION We aim at formally modeling and specifying the data aspect of Web services, as it is overlooked by current standards. The data models and data contracts, proposed in our framework, are specifications for the data stores and data services, respectively. They allow the service consumer to ignore the data and service implementation details. They also allow the service providers flexibility in creating or modifying implementations for their services. This separation between specification and implementation promotes software modularity and service reuse. In our work, we use formal methods and design-by-contract techniques.
-L0: No specifications. -L1: Model-independent pre/post-conditions. -L2-L5: Model-based specification ranging from 6 up to 14 assertion describing service behavior under different input combinations. -Levels are cumulative.
Our main research hypothesis can be stated as follows: Main Hypothesis: The formal specification and verification of data-centric Web services can be facilitated by exposing a formal data contract.
Figure 2. Number of possible queries for the ItemSearch service at different levels of specifications.
In order to support our main hypothesis, we develop a formal model for an abstract source of data and develop the contracting framework described in Section 3. We model a data source as set of entities where each entity is a set of records. In addition to a unique record identifier (key), a record can have zero or more attributes. We view this model as a common denominator of many popular data models that we surveyed [6][18][4]. Our approach is hence applicable to both structured and semi-structured data stores such as databases, spreadsheets, and XML files. We adapt the CRUD (Create-Read-Update-Delete) [8] model to include functional descriptions of the basic data operations. We implement our model as a generic class to facilitate its understanding by programmers of Web services. The reader is referred [15][14] for the details and an example of our model along with a generic template that can be used to write the data models for their services. We split our main hypothesis into the hypotheses discussed in the following subsections.
4.2 Verification of Data Integrity Properties in ACID Transactions Hypothesis: The proposed contracting approach enables verifying the data integrity within an ACID transaction that spans multiple autonomous Web services. ACID (atomicity, consistency, isolation, durability) is a set of properties that guarantee that database transactions are processed reliably. Validation Approach: We consider an implementation of an ecommerce Website where the developer uses FedEx to ship orders to customers and uses PayPal Express Checkout to implement the electronic payment functionalities. The Website is implemented by integrating services from the two service providers. The developer would like to consider the implementation as an ACID transaction and would hence like to ensure the all-or-nothing property; i.e. if an error occurs within the transaction, a compensating action should be applied to undo any database update. For example, if the FedEx shipment processing service fails, the Website should invoke a PayPal refund service to compensate the customer’s payment. The transaction flow is depicted in Figure 3. The data models and contracts of the participating services are shown in Figure 4.
4.1 Demystifying Data-Centric Web Services Hypothesis: Our contracting approach decreases the level of ambiguity about a service behavior in terms of its underlying data interactions and expected output under different input conditions. Validation Approach: We use our model to specify a simplified version of the ItemSearch service which searches for items within Amazon.com product catalog given a set of search filters [1]. We then consider a case study where the ItemSearch service is used by a Web search engine to crawl data from Amazon database. Our evaluation is based on the observation that the more queries the crawler has to try to retrieve the same set of data records, the more ambiguous the service behavior. Consequently, we consider the total number of possible input combinations (queries) as an indication of the level of ambiguity of the service specification. Our goal is to minimize the total number of input combinations by only considering the relevant ones. Filtering out invalid input combinations is done based on the crawler understanding of the exposed data contract.
Figure 3. The e-commerce item checkout transaction. The class PayPalDM in Figure 4 (a) represents the PayPal data model which is defined as a set of transaction records. A transaction record is represented by the TransRecord class and consists of a transaction ID transID, a payment transaction amount transAmount and the corresponding payer and seller
Our results depicted in Figure 2 indicate that the service specifications have a great impact on narrowing the search space for queries and selecting queries that will not generate errors or duplicates and that maximize the result set.
39
information captured by the attributes payerInfo and sellerInfo, respectively. The transID attribute is a timestamped token that is used by the PayPal services to relate different services calls to a one payment transaction. It is unique and hence we choose to use it as the transaction record key. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
In our work, we use Hoare-style specification [7] to define an operation’s pre/post-conditions. A pre-condition is specified using a requires clause and a post-condition is specified using an ensures clause.
class TransRecord attribute transID: String //key attribute transAmount: float attribute payerInfo: PayerInfoType attribute sellerInfo: SellerInfoType end TransRecord
1 String SetExpressCheckout(float sPaymentAmount, 2 SellerInfoType seller, BuyerInfoType buyer) 3 modifies ppdm, pRec 4 ensures pRec.transID ≠ Nil and 5 #ppdm.findRecordByKey(pRec.transID) = Nil and 6 pRec.sellerInfo = #seller and 7 pRec.payerInfo = #buyer and 8 pRec.transAmount = #sPaymentAmount and 9 result = pRec.transID and 10 ppdm = #ppdm.createRecord(pRec)
class PayPalDM attribute transEntity: Set(TransRecord) operation TransRecord findRecordByKey(key: String) ensures (result.token = key and result in this.transEntity) or result = Nil operation Set(TransRecord) findRecordByCriteria(payerInfos: Set(PayerInfoType)) ensures ∀rec in result, rec.payerInfo in payerInfos and result in this.transEntity operation PayPalDM createRecord(rec: TransRecord) ensures result.transEntity = this.transEntity ∪ rec operation PayPalDM deleteRecord(key: String) ensures result.transEntity = this.transEntity – this.findRecordByKey(key) operation PayPalDM updateRecord(rec: TransRecord) requires this.findRecordByKey(rec.transID) ≠ Nil ensures result.transEntity = this.deleteRecord(rec.transID).createRecord(rec) end PayPalDM
(a) PayPal Data Model
1 2 3 4
PayerInfoType GetExpressCheckoutDetails(String gToken) requires ppdm.findRecordByKey(gToken).payerInfo ≠ Nil ensures pRec = #ppdm.findRecordByKey(#gtoken) and result = pRec.payerInfo
1 2 3 4 5 6 7 8 9 10 11
void DoExpressCheckout(String dToken, float dPaymentAmount) modifies ppdm requires ppdm.findRecordByKey(dToken).payerInfo ≠ Nil ensures #pRec = #ppdm.findRecordByKey(#dToken) and pRec.transAmount = #dPaymentAmount and pRec.payerInfo.balance = #pRec.payerInfo.balance – #dPaymentAmount and pRec.sellerInfo.balance = #pRec.sellerInfo.balance + #dPaymentAmount ensures ppdm = #ppdm.updateRecord(pRec)
1 2 3 4 5 6 7 8 9
void RefundTransaction(String transID) modifies ppdm requires ppdm.findRecordByKey(transID) ≠ Nil ensures #pRec = #ppdm.findRecordByKey(#transID) and pRec.payerInfo.balance = #pRec.payerInfo.balance + #pRec.transAmount and pRec.sellerInfo.balance = #pRec.seller.balance - #pRec.transAmount and ppdm = #ppdm.updateRecord(pRec)
1 2
float Rate(Address shipper, Address recipient, float weight, PackagingType packaging)
(b) Data Contracts of PayPal Services
1 class FedExRecord 2 attribute trackingID: String //key 3 attribute shipperAddress: Address 4 attribute recipientAddress: Address 5 attribute weight: float 6 attribute packagingType: 7 {BOX, ENVELOPE, YOUR_PACKAGING} 8 attribute totalNetCharges: float 9 end FedExRecord 10 11 class FedExDM 12 attribute shipmentEntity: Set(FedExRecord) 13 // Similar definitions for findRecordByKey, 14 // findRecordByCriteria, createRecord, deleteRecord 15 // and updateRecord as in (a) 16 end FedExDM
1 boolean ProcessShipment(Address shipper, 2 Address recipient, 3 float weight, 4 PackagingType packaging) 5 modifies fedm, fRec; 6 ensures if result = FALSE then 7 fedm = #fedm and frec = #frec and 8 if result = TRUE then 9 fRec.trackingID ≠ Nil and 10 #fedm.findRecordByKey(fRec.trackingID) = Nil and 11 frec.shipperAddress = shipper and 12 frec.recipientAddress = recipient and 13 fRec.totalNetCharges = 14 Rate(#shipper, #recipient, #weight, #packaging) 15 and fedm = #fedm.createRecord(fRec)
(c) FedEx Data Model
(d) Data Contracts of FedEx Services
Figure 4. The data models and contracts of PayPal and FedEx Web services. The ‘#’ prefix is used in the ensures clause to denote the value of a variable before the invocation of the operation. The result keyword is used to denote an operation’s output. Importantly, we use the modifies clause to indicate that a variable other than an explicit parameter is modified by an operation execution. We define model variables representing the underlying data stores. A model variable is a specification-only variable [3] that is used in conjunction with programming variables to model the state of the system. In our example, the model variables can be shared by one or more service to reflect the fact that these services may be
reading and updating the same data store and hence we capture dependency and compositional effect of services on that data store. The system state in our case is represented by service inputs and outputs in addition to the model variables. We use these notations in Figure 4 to specify the basic data operations and the PayPal and FedEx services. The basic data operations are defined as pure mathematical functions that have no side-effect. This enables us to use these operations within the specification of Web services. For example, findRecordByKey in Figure 4 (a) takes as input a key value and returns a transaction
40
guarantee that if a service fails, the seller and buyer balances remain intact. We use symbolic reasoning technique, introduced in [19], as a way to generate the proof obligations required in formal verification. Symbolic reasoning can be seen as a generalization of code tracing, where object values are represented symbolically rather than concretely. In this scenario, we are able to provide formal proofs of data integrity at the design-time of the transaction.
record identified by that key value. It ensures that the returned result is either an existing record or a Nil value if a record with that key does not exist in the transaction entity. The operation is does not change the state of a system where it is used. Figure 4 (b) shows the data contract for each individual service in the PayPal flow. In our specification of the PayPal services, we begin by defining a model variable ppdm of type PayPalDM representing the underlying data store. We consider four PayPal services: the SetExpressCheckout service which initiates a payment transaction given the buyer and the seller information and returns a timestamped token. The GetExpressCheckoutDetails service is used obtain information about the buyer from PayPal given the token previously generated by a call to the SetExpressCheckout service. The DoExpressCheckout service is used to complete the transaction by applying the payment and updating PayPal balances accordingly. Finally, the RefundTransaction, as the name suggests, is used to refund a transaction identified by a token value.
We can use the reasoning table to formally verify that the item checkout transaction preserves data consistency between the FedEx and PayPal databases by ensuring the all-or-nothing property. The main idea is to prove that the obligations in the service contract are satisfied by the implementation. In order to accomplish that, we use facts from the symbolic table to prove obligations at the final state of the implementation. For example, we can prove the obligation: if returnValue = FALSE then seller.balance = #seller.balance and buyer.balance = #buyer.balance
Similarly, Figure 4 (c) and (d) show the data model and contracts for the FedEx services, respectively. The FedEx data model is represented by the model variable fedm of type FedExDM. In our example, we consider The FedEx Rate service which is used to provide pre-ship rating information given the shipper and the recipient addresses, and the item weight and packaging type. This service does not have to access the FedEx data store and hence does not expose any data-related specification. The ProcessShipment service creates a FedEx shipment given the same information as the Rate service. The ProcessShipment either returns true when a shipment is created successfully, or it returns false on failure. For the sake of simplicity, we choose not to fully specify the failure conditions.
This obligation states that if the transaction returns a false value, neither the seller or buyer balances are updated. The formal proofs are omitted from this paper due to limited space.
4.3 Detection of Errors in Web Services Composition Hypothesis: Our proposed contracting framework facilitates the discovery of Web services composition errors at design time. These errors cannot be detected using current WSDL specification Validation Approach: We conduct an experiment to empirically measure the usefulness of our approach in preventing erroneous use of services. We use a set of real-life case studies we implement as compositions of services and we test our hypothesis through the following steps:
boolean CheckoutTransaction(Item item, SellerInfoType seller, BuyerInfoType buyer) modifies ppDm, feDm ensures if result = TRUE then seller.balance = #seller.balance + #item.price + Rate(#seller.address, #buyer.address, #item.weight, PackagingType.YOUR_PACKAGING)and buyer.balance = #buyer.balance – #item.price - Rate(#seller.address, #buyer.address, #item.weight, PackagingType.YOUR_PACKAGING) if result = FALSE then seller.balance = #seller.balance and buyer.balance = #buyer.balance BEGIN returnValue := FALSE; String token := SetExpressCheckout(item.price, seller, buyer); PayerInfoType payerInfo := GetExpressCheckoutDetails(token); float totalCharge:= Rate(seller.Address, payerInfo.Address, item.weight, YOUR_PACKAGING); DoExpressCheckout(token, totalCharge + item.price); if(ProcessShipment(seller.Address, payerInfo.Address, item.weight, YOUR_PACKAGING)) then returnValue := TRUE; else RefundTransaction(token); end if END
(a) Using our modeling and contracting framework, each service is annotated with a formal data contract that specifies its interactions with the underlying data store. (b) A global data contract, representing the services’ integrator intention, is used to specify each composition of services. (c) The composition of services is verified to ensure that the implementation satisfies the global contract and hence satisfy the integrator’s intentions. (d) Errors are automatically injected into each composition of services using techniques from [17]. These techniques simulate programmers’ errors by randomly mutating programs, for example: - Replacing a variable with another variable of the same type. - Replacing a statement with a null/return statement. (e) Using automatic verification techniques, the implementation is compared against the global contract. The injected error is detected if the verification fails to verify the global contract. (f) We repeat steps (d) and (e) for different types of errors and calculate the total number of errors detected using different specification techniques. We consider the following specification levels in our testing: • Level 1: WSDL-only specification, as our baseline. • Level 2: WSDL and our formal specification technique, simplified, where database updates are abstracted as read and write operations
Listing 1. The pseudo-code of the item checkout transaction The implementation of the e-commerce transaction is shown in Listing 1. For simplicity, the global contract shown only provides important obligations related to data integrity guarantees. The variable returnValue in Listing 1 denotes the transaction’s output. As an example of a data integrity property, the integration should
41
[4]
• Level 3: WSDL and our formal specification technique, where database operations are further specified as find, create, update, and delete operations.
[5]
The independent variable in the proposed experiment is the Web services specification level. The dependent variable is a ratio value capturing the percentage of errors detected to the total number of errors injected into the service composition. The main idea is that the number of errors detected using either of the specification methods studied in our experiment is an indication of the correctness of software produced using that method. Our goal is to demonstrate how our approach is useful in maximizing software correctness by avoiding service composition errors that can potentially lead to inconsistent data state. This part of our work is still in progress.
[6]
[7]
[8]
[9]
5. CONCLUSION AND SUMMARY OF CONTRIBUTIONS The main contribution of our work is a contracting framework for data-centric Web services that enable the formal specification of service-to-data interactions and the automatic verification of datarelated properties. Our work comes to fill a practical gap in current Web services’ specification techniques where the specification of the data logic and related business rules is overlooked. We hence provide Web service consumers with valuable tools and guidelines that enable verifying correctness of their Web service-based applications. Our approach has a sound formal foundation which opens the opportunities of many automated applications that exploit the specification in order to deduce facts about service behavior.
[10]
Our future work includes an empirical evaluation of the usefulness of a service data contract at different level of sophistication. This should facilitate a cost-benefit analysis to decide on the time and effort invested by service providers in specifying their services.
[15]
6. ACKNOWLEDGMENTS
[17]
[11]
[12]
[13] [14]
[16]
This work was partially supported by the National Science Foundation Award 0705130 and 1004014. [18]
7. REFERENCES [1] [2]
[3]
[19]
Amazon Associates Web Service. http://aws.amazon.com/. Barnett, M., Rustan, K. et al. 2004. The Spec# programming system: An overview. Construction and Analysis of Safe, Secure, and Interoperable Smart Devices. 3362, (2004), 49--69. Cheon, Y., Leavens, G. et al. 2005. Model variables: cleanly supporting abstraction in design by contract: Research Articles. Software -Practice & Experience. 35, 6 (2005), 583-599.
[20] [21]
42
Date, C. 2003. An Introduction to Database Systems. Addison Wesley. Deutsh, A. and Vianu, V. 2008. WAVE: Automatic Verification of Data-Driven Web Services. IEEE Data Engineering Bulletin (2008), 35-39. Formal Specification Examples. http://users.csc.calpoly.edu/~gfisher/classes/308/doc/refman/formal-spec-examples.html. Accessed: 01-28-2010. Hoare, C.A.R. 1969. An Axiomatic Basis for Computer Programming. Communications of the ACM. 12, 10 (1969), 576-580. Kilov, H. 1990. From Semantic to Object-Oriented Data Modeling. Systems Integration, 1990. Systems Integration '90., Proceedings of the First International Conference on (1990), 385-393. OASIS Business Transaction Protocol. http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=businesstransaction. OASIS Web Services Business Process Execution Language (WSBPEL). http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=wsbpel. OASIS Web Services Transaction (WS-TX). http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=ws-tx. OWL-S: Semantic Markup for Web Services. http://www.w3.org/Submission/2004/SUBM-OWL-S20041122/. PayPal X Developer Network. https://www.x.com/. Saleh, I., Kulczycki, G. et al. 2009. Demystifying DataCentric Web Services. Internet Computing, IEEE. 13, 5 (2009), 86-90. Saleh, I., Kulczycki, G. et al. 2009. A Reusable Model for Data-Centric Web Services. Formal Foundations of Reuse and Domain Engineering. 288-297. Souto, R. 1994. On the Formal Specification and Derivation of Relational Database Applications. University of Glasgow. Voas, J.M. and McGraw, G. 1998. Software Fault Injection: Inoculating Programs Against Errors. John Wiley & Sons. Vossen, G. 1995. On Formal Models for Object-Oriented Databases. SIGPLAN OOPS Mess. 6, 3 (1995), 1-19. Wayne Heym 1995. Computer Program Verification: Improvements for Human Reasoning. The Ohio State University. Web Services Description Language (WSDL) Version 2.0. http://www.w3.org/TR/wsdl20/. Yang, F., Shanmugasundaram, J. et al. 2006. Hilda: A high-level language for data-driven web applications. In proceedings of the 22nd International Conferences on Data Engineering (ICDE’06). (2006), 32--43.
