| Daniela Florescu | Andreas Grünhagen | Donald Kossmann |
| XQRL, Inc. | Technical University Munich | Technical University Munich, XQRL, Inc. |
| dana@xqrl.com | gruenhag@in.tum.de | kossmann@in.tum.de |
We present an XML programming language specially designed for the implementation of Web services. XL is portable and fully compliant with W3C standards such as XQuery, XML Protocol, and XML Schema. One of the key features of XL is that it allows programmers to concentrate on the logic of their application. XL provides high-level and declarative constructs for actions which are typically carried out in the implementation of a Web service; e.g., logging, error handling, retry of actions, workload management, events, etc. Issues such as performance tuning (e.g., caching, horizontal partitioning, etc.) should be carried out automatically by an implementation of the language. This way, the productivity of the programmers, the ability of evolution of the programs, and the chances to achieve good performance are substantially enhanced.
XML is the lingua franca for data exchange on the Internet. Among its many possible uses, XML-based languages are ideal for publishing documents on Web sites, for storing catalogs in electronic market places, and for exchanging data between business processes. Even though some data sources will probably continue to use relational and object-relational database systems as a primary form of storage (at least for a certain time), we expect that most data sources will eventually provide XML access for their published data. Software vendors and standard bodies, like the W3 consortium, have been very active in providing tools (XML parsers) and standardized languages (XSLT, XPointer, XPath, XQuery, etc.) for XML. So far, however, no imperative programming language has been proposed that is specifically tailored for building XML applications and Web services, and, unfortunately, side-effect free languages like XSLT and XQuery are not powerful enough to describe the logic of complex Web services.
The concept of "Web services" became recently very popular; however, there is no clear agreed upon definition yet. By a Web service we understand an autonomous piece of software uniquely identified by an URI and that can interact with peer Web services via messages using Internet protocols like XML, XMLP or HTTP. Web services can, but they are not required to, preserve an internal state. In addition, Web services can participate in complex conversations. A conversation is an exchange of correlated messages among a certain number of participant Web services. By exchanging messages during a conversation the participant Web services strive to achieve a certain (business) goal; e.g., place an order, place a bid, send a request for information. The Web services can, but they are not required to, maintain contextual or historical information about the messages exchanged as part of a certain conversation. The Web services can, in general, perform several operations, each being specialized to a certain task. Operations are invoked by XML messages using the emerging XML protocol [XML:Protocol]; the result of the execution is sent back to the originator using the same protocol.
As of today, most Web services are built using classic programming languages, such as Java or Visual Basic, and some kind of SQL-based RDBMS (e.g., Oracle or DB2), a mixture of paradigms that inherently implies a number of logically irrelevant but costly and error prone intermediate data-transformations. An XML Web application built on such technologies will have to deal with difficulties such as:
Language implementors and database manufacturers are making great efforts
to increase their products with "XML extensions" and to
introduce automatic treatment for those chores whom programmers are
currently dealing with manually. Indeed, there are significant efforts
both on the Java side, from database and third-party vendors in these
directions. However, we believe that the
type systems of XML, Java, and relational database systems are simply
too different and ultimately incompatible for productively
building large scale applications that span across the three
different paradigms.
In addition to the double impedance mismatch, programmers face another
problem that drastically impacts both the productivity and the
performance of Web services. The problem is that, very often, the
application tier mixes in a dangerous way, in the same imperative
language (e.g., Java), very different semantic actions. For example,
low level protocols manipulation and performance improvements are
often mixed with data validation and real application logic.
In the case where those different semantic actions are strongly
interleaved, the application evolution is almost impossible. Imagine
the difficulty of changing the data model or the logic of such an
application, where data spans three different paradigms and data
instances are present in the three different layers and, potentially,
cached or materialized in various places on the platform!
The alternative that we are pursuing with this paper is to introduce
a new high-level programming language called XL for the specification of
Web services. There are a couple of reasons why we believe that such a
language can simplify the above problems. First, we believe that
programmers should use a single data representation and type
system to program a Web service. For obvious reasons we believe that
this unique type system should be based on XML. Moreover, the language
should be, as much as possible, declarative and
high level.
We listed above a couple of semantic actions that are interleaved
today, with unfortunate consequences. Among those, we believe that all
the performance improvement mechanisms should not be programmed
by hand, but derived automatically. A lesson that we all learned from
the success of relational databases is that the ability to do
automatic optimization is a key factor in the possibility to evolve an
application and to be robust to the inevitable hardware or software
platform evolution, or the environment evolution (data volume or
statistics, application workload). Such a declarative, high level
language can simplify or solve this problem, since it provides great
opportunities for automatic optimizations like application transparent
caching, replication, partitioning, or load balancing.
Another important feature of XL is that other semantic actions, like
data validation, error handling, and scheduling, are as much as
possible separated from the application logic itself and, as much as
possible, specified in a declarative manner
Five fundamental principles underlie the design of this new language:
The rest of the paper is organized as follows. Section 2 describes the main design goals for a programming language for Web services. Section 3 gives a short reminder of existing XML related standards (data model, schema, and expression/query language). Section 4 details the design of XL. Section 5 gives a simple example: an auctioning system. Section 6 gives a brief overview of related work. Section 7 concludes this work.
In this section, we will describe a list of more specific requirements that drove our design of XL. Some of the requirements are derived from the global architecture in which a Web service specified using this language should be integrated.
A very popular wrong myth related to XML is that "XML is just a
syntax, and programmers cannot reason on a syntax". While it is
indeed true that the original XML recommendation described only a
syntax for data and documents, and not a logical data model,
the W3C is currently in the process of standardizing such a logical,
abstract data model for XML. The purpose of an abstract data model has
been clear since the original papers of Codd in the 70's: it allows
programs to achieve logical and physical data
independence. In other words, programmers can concentrate on the abstract
representation of data and they can ignore the real physical representation
of the data. As a result, the physical data representation
can evolve without any impact on the code of the applications
itself. The huge advantage of this concept has been validated in the
last 30 years by the success of the database industry.
Fortunately, the XML standards did not ignore this important
database heritage. The semantics of the current W3C's XML related
programming languages (XSLT and XQuery) are described in terms of an
XML abstract data model [datamodel] that serves the same purpose
as the relational data model for relational databases.
The W3C XML data model describes, in an E/R fashion, a set of entities
present in an XML document and a set of relationships among them. The
entities describe the data itself (e.g., nodes, values, sequences) and
schema components. The data is modeled as very general mathematical
structures, i.e., as ordered trees of nodes. The internal
nodes have node identity and they can be of several kinds
(e.g., document nodes, element nodes, attribute nodes, comment nodes,
processing instruction nodes, namespace nodes) while the leaves of the
trees, i.e., the values, can be values in the domains of the XML Schema
basic types (e.g., integer, decimal, string, duration). Pivotal to the
XML data model is the notion of sequence. One important
property of the XML data model is that sequences are always
flat; i.e., sequences of sequences are automatically unnested.
Another important property of the XML data model is the
ability to capture the topological order in nodes of the document.
This order can be queried and exploited during the
computation. Finally, an XML data model is also able to model
errors, which are accepted intermediate results of various XML
computations.
The data model describes only the basic composition of ordered tree.
The XML Schema [XML:Schema] describes structural and
content-based constraints on the ordered trees. The XML Schema
describes the simple types (with their accepted domain values and the
accepted basic operations) supported by the XML data model, the
definition of user-defined complex types and gives a basic support for
user-defined integrity constraints (e.g., referential integrity
constraints, lexical constraints).
The XML type system formally described in [formalxquery] captures
the essence of the structural information present in the XML
Schema. The goal of the type system is threefold. First, it allows
automatic type inference: given an XML expression (as
described in the next paragraph) and the type of the input data set,
the type system is able to intentionally (i.e., without executing the
query on any particular data set) derive the type of the
result. Second, it is possible to do type checking: given an
expression and the expected type describing the input data set, it is
possible to derive that the expression will return errors on all (or
some of) the valid instances of the input type. Finally, the type
system is capable of testing the type subsumption. This is a
useful feature for the following scenario: given an XML expression and
the type describing the expected input data set, detect automatically
if the result of the evaluation of the expression on all valid input
data instances will be valid instances of a predefined expected output
data type. More detailed information about the type system can be
found in [formalxquery].
A complementary W3C standard
deals with XML expressions and XML queries [XML:Query]. XQuery is
a functional language. Like all functional languages,
XQuery expressions are constructed using first order and second order
function applications starting with variables and constants.
Examples of first order functions are:
logical, arithmetic, string manipulation, collection oriented
operations like union, intersection, and difference. Examples of second
order functions are map and
sort. Of particular importance are the second order FLWR
expressions: they are XML expressions constructed based on a pattern
that is akin to SQL's SELECT-FROM-WHERE queries. Like SQL queries, a
FLWR expression has a special clause to define variables and
their associated domains (the FOR clause in XQuery corresponds to the
FROM clause in SQL), a special clause that filters variable bindings based on
predicates (the WHERE clause in both languages) and a special clause
that specifies how to construct the result (the RETURN clause in
XQuery corresponds to the SELECT clause in SQL). Special expressions
called {\em path expressions} are used in order to navigate in an XML
tree; the syntax and semantics of path expressions are defined in the
XPath standard [XML:Xpath].
XML queries [XML:Query] are declarative, side effect free programs
that manipulate XML data. A query is composed of a preamble containing
function definitions, local type declarations, function declarations,
XML schema imports, plus a main expression to be evaluated and
returned as a result of the execution of the program. Unfortunately,
the logic of complex Web services cannot be described using only
declarative programs, or using only side effect free XML query expressions.
The programming language we propose in this paper extends the simple XQuery expression language to a full programming language, powerful enough to specify the logic of complex Web services. In this section we will describe the concepts of an initial design; these concepts provide a core functionality. More functionality (and syntactic sugar) are probably necessary to achieve wide acceptance. Moreover, the semantics of certain concepts (e.g., transactions or access control) need further investigation; they are omitted from this paper.
A Web service in XL generalizes the notion of an XQuery entity. In
addition to a query, a Web service is identified by a unique URI (the
target URI). Like an XQuery entity, a Web service specification can
contain a set of local function declarations plus a set of type
definitions and schema and namespace imports. In addition, a Web
service specification in XL can contain: (a) local data declarations,
(b) declarative clauses, and (c) specifications of the Web service
operations.
The syntax of XL for Web services is as follows.
Here and in the rest of the paper, keywords are denoted in bold-face
and non-terminals are enclosed in angle brackets. Optional parts are
denoted in square brackets. Comments are represented in italics. An
asterisk is used if a clause can occur 0 or more times. The order in
which the individual clauses occur is arbitrary; the individual
clauses are separated by semi-colons.
Functions are defined in XL in exactly the same way as in XQuery. We will describe local declarations, declarative web service clauses, and operation specifications which are specific to XL in the following subsections.
As in XQuery, a Web service implemented in XL can have local types and
imported schema components. In addition, an XL Web service can
declare local variables. Such variables hold only XML data and their
potential values can be constrained by the XML type system. Two kinds
of local variables can be declared in XL. The first kind of
variables represents the internal state of the whole Web service.
These variables are instantiated once when the Web service is
installed and persist the whole life time of the Web service. The
scope of these variables is the whole Web service. An example is the
customer database of an online broker.
The second kind of variables represents the internal state of a
particular conversation that the Web service is involved in. Examples
are the session id when a user logs into the system or the maximum bid
for an item in an auctioning system. These variables are instantiated
when the Web service joins a new conversation; in other words, when
the Web service receives the first message with a specific
conversation URI\@. We assume here that the SOAP messages which are
exchanged between Web services can carry the unique identifier (URI)
of a conversation in their envelop
.
This kind of variables can be used in the body of
all operations of the Web service that participate in conversations;
i.e., all operations that are able to receive messages that carry the
URI of a conversation. The life time of such variables is bound by the
life time of the conversation. Since the Web service can be involved
in several conversations at the same time, multiple instances of such
variables can exist at the same time; one instance of each variable
for each conversation. In some sense, the set of all instances of these
variables can be thought of as an array that is indexed by the URIs of
conversations. In the buy operation of an online broker, for
instance, a session id variable will be used in order to determine
which customer invoked the buy operation; the right value
(i.e., instance) of this variable will automatically be set
using the conversation URI of the message sent from the customer to
the online broker. (Obviously, this conversation URI should not be
public in this example.)
The syntax for declaring these two kinds of variables is the
following:
In this syntax, the "type" is the optional type constraining the type of the variable's values, while "expression" is an XQuery expression describing the initial value of the variable. If no "expression" is given, then the variable is initialized to the empty sequence; if no "type" is given then the variable can be bound to any valid instance of the XML data model (see section 3.1).
Essentially, this part contains a set of high level declarations that control the Web services global state, how the Web service operations are executed and how the Web services interacts with other Web services. The syntax for these clauses is as follows:
In the following, we will briefly describe the individual clauses.
The meaning of the individual clauses will become clearer in the
discussions and examples of the following subsections.
| Pattern | URI of Input Message | URI of Outgoing Messages |
|---|---|---|
| Required | none C2 |
C1 C1 |
| RequiredNew | none C1 |
C2 C2 |
| Mandatory | none C1 |
error C1 |
| NotSupported | none C1 |
none none |
| Supports | none C1 |
none C1 |
| Never | none none |
C1 error |
Each Web service can perform multiple tasks, each described by an
operation. As mentioned earlier, an operation is called every time a
Web service receives a message. An operation, therefore, gets the
content of a message as input, carries out a number of statements
based on this input, and generates a message with the output.
Consequently, unlike XQuery functions that can have multiple inputs
and exactly one answer, XL operations have exactly one input and at
most one output. Within every operation, two variables are defined
implicitly: $input and $output. The $input
variable is automatically bound with the content of the XML message
sent to the operation. The value of the $output variable is
computed in the implementation of the operation and automatically sent
back as a message to the caller of the Web service. The execution of
the operations can also result in errors which are sent also back as
XML messages to the caller.
In XL the specification of an operation is composed of the
operation's declarative clauses and the operation body. The
syntax of an operation specification is as follows:
As for the whole Web service, the declarative clauses of an operation control the run-time behavior of the given operation. Some of the clauses are identical in syntax and semantics to those of the Web service and serve only to refine the global Web service behavior ( HISTORY, CONVERSATION PATTERN and ON ERROR INVOKE). We remark that the notion of an conversation timeout cannot be associated with a single operation. Other clauses like the PRECONDITIONS, POSTCONDITIONS, and NO SIDEEFFECT are specific only to operations, and we will describe them next. The syntax is as follows:
This is a condition that is checked before
the first statement of the body of the operation is executed. If the
condition fails (i.e., evaluates to the Boolean value FALSE), an
exception is raised. The exception is specified in the THROW clause.
Within the header of an operation, any number of preconditions can be
defined. If there are several preconditions, these preconditions are
evaluated in a random order.
Typically, preconditions will test certain properties of the
$input variable; e.g., the existence of certain elements or the
range of the value of certain elements. Preconditions, however, can
also involve internal variables which are declared in the local
declarations of the Web service (see Section 4.1). The
precondition could also depend on some external conditions. The
following precondition would specify that the buy operation
can only be called while the status of the online broker is open:
A postcondition is checked after the
last statement of the operation has been executed. Typically, a
postcondition will involve the $output variable but, again,
any kind of Boolean expression can be used.
If a postcondition fails, the given
exception is raised. If more than one postcondition is defined, the
postconditions are evaluated in a random order. If an exception is
raised by a precondition, then no postcondition is evaluated.
Likewise, postconditions are not evaluated, if an exception is raised
within the body of the operation and the exception is not handled
within the body of the operation.
An example for a postcondition is to validate the type of the
$output variable before it is sent as a response to the caller of
the login operation:
This clause specifies that the operation has no sideeffects; i.e., the operation is an observer and does not change the internal state of the Web service or of any other Web service it might call. Operations that have no sideeffects can be invoked as part of expressions; otherwise, an operation cannot be invoked as part of an expression and it must be invoked as part of a statement (described in the next section).
XL extends the notion of XQuery expressions to statements. The body of an XL operation is described by such a statement. In addition to classic imperative statements like variable assignment, conditional statements, loops, error handling and return statements, XL supports some additional ones: some are XML specific (e.g., the update statements) and others are Web services specific (e.g., Web services invocation, logging, sleep). Finally, in addition to the classic imperative statement combinator (sequencing), XL contains other statement combinators borrowed from the workflow and dataflow theory (e.g., dataflow, parallelism, choice).
In this section we introduce some of the basic atomic statements that can be used in the body of an XL program. (Statements used for specific services will be discussed in the following subsections.)
Variable assignments The simplest statement is the assignment of a local variable. The syntax is as follows:Local variables need not be declared before being used. However, the (XML schema) type of a variable can optionally be set as part of the first assignment to this variable. The scope of a variable is the block where the variable is defined (see Subsection 4.6). Expressions can be any expression defined by the W3C XQuery proposal [XML:Query].
Update Statements Unfortunately, XQuery does not yet provide expressions to manipulate XML data. There are plans to extend XQuery in this respect and once a recommendation has been released by the W3C, XL is going to adopt the syntax and semantics of these expressions. In the meantime, we will use the following statements to manipulate XML data:
The general syntax of the update statements is as follows
:For move, the second expression must uniquely identify the position to which to move the XML nodes; in other words, the second expression must evaluate to a single node of the XML data model.
Service Invocation Statements
Probably the most relevant atomic statements in XL are those used for
invoking other Web services; i.e., sending a message to another Web
service. Often, the other Web service will be written in XL, but
messages can be sent to any service that have a URI and respond to
SOAP messages [SOAP]. Web services are invoked independently of
the specific way they are implemented. We propose two ways to invoke a
Web service as part of an XL program: synchronous and asynchronous.
The syntax of a synchronous call is as follows:
The semantics are straightforward. A message with the value
of expression is sent to the Web service identified by
uri. If a specific operation of that Web service should be called,
then the name of the operation can also be specified. Otherwise,
the default operation of the Web service is invoked. In a synchronous
call, the execution is halted until the called Web service finishes
its execution and returns the entire result (also wrapped in a SOAP
message).
If a variable is given as part of the call, then
the body of the message returned by the called service is copied into
this variable. The message is sent exactly once and in a best effort
way. Quality of service guarantees and other specifications such as
"as often as possible" or "at least once" which might become part of the
XML Protocol recommendation [XML:Protocol] cannot be expressed in
the current version of XL. We plan to extend XL accordingly once the
XML Protocol recommendation has been completed.
As an example, consider the following synchronous service invocation
that asks the online broker to buy
1000 SAP for at most Euro 140.00; the result is stored
in the $receipt variable:
The syntax of an asynchronous call is similar to the synchronous one:
In terms of the semantics: in this case the execution will not block and the program will immediately continue executing the next statement after the message to the called service has been sent. If the output (normal reply message or error) needs to be processed, then the name of the operation that will process the asynchronous result can be given as part of the call; this operation has to be a member of the Web service that originated the asynchronous call. Again, the message is sent exactly once and in a best effort way.
Assertions Recall that it is possible to define preconditions and postconditions of XL operations (see Section 4.4). The more general concept is the concept of an assertion that can be executed at any point during the execution of an XL operation. Assertion statements are described using the following notation:
If the Boolean expression evaluates to TRUE, the execution continues normally. Otherwise, an exception is raised. The second expression specifies the exception that is raised in this case.
Just like most other programming languages, XL provides an IF-THEN-ELSE statement in order to carry out conditions:
The semantics are straightforward and the same as in other imperative
programming languages.
Furthermore, XL supports the following SWITCH statement:
Again, the semantics are straightforward. The Boolean expressions are checked from the top to the bottom until an expression evaluates to TRUE. At most one statement is executed - after that the switch statement terminates without considering any other Boolean expression. (In C++ and Java, break statements are used for this purpose.) The DEFAULT clause is optional.
XL supports three different kinds of loops: WHILE loops, DO-WHILE loops, and FOR-LET-WHERE-DO loops, with the following syntax:
and
and
The FOR-LET-WHERE-DO loop corresponds to FLWR expressions in XQuery [XML:Query].
Web services implemented using XL signal failure by throwing exceptions - just as in Java or C++. The syntax of the XL statement that raises an exception is as follows:
Here, expression can be any kind of XQuery expression. If the exception is not handled locally (see below), the execution of the operation terminates and the value of the expression (instead of the value of the $output variable) is returned as a message to the caller of the service. Just like variables and any other expression, the exceptions can be strongly typed optionally.
XL also adopts the Java syntax for catching exceptions. TRY is used to indicate a statement (or sequence of statements) in which an exception might be raised; CATCH is used to write code that reacts to exceptions. The syntax is as follows:
The variable in the CATCH statement is bound to the value of the data carried by the exception that is raised while executing the statement(s) of the TRY statement. Like in Java, a caught exception will trigger the execution of the associated statement.
Obviously, the body of an XL program can contain more than one atomic statement. There are several ways to combine statements. In the following "statement1" and "statement2" can refer to any atomic statement as the ones described in the previous sections or to any combination of statements [WebL].
The typical way to combine statements is by using the ";" symbol, like in C++ or Java. Thus, the following means that "statement1" is executed before "statement2".
If "statement1" fails, execute "statement2".
Execute either "statement1" or "statement2", but not both. Which one is executed is nondeterministic.
Execute "statement1" and "statement2" in parallel. In other words, the order in which the individual statements are carried out is not specified.
If there are data dependencies between "statement1" and "statement2" (e.g., "statement1" binds a variable that is used in "statement2"), then execute the statement that depends on the other statement last. If there are no dependencies, then execute "statement1" and "statement2" in any order (or in parallel). If there is a cyclic dependency, then this combination of statements is illegal.
As in C++ and Java, we use the following syntax to identify a block of statements. The body of an XL program, for instance, is formed as a block of statements. The scope of a variable is the block of statements in which the variable is used for the first time.
XL also provides a series of additional statements that are very helpful to implement Web services. We list them in the following.
As mentioned in Section 4.1, there is an easy way to specify in XL that all calls to operations are logged in an automatic way - simply, the keyword HISTORY must be written in the declaration of a Web service. This way of automatic logging only involves calls to a Web service, the timestamp of the call, and the $input message sent by the caller. In order to write more information into a log, we propose the following syntax.
As a result of the execution of this statement, the expressions 1 to N are evaluated before and after the execution of the statement (or series of statements) and their values are inserted each time into the $history variable using the respective names.
The RETURN statement terminates the execution of an XL operation and returns the current value of the $output variable.
The HALT statement terminates the execution of an XL operation without returning any message to the caller. In the absence of a RETURN and HALT statement, the body of the XL operation will be executed and the content of the $output variable is returned after the last statement of the XL operation has been executed.
The NOTHING statement represents the empty statement useful in certain cases of workflow.
The SLEEP statement stops the execution of an XL program for a certain duration. For instance, the following statement will stop the execution for 10 minutes:
The XQuery expression xf:duration(``P10M'') generates an XML value of type duration; in order to do this, it uses the function xf:duration defined in the XQuery built-in function and operation library.
Sometimes it is important to suspend the execution of a program until a certain event has happened. Examples for events are data updates, messages received, or certain points in time have been reached. For instance, the following statement will suspend the execution of an XL operation until the balance of the customer is more than 1000:
Analogously, we propose a WAIT ON CHANGE statement that stops the execution of a program until the value of a variable has changed. For instance, the following statement will stop the execution until there is some change to the $history variable. This statement could be part of an operation that continuously monitors all the interactions of a Web service in order to, say, detect fraud.
Note that the following two statements are not equivalent, if the execution of a program should be halted until some given timestamp (xf:currentDateTime() is the XQuery/XPath function that returns the current Timestamp [XQuery:FunctionLib]):
The busy wait in this example does not work because there is no guarantee that the condition will be checked at every point in time.
A typical programming pattern in Web services is repetitive execution of statements until their successful completion, e.g. try to send a message until an acknowledgment is received. XL provides a convenient syntax to facilitate the programming of such patterns, as follows:
This statement will attempt the repetitive execution of the statement until the execution finishes without an exception, or at most a certain number of times (if a MAXIMUM clause is given) or for a maximum duration (if a TIMEOUT clause is given).
For instance, the following statement will try to charge the visa credit card of a customer three times. Such a payment can fail temporarily for various reasons; e.g., if servers are overloaded. If all three times fail, however, it is assumed that there is something wrong with the credit card and an exception that indicates an illegal payment method is raised:
In this section we show how an auctioning system can be implemented
using XL\@. We show the global definitions and declarations of this
Web service and the takeBid operation. The full example,
including definitions for the other operations (e.g., starting and
ending an auction), is presented in [XL:TechReport].
An auction is carried out as a conversation in which the
auctioning system and potentially a large set of bidders participate. Several
such conversations (i.e., auctions) can be carried out concurrently;
in particular, each bidder can simultaneously participate in several
such conversations. In order to give a new bid, bidders invoke the
takeBid operation of the auctioning system. If the bidders
are also implemented in XL, bids are automatically associated to the
correct auction; if not, bidders must explicitly set the uri of the
conversation as part of the SOAP message they send to the auctioning
system. When a new bid is entered, the other participants of
the auction are automatically informed so that they can react.
An auction terminates after a period of 10 hours with no new bids.
This period is specified in the CONVERSATIONTIMEOUT clause. The end
of an auction is implemented by the closeAuction operation
(not shown). Of course, not everybody should be authorized to call
this operation; extending XL for authorization is part of future work
so that such restrictions are not implemented here.
The development and composition of Web services (or e-services) is currently a very active area in both industry and academic research. Very good resources that address various aspects of this area are the recent W3C workshop on Web services [W3C:Web:Workshop] and the latest issue of the IEEE Data Engineering Bulletin on e-services [debull:eservices]. The main purpose of our work was to provide a clean basis for a new XML programming language for rapid development of Web services. Such a language will obviously not be built from scratch but using the knowledge and technology advancements accumulated in the last 40 years.
In the industry, there have been a number of concrete proposals for new languages and frameworks related but not identical to our programming language proposal---most prominently, SUN's J2EE [J2EE] and SunOne [SunOne], and Microsoft's .NET initiative [Dotnet]. Compaq has developed the WebL language [WebL]; HP has developed the eFlow and eSpeak systems [eFlow], [eSpeak], IBM is working on a language called Web Service Flow Language [WSFL], and Microsoft has recently released their BizTalk Server 2000 [BizTalk] and XLANG [XLANG]. While there are many similarities between WSFL and XLANG on one hand and XL on the other hand, there are a couple of major differences. First, both WSFL and XLANG are XML programming languages in the sense that they have an XML syntax; our understanding of an XML programming language is a language that manipulates only XML data, independently of the syntax of the language itself. Second, both WSFL and XLANG are able to describe only how to compose existing Web service components (that are expected to be implemented using other languages), while XL is complete not only with respect to Web service composition but also specification. Using XL, it should be possible to implement complex Web services entirely without any need for any other programming language. Finally, and more importantly, XL adds to Web services the concepts of declarative behavior specification inherited first from relational databases and then from J2EE.
Two other specifications worth mentioning are the Business Process Model Initiative whose goal is to implement cross-organization processes and workflows on the Internet [BPMI] and DAML-S whose goal is the automation of Web services using ontologies [DAML]. Moreover, the state of the art in the Java world is to support XML via so-called servlets that translate (XML and HTML) requests into Java classes and back [Jakarta]. Furthermore, the J2EE framework provides a number of features for service composition, conversations, database interaction, transactions, and security [J2EE]. Recently, Sun Microsystems introduced the JXTA project on peer-to-peer computing to support distributed computing on the Internet [JXTA]. SAP has recently announced an own effort to implement a Web services platform [SAP:platform]. Finally, the notion of a service composition is based on a solid theoretical background consisting on the calculi developed first by Hoare [CSP] and more recently by Cardelli [Cardelli:WebServiceCalculus]. However, none of those languages and frameworks are totally consistent with the current W3C standards, and we believe that this is a mandatory condition for the success of such a programming language.
Our short-term goal is to foster discussions that will eventually come to a consensus for a complete design of such a language. Open questions involve the syntax and semantics for transactions, support for more comfortable conversations, constructs to explicitly set the SOAP envelop of a message, implementation of multi-casts, and security aspects (e.g., authorization and encryption). In the long run, the implementation of XL and of a global infrastructure for Web service composition will involve a large number of new research opportunities; e.g., code mobility, automatic caching and optimization. One particular issue is to find out what kind of meta-data is necessary in order to describe a Web service and make these optimizations possible.
The language we propose here is currently being implemented; we hope to have a demo available on the Web in summer 2002.