ServiceJ A Java Extension for Programming Web Services Interactions

ServiceJ – A Java Extension for Programming Web Services Interactions

Sven De Labey, Marko van Dooren, and Eric Steegmans

K.U.Leuven, Dept. of Computer Science

200A Celestijnenlaan, B-3000 Leuven, Belgium

{

svendl,marko,eric

}

@cs.kuleuven.be

Abstract

Object-oriented programming languages are losing pace with the rapidly evolving Web Services paradigm. They are unable to deal with the distributed, volatile nature of web services, and they lack expressive language constructs for complex web service interactions. In this paper, we present ServiceJ, a Java extension with integrated support for web service programming. By extending the type system with type qualifiers, ServiceJ realizes important objectives from both paradigms. On one hand, ServiceJ resembles Java by promoting reuse and abstraction, and by supporting type-safe web service invocations. On the other hand, ServiceJ supports late web service binding, Quality of Service nego-tiation, and transparent web service failover.

We provide an in-depth discussion of our type system ex-tension, formally prove its type soundness, and compare our language extension with related object-oriented and service-oriented programming languages.

1. Introduction

The paradigm shift from in-house, homogenous dis-tributed systems to diversified cross-organizational web ser-vice architectures imposes new challenges on application developers [30]. These challenges originate from (1) the inherent volatilityand (2) thedistributed natureof web ser-vices. Being volatile, service applications must cope with newly joining services, service migration, incompatible ser-vice updates and serser-vice deprecation. Being distributed, ap-plications must deal with availability problems caused by router failures, network errors or server outages.

Object-oriented programming languages such as Java Enterprise Edition 5.0 [22] deliver the main technology for developing enterprise systems, but their current pro-gramming models are not adequate for implementing com-plex interactions with remote web services. By too slowly adopting the web services paradigm, object-oriented pro-gramming languages make the programmer responsible for 1_{Research funded by a Ph.D. grant of the Institute for the Promotion of}

Innovation through Science and Technology in Flanders.

the implementation of technical middleware algorithms for dealing with low-level volatility and distribution issues [33]. In this paper, we present ServiceJ, an extension of Java with integrated support for Web Service programming. Ser-viceJ improves other object-oriented solutions in two ways. First, it deals withservice volatilityby supporting late ser-vice binding, QoS constraining, and optimal serser-vice selec-tion. Second, it copes withdistribution issuesby providing transparent service failover and by offering constructs for creating ad hoc web servicesessions.

This paper is structured as follows. Section 2 assesses how Java supports Web Service programming, leading to a list of design goals for our language extension. Section 3 presents ServiceJ and its new language constructs. Sec-tion 4 briefly discusses the formalizaSec-tion of ServiceJ, and Section 5 outlines its implementation. An evaluation of our approach is presented in Section 6. Finally, Section 7 dis-cusses related work, and Section 8 concludes.

2. Java Language Support for Web Services

From the release of the Java API for XML-based Web Services 2.0 (JAX-WS [23]), the Java Enterprise Edition programming model [22] includes an annotation,

@WebServiceRef, to define a web service reference. The information found in this annotation typically consists of (1) the location of the remote WSDL file and (2) the type of theservice interface, as shown in the code sample below. The runtime system uses this information to initialize the field with a reference to the remote service endpoint. @WebServiceRef{

wsdlLocation="www.service.url/t.wsdl", type=T.class}

T myService; //initialized by container From the viewpoint of service-oriented computing, this level of support is problematic for a number of reasons:

1. Static Service Binding.The use ofwsdlLocation

attributes hardwires service references to physical web service locations, thus requiring code revisions to han-dleservice migrationandservice deprecation. But this is not manageable because the annotations to be up-dated may be scattered throughout the entire

applica-tion. An alternative approach could be to externalize service addresses in a deployment descriptor [22], but even then, the dynamic nature of web services causes (1) frequent and complex revisions of a verbose XML file and (2) application redeployment.

2. Flexibility. By relying on hardwired URLs, Java forces users withdifferentpreferences to use thesame service, even though there may exist services that bet-ter suit their needs.

3. Distribution. The @WebServiceRef annotation makes it impossible to reroute requests to backup end-points. If a service crashes, the client must either wait until that service recovers, or wait until someone updates the annotation and redeploys the application. Both solutions are unacceptable.

4. Reuse and Adaptation. Exporting the application to a new service architecture forces developers to rewire every@WebServiceRefannotation to the services in that new environment.

5. Program Comprehension. Java makes the program-mer responsible for implementing service selection and failover. These algorithms cooperate tightly with the business logic, which obstructs a clean abstraction into reusable libraries or aspects. But their occurrence in the business logic decreases both the readability and the modularity of the source code, which in turn in-creases maintenance costs as well as the probability to introduce bugs in newer versions of the software.

2.1. Goals for Web Service Integration

This paper aims at defining an object-oriented language with integrated support for web service interactions. Obvi-ously, such an integrated language must satisfy design goals from both worlds. Therefore, we have defined a number of objectives originating from the world of Web Services, to-gether with some important requirements stemming from traditional Object-Oriented Software Development. The objectives related to web service programming (WS 1–6), on one hand, focus on the provision of expressive language constructs for service selection, and on enhanced runtime support for handling servicevolatilityanddistribution:

• WS1. Late Service Binding. Service references must be bound at runtime, possibly taking into account ser-vices that were dynamically discovered.

• WS2. Service Failover. Being confronted with avail-ability problems caused by server outages, router fail-ures, and network partitioning, applications need sup-port for web service failover to increase the probability to successfully execute a business operation.

• WS3. Constraint Handling. Clients must be able to impose functional requirements and Quality of Service constraints on a set of competing service providers.

• WS4. Preference-driven Service Optimisation. A list of candidate services must be sortable according to user-definedquality attributes, thus allowing to select the optimal service for each individual user.

• WS5. Service Sessions.Complex business operations comprise multiple client-service interactions. The run-time must ensure that suchsessionsare executed con-sistentlyandatomicallyon the target web service, thus requiring support for ad hoc web servicetransactions.

• WS6. Provider Unawareness. Interactions between a client and its service providers must be done using standard web service protocols (e.g. SOAP), without requiring the provider to install additional software. Our design goals related to object-oriented programming focus on statictype-checking,reuse, andabstraction:

• OO1. Static Type Checks. The language must sup-port compile-time type checking of web service inter-actions to increase the odds for encountering problems beforethe application is put online.

• OO2. Reuse. Reusing application components in an environment with different providers must be possible without source code modification. Thus, the business logic must beindependentof deployment decisions.

• OO3. Abstraction. Regarding issues such as service binding and failover, the language mustmaximize run-time support andminimize the task of the developer.

• OO4. Java Compatibility. Our Java extension must be compilable to Java. This ensures full compatibility with existing Java code and it guarantees that the stan-dard JVM can be reused as an execution environment. Java’s annotation-based model for programming web ser-vice interactions realizes onlyOO1,OO4, andWS6.

3. ServiceJ Language Extensions

ServiceJ aims at integrating web service interactions with the Java programming model. It does so (1) by in-troducingtype qualifiersto enable transparent failover, (2) by introducingdeclarative language constructsto fine-tune dynamic service selection, and (3) by providing session blocksto demarcate ad hoc web service transactions.

3.1. Service Pools

Advanced language support for enforcing QoS con-straints and user preferences (WS 3–4) requires a basic mechanism for late service binding (WS1) and, option-ally, for service failover (WS2). Therefore, ServiceJ re-moves the need to rely on hardwired web service URLs in

@WebServiceRefannotations. In stead of directly point-ing to these URLs, ServiceJ variables refer to aservice pool, a new language concept defined as follows:

Definition 1(Service Pool). A service pool of typeT, de-noted as PT, is an unordered, unbounded set of inter-changeable service endpointss₁, . . . , s_n such that for all 1≤i≤n, the typeS_iofs_iconforms toT (i.e.S_i≤T).

Figure 1: Java references and ServiceJ pool references There are two main differences between ServiceJ pool vari-ables and normal Java varivari-ables. First, both varivari-ables dif-ferconceptually, as shown in Figure 1. The Java variable is hardwired tos1and is unable to contact replicated in-stances (s2ands3) ifs1crashes. The ServiceJpool vari-able, on the other hand, refers to a pool containing inter-changeable service endpoints and enables the runtime sys-tem to dynamically bind (and rebind)stos1,s2, ors3.

Second, ServiceJ pool variables differsyntacticallyfrom normal variables in that pool variables are declared with an additionaltype qualifier(pool) [32]. A qualified type such as pool FlightService, for instance, indicates that the runtime system must non-deterministically inject a ref-erence found in the pool ofFlightServicereferences.

Similar to Java variables, however, a ServiceJ pool vari-able is bound to one service at the same time(s1 in our example). Thus, programmatically, method invocation on pool variables resembles method invocation in Java. This allows programmers to treat a pool variable as a proxy to asingle virtual service. The runtime initializes this virtual service by injecting a pool member into the pool variable. This injected service is called theactive service:

Property 1(Single Active Service). A non-empty pool con-tains exactly one active service. Formally,

PT =∅ ∨ ∃!s∈ PT such thatactive(PT) =s. By transparently binding pool variables (p_T) to services from the corresponding pool (P_T), the runtime enableslate service binding. By transparently selecting and injecting a new pool member on service failure, the runtime also en-ables transparent failover. This self-healing property of pool variables is formalized as follows:

Property 2(Transparent Failover). Letp_T be a pool vari-able referring to a service pool P_T = {s₁, . . . , s_n}. Let mbe a method exported byT. DefineP_T,av as the set of reachable services inP_T. Then,

(1) p_T is bound toactive(P_T)∈ P_T,av⊆ P_T. (2) P_T,av=∅ ⇐⇒p_T.msucceeds

Example.Figure 2 gives an example of the runtime sys-tem acting as amediatorto enablelate service bindingand transparent failover. It shows how a pool variablepof type

Sis used to invoke operationm(exported byS). At thecode level, the pool is referenced as asingle virtual service, thus hiding its underlying complexity. Theruntime, on the other hand, has full access to the pool contents and injects, for instance,s1as the active service. After unsuccessfully in-vokings1.m, the runtime injects another service,s2, and invokess2.m, resulting in another error. Finally, after in-jecting s3, the call s3.m returns successfully ands3 is registered as theactive servicefor further invocations onp.

Figure 2: Transparent failover in service pools

Service Pool = Dynamic Population + Sharing

Service pools grow and shrink dynamically as a reaction to service discovery and service deprecation (see Figure 3). Their dynamic nature enables applications to interact with newly discovered services (e.g.Sn) without additional con-figuration or code modification. ServiceJ does not restrict how references are added to the pool. This can be done, for example, by using an in-house discovery mechanism, or by directly referring to the directory server of a provider.

Figure 3: A service pool is a shared set of services that evolves due to service discovery and service deprecation.

Another interesting property of service pools is that they areshared between applications, thus admitting cen-tral management of apool registryfor an entire enterprise SOA (as shown in Figure 3). Pool sharing improves the annotation-based approach of Java, which scatters service URLs throughout various applications running on the SOA. In this paper, we focus on the language design rather than ondeployment issues. As pool management does not

interfere with our design, we refer to [15] for a detailed dis-cussion on pool construction and maintenance.

3.2. Constraining Service Pools

By only requiring that the type of a pool memberS con-forms to the pool type T (S ≤ T), basic service pools provide too limited support for imposingmembership con-straintson pool candidates. Often, programmers need to constrain membership to those services that comply with a set of superimposed functional and non-functional require-ments (WS3). Functional constraints, on one hand, relate directly to the business logic of an application. For example, a pool ofFlightServiceinstances may be constrained to those travel agents that offer a flight from London to New York. Non-functional requirements orQuality of Service constraints, on the other hand, relate to web service avail-ability, performance, security, etc.

Java offers no language support for expressing con-straints on web services, thus forcing programmers to hard-code support for iterating through a list of service can-didates (WS1) until a service satisfies their requirements (WS3). This lack of abstraction violates our goals related to object-oriented programming (OO1,OO2, andOO3).

ServiceJ, on the other hand, makes the runtime system responsible for enforcing membership constraints. At the code level, programmers specify a boolean membership condition with a declarative operation,where. The runtime creates aselective viewon the shared pool by selecting only those candidates that satisfy that condition. An example is shown in Figure 4, where two pool variables, fandg, from two different applications each define their own mem-bership conditions c1 andc2 on F, leading toselective, personalizedviews on a shared service pool (P_F).

Figure 4: Declarative membership conditions c1and c2

induce a selective view in a shared service poolF.

Property 3(Constrained Pool Invocation).LetpT be a pool variable referring to a service pool P_T with membership conditionc. Letmbe any method exported byT. Define

PT,av,c as the set of services inPT containing only those reachable services that satisfyc. Then,

(1) P_T,av,c⊆ P_T,c⊆ P_T

(2) P_T,av,c=∅ ⇐⇒active(P_T)∈ P_T,av,c (3) P_T,av,c=∅ ⇐⇒p_T.msucceeds

Example. Figure 5 gives a detailed example of method invocation on constrained pools. It shows how a pool vari-ablepwith conditioncinvokes an operationm. On method invocation, the pool containingS1,S2,S3, andS4is fil-tered and only those services that satisfycare retained (S2

andS3). This explains whyS1is never selected as an ac-tive service in Figure 5. After constraining the pool, the call is sent toS2, resulting in an error and causing the failover mechanism to reinvokemonS3, which handles the request.

Figure 5: The runtime system transparently enforces the constraints that were specified using awhereclause.

3.3. Optimal Service Selection

Until now, all pool members were assumed to befully interchangeableas each member satisfies two basic require-ments: (1) its type conforms to the pool type, as enforced by the compiler and (2) every member satisfies the member-ship constraint (if any), as enforced by the runtime system. Therefore, pools are typically used to expressservice equiv-alence, thus justifyingnon-deterministicservice selection.

Often, however, some services in the pool have more ap-pealing characteristics than others. For example, a pool con-taining flight booking services from competing travel agents may offer flights at various price levels, and a customer may be interested in booking thecheapestflight available. This breaks our assumption of service equivalence, making the

poolqualifier less suitable. Therefore, we define asubtype of the pool qualifier,sequence, to indicate that the runtime system must pay attention to quality attributesduring ser-vice binding. In other words, thesequencequalifier in-stalls adeterministicservice selection algorithm:

Definition 2(Sequence). A sequence of type T, denoted as

ST,q is an ordered, unbounded set of interchangeable ser-vice endpointss₁, . . . , s_nsorted according to a set of qual-ity attributesq=q₁, . . . , q_nsuch that for all1≤i≤n, the typeS_iofs_iconforms toT(i.e.S_i≤T).

Developers specify quality attributes using a new declar-ative operation,orderby, that accepts aprimitive Java type or a JavaComparableexpression. On method invoca-tion, the runtime system scans through the pool and injects the member that most closely approximates these quality attributes into thesequence variable:

Property 4(Sequence Invocation). LetsT be a variable re-ferring to a sequenceST,qwith type T and quality attributes q. Letmbe a method exported by T. DefineS_T,q,avas the subsequence of reachable services inS_T,q. Then,

(1) S_T,q,av⊆ S_T,q

(2) S_T,q,av=∅ ⇐⇒active(S_T,q)∈ S_T,q,av (3) S_T,q,av=∅ ⇐⇒s_T.msucceeds

(4) ∃s∈ S_T,q,avsuch thatactive(S_T,q)<_q s for the sorting function<_qinduced by quality attributesq.

Figure 6: The runtime system selects the optimal service based on quality attributes from the source code.

Example. Figure 6 shows how a sequence is used to select the cheapest flight booker by sorting the pool ofFlightServiceinstances according to a quality at-tribute fs.getPrice(). The runtime system queries each member for the price of the flight and injects the ser-vice that minimizes this attribute into the sequence variable. ServicesS1,S2, andS3respond with 500, 450, and 600 re-spectively, soS2is injected. In case of a failure, the runtime system reinvokes the booking operation onS1.

3.4. Pool Sessions

The execution of a complex business operation often comprises multiple interactions between the client and a web service. This set of method invocations is called a session, and for consistency reasons, it is crucial that the pool variable is bound to thesame servicefor the entire ses-sion. This calls for acoarser-grained, transactional failover mechanism that extends our basic failover strategy (see Section 3.1). Therefore, ServiceJ introducessession{. . .}

blocks to combine related web service interactions into ses-sions. On entering a session block, the runtime injects a service into the pool variable as described in Sections 3.1– 3.3. From then on, the pool variable islockeduntil the ses-sion ends successfully, or until the injected service becomes unreachable. In the latter case, the runtimeaborts1_the cur-rent session,unlocksthe pool variable, injects another pool member, and then restarts the entire session. Thus, by in-troducing these session-scoped locks on pool variables, Ser-1_{Note that full atomicity is often impossible because pool variables may}

depend on external services outside the control of the developers.

Figure 7: Thesessionkeyword demarcates pool sessions viceJ allows developers to think of a session as anatomic, fault-tolerant interactionwith a remote web service.

Example. Figure 7 shows how developers use a

session{. . .}block to demarcate a session between a client and a FlightService. On starting the session, the runtime evaluates themembership constraint(where) and the quality attributes (orderby), causing the injection of

S1 intofs. The session is opened with an invocation of

regCustomer(). This call succeeds, but S1 crashes shortly afterwards. The failure is detected by the client as soon as the call tofinalizeBooking()returns an er-ror, causing the runtime to revert the session and inject an-other service (S2) intofs. The session is restarted by call-ing regCustomer() and finalizeBooking() on

S2, which successfully handles both calls.

4. Formal Model and Soundness Proof

Our formal model, calledFeatherweight ServiceJ[15], is an extension of Featherweight Java [20], a minimal core cal-culus for Java. Featherweight ServiceJ essentially extends the Java type system with type qualifiers. Each Java type C is decorated with a qualifierQ, thus creating aServiceJ type: T = Q C. The type qualifierQis either a pool, asequence, or a singleton. The singleton qualifier only exists in the formal model and is used to represent nor-mal Java variables. Featherweight ServiceJ was developed in order to prove thetype soundnessof ServiceJ, which is formalized in the following (simplified) theorem:

Theorem 1 (Type Soundness of ServiceJ). Given an ex-pression e of type T, then either e evaluates to a value x, e executes forever, or e evaluates to e’, which is stuck in a failed dynamic downcast.

Proof. Based on standard Subject Reduction and Progress Theorems, as used in [20]. A full proof is given in [15].

Due to space limitations, we cannot elaborate on our for-malization. Therefore, we refer to our technical report [15], which provides a detailed discussion of the Featherweight ServiceJ syntax, its typing and reduction rules, and a formal proof of the type soundness theorem mentioned above.

5. Implementation

Looking back to the design goals enumerated in Section 2.1, ServiceJ must be compatible with Java (OO4), and it must not require service providers to install additional soft-ware (WS6). In this Section, we outline how the implemen-tation of our language extension realizes both objectives.

(WS6) Service Providers are unaware of ServiceJ.The primary goal of the Web Services paradigm is the provi-sion of interoperabilityin heterogenous, distributed archi-tectures. ServiceJ fully supports this vision by relying on standard protocols such as SOAP and WSDL for interact-ing with web services. Unlike a number of other Java ex-tensions discussed in Section 7, ServiceJ does not require the service provider to install additional libraries since this would decrease the opportunities forcross-organizational web service interactions.

(OO4) ServiceJ runs on the Standard JVM. This is achieved by representing ServiceJ source code in JNome [27], our metamodel of Java, which is a specialization of Chameleon [27], our framework for object-oriented pro-gramming languages. After reading the source code into the metamodel, a transformation is executed which trans-lates ServiceJ to Java and injects the necessary algorithms for pool interactions, QoS constraining, and service selec-tion. The output of this transformation is then compiled with the Java compiler. Therefore, our JNome transforma-tion is actually apreprocessorfor the Java compiler, and the cooperation between both tools is commonly referred to as “the ServiceJ compiler”.

6. Evaluation

ServiceJ is evaluated by comparing its language constructs with our goals from Web Service programming (WS 1–6) and Object Oriented programming (OO 1–4).

Web Service Programming. By no longer hardwiring pool variables to service URLs, service pools enable load balancing and late service binding (WS1). By allowing the middleware to bind and rebind pool variables toanypool member, service pools support transparent failover (WS2). The need for constraining service candidates (WS3) is sat-isfied by thewhereoperation, whereas theorderby opera-tion installs adeterministic, optimal service selection pol-icy (WS4) based on quality attributes. Such fine-tuned pool variables are used insession blocksto execute business operations that comprise complex web service interactions (WS5). Additionally, we subscribe to the vision of inter-operable, platform-independent computing by allowing ser-vice providers to be unaware of Serser-viceJ (WS6).

Object-Oriented Programming. ServiceJ raises the level of abstraction (OO3) in two ways. First, the

plural-ity of services ishiddenfor developers, shielding them from service discovery, migration, failover, and deprecation. Sec-ond, algorithms for enforcing QoS constraints and service selection are configured usingdeclarative operations, thus hiding the technical details of these algorithms.

ServiceJ improves the reusability of an application (OO2) by removing all physical web service URLs from the source code. This approach fosters centralized, application-independent management of service provider alliances. In-deed, whether or not an application cooperates with a provider is entirely defined by the existence of references to that provider in the pool.

By introducing a type qualifier hierarchy where

sequenceis asubtypeofpool, and by integrating this qualifier hierarchy with the type system, we enable the com-piler totype-check web service interactions(OO1). For ex-ample, the ServiceJ compiler guarantees that an unordered set of interchangeable services (pool) can never flow to a place in the code where a deterministic, preference-driven selection policy (sequence) is required. Additionally, it can type-check the pool membership condition (where) and theservice selection policy(orderby).

Finally, ServiceJ is compatible with Java and runs on the standard JVM (OO4), as explained in Section 5.

7. Related Work

We compare ServiceJ withobject-oriented programming languages (Section 7.1) and markup languages (Section 7.2). Table 1 shows the scores of these languages relative to the objectives mentioned in Section 2.1.

7.1. Object-Oriented Programming

Java-based Languages. Jini [24] is a Java framework with support for late binding and dynamic discovery. De-velopers express serviceconstraintsby programming tem-plates. Such a template is sent to a discovery service and only services matching the constraints of this template are returned. This mechanism is weaker than ourwhereclause because it only supportsexact matchesonpredefined query instances. Another drawback of Jini is that developers must write a considerable amount of boilerplate code for service lookup, service selection and fault tolerance whereas Ser-viceJ transparently supports these features.

WSIF [26] is a Java API for shielding programmers from the technical details of web service invocation. The frame-work provides anabstract representationof web services, resembling ourvirtual service model. Similar to Jini, the functionality of the API is rather low-level, thus forcing de-velopers to write technical boilerplate code. Another prob-lem is that WSIF relies on hardcoded service endpoints, thus limiting reuse (OO2). Also, WSIF relies on the Java Reflection API, thus disabling compile-time checkable web

• Full Support Object-Oriented Programming Markup

◦ Minimal Support Java Web AOP Languages

Ja v a E E 5. 0 Jini WSIF JW ig GM I Pro A ct iv e Filterfresh JG roup Ja v aG roups mChaRM Tac tic s fo r RM I E x te nded R MI Se rv ic e C o m b. We b L We b O z XL AS IL Fu se J A 04B P E L AXM L Imp l. AXM L < Big W ig > BPEL BPELJ GPSL BP E L + P aram. WSM L Dy S O A

WS1– Late service binding • • • • • • • • • • • • • • • • • • •

WS2– Transparent failover • • • • • • • • • • • • • • • •

WS3– Constraint handling ◦ • ◦ ◦ ◦ • • •

WS4– Optimized selection ◦ ◦ •

WS5– Session Support • • • • •

WS6– Provider Unawareness • • • • • • • • • • • • • • • •

OO1– Safe invocation • • • • • • • • • •

OO2– Reuse • • • • ◦ • • • • • • • • • • •

OO3– Abstraction • • • • • ◦ • •

Table 1: Comparative study of integration between Object-Oriented Programming and Web Services Programming service invocations (OO1). This problem is solved in JWig

[11] and<BigWig>[7], by extending the type system. Ser-viceJ follows a similar strategy by integrating a hierarchy of type qualifiers with the Java type system.

GMI [28], ProActive [2], Filterfresh [1], JGroup [29], and JavaGroups [3] are Java-based languages and libraries developed for supportingfault toleranceandgroup commu-nication. These languages manage a collection of inter-changeable remote objects, comparable to ServiceJ pools. They turn out to be less appealing for web service progam-ming because they assume all remote objects to be equiv-alent at all times. Consequently, they lack constructs for expressing membership conditions (WS3) and quality at-tributes (WS4). Second, these languages provide insuffi-cient abstraction (OO3) because the programmer is forced to manage the pool contents in the source code. ServiceJ, on the other hand, completely hides the technical details of service pools by deferring pool management to the run-time system. Third, these languages require the service provider to install additional software, thus violatingWS6, which makes them unappealing for implementing cross-organizational web service interactions. Similar problems were detected in languages that extend the basic Java Re-mote Method Invocation mechanism in order to support fault tolerance and constrained method invocation, for ex-ample, mChaRM [9], RMI Tactics [16], and [35].

Web Programming. Language constructs for handling connectivity problems in web computing were first intro-duced by Cardelli et al. in [8]. They useservice combi-natorssuch as thesequential execution operator(denoted “S1?S2”) for stating thatS2 must be contacted if S1 is unreachable. Combinators are used in object-oriented lan-guages such as WebOz [18], WebL [25], and XL [17] to en-able web service failover. Their dependence on hardwired service references, however, does not capture the volatility

of web service architectures (WS1) and it disables dynamic service discovery. Also, these languages lack support for defining constraints (WS3) and selection policies (WS4), and for enclosing interactions into sessions (WS5).

Aspect-Oriented Programmming. ASIL [21] and AO4BPEL [10] are AOP-based web service programming languages. These languages offer basic support for late binding and failover by introducing a number of reusable aspects, but they still require considerable effort to imple-ment QoS constraining (WS3) and optimal service selec-tion (WS4), thus decreasing the level of abstraction (OO3). FuseJ [14] introduces similar aspects, calledconnectors, for wiring applications to remote web services, but forces ser-vice providers to be FuseJ-aware, thus violatingWS6.

7.2. Markup Languages

ActiveXML [4, 31], BPEL [5], and BPELJ [6] are typical XML-based languages for programming web service inter-actions, but they provide only limited support fordynamic web service binding (WS1). GPSL [12] and [13] solve this problem by introducingparametrization. Parametrization enables developers to invoke operations on a service se-lected fromthe result of a query. These result sets resemble our service pools, but they lack support fortransparentweb service failover (WS2). ServiceJ offers a more expressive, typed query language withwhere andorderby opera-tions and provides a fully transparent failover mechanism.

The Web Services Management Layer (WSML) [34] and DySOA [19] act as mediators between clients and web ser-vice providers. Both systems enable serser-vice failover by relying on late binding and provide a basic means for en-forcing QoS constraints. ServiceJ integrates similar fea-tures with Java by using the runtime system as a media-tor between the client and the web service. One limitation of WSML and DySOA is their lack of asessionconstruct,

whereas ServiceJ offers basic support for ad hoc web ser-vice sessions.

8. Conclusion and Future Work

We have pointed out a number of problems with Java in the context of programming web service interactions, leading to a list of objectives for better integrating web services and object-oriented programming. ServiceJ real-izes these goals by extending the Java type system with type qualifiersfor non-deterministic (pool) and determin-istic, preference-driven (sequence) service selection. The level of abstraction is raised by introducingdeclarative op-erationsfor specifying membership conditions (where) and quality attributes (orderby). Moreover, ServiceJ offers ba-sic support for ad hoc web service transactions by allow-ing developers to group related web service interactions into session blocks. We have outlined the formalization and the implementation of ServiceJ, and we have compared the lan-guage with a number of object-oriented and XML-based programming languages.

There are two important future directions. First, we will increase the expressiveness of the service selection mech-anism (orderby) by integrating linear programming con-cepts. Second, we will enrich our session blocks with support for intra-organizational service architectures where clients and services are controlled by the same organization, thus allowing for more robust transaction mechanisms.

References

[1] A. Baratloo, E. Chung, et. al. Filterfresh: Hot Replication of Java RMI Server Objects. InCOOTS98, 1998.

[2] L. Baduel, F. Baude, and D. Caromel. Efficient, Flexible, and Typed Group Communications in Java. In The Java Grande and ISCOPE 2002 Joint Conference, 2002. [3] B. Ban. JavaGroups. Group Communication Patterns in

Java. Technical Report, Cornell University. 1998.

[4] O. Benjelloun. ActiveXML: a Data Centric Perspective on Web services. PhD Thesis, Paris XI University, 2004. [5] BPEL4WS Spec.http://www.ibm.com/developerworks. [6] BPELJ Spec.http://www.ibm.com/developerworks. [7] C. Brabrand, A. Moller, and M. I. Schwartzbach. The bigwig

project.ACM Trans. Inter. Tech., 2(2):79–114, 2002. [8] L. Cardelli and R. Davies. Service Combinators for Web

Computing.In: Trans. on Softw. Engineering, 25(3), 1999. [9] W. Cazzola. mChaRM: Reflective Middleware with a Global

View of Communications. IEEE DS On-Line, 3(2), 2002. [10] A. Charfi and M. Mezini. Aspect-Oriented Web Service

Composition with AO4BPEL. InECOWS04, 2004. [11] A. S. Christensen, A. Moller, and M. I. Schwartzbach.

Ex-tending Java for high-level Web Service Construction.ACM Trans. on Programing Languages and Systems, 25(6), 2003. [12] D. Cooney, et al. Programming and Compiling Web Services with GPSL. InProceedings of the 3rd International Confer-ence on Service Oriented Computing. ICSOC05, 2005. [13] D. Karastoyanova, et al. An Approach to Parametrizing Web

Service Flows. InProceedings of the 3rd International Con-ference on Service Oriented Computing. ICSOC05, 2005.

[14] D. Suvee et al. Evaluating FuseJ as a Web Service Com-position Language. InProceedings of the Third European Conference on Web Services. ECOWS05, 2005.

[15] De Labey, S., M. van Dooren, and E. Steegmans. ServiceJ. Service-oriented Programming in Java. Technical Report http://www.cs.kuleuven.be/publicaties/reports/CW/2006/. [16] F. Pereira et al. Tactics for Remote Method Invocation.

Jour-nal of Universal Computer Science, 10(7):824–842, 2004. [17] D. Florescu, A. Gruenhagen, and D. Kossmann. XL: A

Plat-form for Web Services. InProceedings of the First Biennial Conference on Innovative Data Systems Research, 2003. [18] M. Hadim and et al. Service Combinators for Web

Comput-ing in Distributed Oz. InProc. Intl. Conference on Parallel and Distributed Processing Techniques and Appl., 2000. [19] I. Bosloper et. al. Creating Self-Adaptive Service Systems

with Dysoa. InProceedings of the Third European Confer-ence on Web Services, ECOWS05, 2005.

[20] A. Igarashi and et al. Featherweight Java: A Minimal Core Calculus for Java and GJ. InOOPSLA99, volume 34(10), pages 132–146, 1999.

[21] C. D. Induruwana. Using an Aspect Oriented Layer in SOA for EAI. InICSOC PhD Symposium, 2005.

[22] Java EE 5.0 Spec.http://www.jcp.org/en/jsr/detail?id=244. [23] JAX-WS 2.0 Spec.http://www.jcp.org/en/jsr/detail?id=224. [24] Jini Architecture Specification.http://www.jini.org. [25] T. Kistler and H. Marais. WebL - A Programming Language

for the Web. In7th Intl. Conference on the WWW, 1998. [26] M. Duflter et al. Web Service Invocation Framework

http://www.research.ibm.com/people/b/bth/OOWS2001. [27] M. van Dooren, K. Vanderkimpen, and S. De Labey. The

JNome and Chameleon Metamodels for Object Oriented Programming, http://www.cs.kuleuven.be/˜marko. 2007. [28] J. Maassen, T. Kielmann, and H. Bal. GMI: Flexible and

Ef-ficient Group Method Invocation for Parallel Programming. In6th Workshop on Languages, Compilers, and Run-time Systems for Scalable Computers, 2002.

[29] A. Montresor, R. Davoli, and O. Babaoglu. Group-Enhanced Remote Method Invocations. In University of Bologna, Technical Report UBLCS-99-05, 1999.

[30] M. Papazoglou. SOC: Concepts, Characteristics and Direc-tions. InProceedings of the 4th International Conference on Web Information Systems Engineering, 2003.

[31] S. Benbernou, X. He, and M. Hacid. Implicit Service Calls in ActiveXML Through OWL-S. In ICSOC05– 3rd Int. Conference on Service Oriented Computing, 2005. [32] S. De Labey and E. Steegmans. A Type System Extension

for Middleware Interactions. In 1st WS on Middleware-Application Interaction, 2007.

[33] S. De Labey, M. van Dooren, and E. Steegmans. Bridging the Gap Between Object-Oriented Programming and Ser-vice Oriented Computing. InProceedings of the 1st WS on Foundations for Service Oriented Architecture, 2007. [34] B. Verheecke and et al. AOP for Dynamic Configuration and

Management of Web Services.In: International Journal on Web Services Research, 1(3):25–41, 2004.

[35] W. Cazzola et. al. Enhancing Java to Support Object Groups. In3rd Conference on Recent Object-Oriented Trends, 2002.