Making Service-Oriented Java Applications Interoperable

Making Service-Oriented Java ApplicationsInteroperable without Compromising

Transparency

Sven De Labey and Eric Steegmans

University of Leuven, Dept of Computer Science200A Celestijnenlaan, B-3000 Leuven, Belgium

{svendl,eric}@cs.kuleuven.be

Abstract. Object-oriented programming languages lack high-level sup-port for platform-independent service interactions. In Java, for instance,the burden of guaranteeing sustainable interoperability is put entirely onthe programmer. Java Remote Method Invocation requires its invocationtargets to be remote Java objects, so Web Services and other targetscan never be invoked without verbose interactions with specialized li-brary classes. This lack of transparency forces programmers to considerheterogeneity problems over and over again, even though interoperabil-ity is ideally a middleware responsibility. Moreover, by mixing businesslogic with non-functional concerns, the source code is obfuscated, whichdecreases code comprehensibility and maintainability.

In this paper, we show that interoperability in Java applications canbe achieved without compromising transparency. We describe a Java ex-tension and focus on how this language enables a precompiler to trans-parently inject the boilerplate code that realizes interoperable service in-teractions. Deferring interoperability provisioning to such a precompilerallows programmers to focus on the implementation of the business logicwithout being distracted by heterogeneity issues occurring in the servicearchitecture in which their application will eventually be deployed.

1 IntroductionWeb Services expose their functionality using standarized WSDL [1] documentsand they communicate over an agreed upon protocol (SOAP [2] over HTTP).By advertising their interfaces using WSDL, they realize platform interoperabil-ity as every programming language can define WSDL bindings that translatetheir method calls back and forth to WSDL. Java service clients, for instance,can execute such translations by means of Apache Axis [3], a set of specializedlibrary classes for web service interactions. Using this API, programmers areable to overcome the problems of platform heterogeneity by benefitting from theinteroperability that web service interactions provide.

While they may effectively hide platform heterogeneity, Web Services cannotcope with protocol diversity : their hardwired reliance on SOAP is thus a limitingfactor for true enterprise application interoperability. Various components exe-cuting in a service architecture may publish services that talk other protocols,

2 Sven De Labey and Eric Steegmans

and these services cannot be contacted using basic APIs such as Apache Axis [3].Currently, the programmer is forced to decide on the communication protocol atimplementation time, leading to interoperability problems in architectures whereservices may decide to switch to other protocols at runtime. This drawbacks canbe avoided by relying on another framework: the Web Service Invocation Frame-work [4]. WSIF allows programmers to invoke services in a protocol-independentway by deferring protocol decisions to dynamic protocol providers. This furtherincreases the interoperability of the overall enterprise system.

It is clear that such frameworks provide increased interoperability at thecost of decreased transparency. Programmers need to learn APIs such as Axisor WSIF, while essentially, interoperability has little or nothing to do with anapplication’s business logic. It is a middleware responsibility, so it should behidden for the implementors of the business logic. Nonetheless, verbose andtechnical middleware interactions continue to appear in the source code, andthe failure to separate functional concerns from non-functional code leads topoor code reusability and portability, as well as increased maintenance cycles.

In this paper, we investigate how the lack of transparency in object-orientedprogramming languages can be cured, taking Java as an example. We begin bypointing out some major transparency issues in Axis and WSIF (Section 2).Then, we provide a quick overview of ServiceJ, our language with specializedconcepts for programming service interactions (Section 3) and we show howthe ServiceJ precompiler is able to inject interoperability-specific technicalitiesduring the transformation from ServiceJ to Java (Section 4). Section 5 providesan example of such an interoperable client-service interaction. Sections 6 and 7present related work and some final thoughts.

2 The Transparency–Interoperability Tradeoff in Java

In this section, we show how platform-independent, protocol-independent serviceinteractions can be programmed in Java. We survey the functionality found inAxis to invoke web services (platform independence), and we review the WebService Invocation Framework (platform and protocol independence).

Web Service Interactions with Axis. Listing 1.1 contains a service invo-cation using Axis. An echoString operation is invoked and the result is printedon screen. Lines 7–8 contain the business logic; the remaining lines comprisemiddleware interactions. This example shows that programmers are made re-sponsible for the creation of a Service object (line 3) representing the target,and a Call instance (line 4) representing the invocation. They must also specifythe target address (line 5) and the name of the operation (line 6).

Evaluation. Driven by Axis, Java clients are no longer limited to invoking otherJava applications; they can now cooperate with any application that exposes itsfunctionality as a web service. This gain in interoperability, however, comes witha large cost. The functional code in Listing 1.1 contains verbose, non-functionalinteractions with the Axis platform, leading to a number of transparency prob-lems:

Making Java applications interoperable 3

1 try {

2 String endpointURL = "http://ws.apache.org:5049/axis/services/echo";

3 Service service = new Service();

4 Call call = (Call)service.createCall();

5 call.setTargetEndpointAddress(new java.net.URL(endpointURL));

6 call.setOperationName(new QName("http://url.org/", "echoString"));

7 String result = (String) call.invoke(new Object[]{"Hello!"});

8 System.out.println(result);

9 }

10 catch (Exception e) {...}

Listing 1.1. Invoking web services using Apache Axis

– Reified service calls. Contrary to method invocations via local Java objectreferences, a web service call must be built from the ground up based onreification. The web service itself is reified as a Service instance, whereasthe service call is represented by a Call object, of which the target and theoperation must be set by the programmer. Consequently, seven lines of codeare needed whereas local java applications would need only one or two.

– Endpoint URL. The business transaction executed here is independent of thelocation of the service, but the service endpoint URL necessarily appears inthe source code, as it is needed to specify the endpoint address of the Callobject. Such hardwired URLs not only jeopardize transparency, they alsobreak the client if that remote service is migrated or deleted.

But there is more to be sacrificed before programmers can integrate the benefitsof interoperability in their applications. In Listing 1.1, it is easy to see that nocompiler can guarantee that echoString is an existing method, or that it acceptsexactly one String as a formal argument. This is in strong contrast with localmethod invocations that can easily be checked for syntax violations and typingerrors. Another problem, already mentioned above, is that SOAP, the underly-ing communication protocol, is hardwired. This decreases interoperability, sinceservices not talking SOAP can never be invoked. Even worse, SOAP-speakingservices dynamically switching to another protocol (e.g. REST) are bound tobreak clients that statically depend on SOAP as the messaging protocol.

In summary, interoperability in Axis comes with a high cost: it compromisestransparency, disables important compiler guarantees, and hardwires protocoldecisions at compile-time. Another framework, WSIF, tries to overcome theseproblems, and it is discussed next.

Service Interactions with WSIF. Compared with Axis, the Web ServiceInvocation Framework improves interoperability in two ways. First, it allowsprogrammers to invoke any service that exposes its functionality in a WSDLdocument, so services not following the web services paradigm may be invokedas well. Second, WSIF determines the underlying protocol dynamically, so it


can speak other protocols than SOAP, and it can react on protocol changes byswitching between protocols at runtime.

Listing 1.2 illustrates how client-service interactions are programmed us-ing WSIF. Both StockQuote and QuoteLog are WSIF stubs, acquired using aWSDL2Java compiler [3]. The code first requests information from a StockQuoteservice and then sends the result to a QuoteLog service.

1 try {

2 // --1-- Create a service factory

3 WSIFServiceFactory factory = WSIFServiceFactory.newInstance();

4

5 // --2a-- Parse WSDL of Stock Quote Service

6 WSIFService quoteService = factory.getService(

7 "/example/SQuote.wsdl", // WSDL location

8 null, // Service Namespace

9 null, // Service Name

10 "http://...url1...", // PortType Namespace

11 "StockQuotePortType" // PortType Name

12 );

13 // --2b-- Parse WSDL of Stock Quote Logger

14 WSIFService logService = factory.getService(

15 "/example/QLog.wsdl", // WSDL location

16 null, // Service Namespace

17 null, // Service Name

18 "http://...url2...", // PortType

19 "QuoteLogPortType" // PortType Name

20 );

21

22 // --3-- Get the stubs

23 StockQuote qStub = (StockQuote)quoteService.getStub(StockQuote.class);

24 QuoteLog logStub = (QuoteLog)logService.getStub(QuoteLog.class);

25

26 // --4-- Interact with the services

27 float quote = qStub.getQuote(aQuote);

28 logStub.logQuote(aQuote, quote);

29 }

30 catch (WSIFException we) { ... }

31 catch (RemoteException re) { ... }

Listing 1.2. Invoking web services using WSIF

Evaluation. WSIF further improves interoperability of Java service clients, butthis gain is again overshadowed by a tremendous increase in lines of code, whichfirmly decreases transparency. Developers need to create a service factory (line3), they need to provide the WSDL location of the service, combined with othertechnical data (lines 6–20). Then, they must ask for stubs, and convert thesestubs to the right type (lines 23–24). And when the service client can finallyinteract with the service reference, programmers must hope that the service


still provides the same QoS (service volatility problems are ignored by WSIF)and that it is still reachable (WSIF does not handle distribution problems). Inaddition, robustness problems remain unsolved: a ClassCastException occurswhen the stub is cast to an incompatible type on lines 23–24.

Towards Transparent Interoperability in Java. In this paper, the main re-search question is whether we can make Java service clients interoperable withoutsacrificing transparency and compile-time guarantees. The next section presentsServiceJ, our Java language extension that introduces declarative language con-structs for programming robust client-service interactions. Section 4, shows howthe transformation of this language extension to regular Java code realizes theinjection of middleware interactions that foster sustainable interoperability.

3 ServiceJ. A Java Dialect for Client-Service Interactions

ServiceJ is a Java extension that introduces specialized language concepts forclient-service interactions in service-oriented architectures. The main objectiveof this extension is to provide programmers with a higher level of abstractionby shielding them from the technical, often middleware-dependent, details ofservice-oriented computing. In this section, we provide a conceptual overview ofServiceJ, and we refer to [5] for the technical details of the extension.

1 try {

2 pool StockQuote quoteService;

3 QuoteInfo info = quoteService.getQuoteInformation(aQuote);

4

5 sequence Printer printer where printer.getPagesPerMinute()>=15

6 orderby printer.getQueue().getSize();

7 printer.print(info);

8 }

9 catch (RemoteException re){...}

Listing 1.3. Invoking services using ServiceJ language constructs

Type Qualifiers. The objective of type qualifiers is to distinguish betweenvariables pointing to local objects and variables containing volatile service ref-erences. ServiceJ decorates the latter with the pool qualifier. This qualifier trig-gers the ServiceJ-to-Java transformer to inject middleware interactions for (1)non-deterministic service retrieval, (2) dynamic service binding, and (3) fault-tolerant service invocation. By relying on code injection, we allow programmersto focus on the business logic, while the injected middleware interactions ensurethe robustness of service invocations. ServiceJ also introduces a second quali-fier, sequence, to be used when deterministic service selection is required instead of the default non-deterministic selection algorithm (see [5] for a completediscussion on ServiceJ’s type qualifier hierarchy).

Declarative Operations. Increased transparency does not imply that pro-grammers lose control over service interactions: ServiceJ introduces declarativeoperations that allow programmers to fine-tune service selection at a high levelof abstraction. Listing 1.3 illustrates how ServiceJ’s where operation is used to


impose a Quality of Service constraint: the middleware may only inject Printerservices that print at least 15 pages per minute (line 5). A second operation,orderby forces the middleware to take into account user preferences [5]. In list-ing 1.3, for instance, the middleware is required to bind the printer variable tothe Printer service with the shortest job queue (line 6).

In summary, type qualifiers and declarative operations specify what must be donerather than how it must be done. They provide important information to themiddleware, but they don’t jeopardize transparency nor do they compromisecompile-time guarantees on the correctness of method invocations. The nextsection shows how middleware instructions for increasing interoperability areinjected driven by ServiceJ’s new language constructs.

Fig. 1. Overview of the ServiceJ-to-Java transformation process

4 Compiling ServiceJ to Java. Injecting Interoperability

ServiceJ source code is transformed to Java before it is compiled by the Javacompiler. The advantage of this transformation is that ServiceJ applicationsbecome interoperable with existing Java applications. Libraries and APIs canthus be reused without requiring source code modification. In this section, wefocus on this transformation, which comprises two phases: (1) the construction ofa metamodel representation of the ServiceJ application, as described in Section4.1, and (2) the transformation of that metamodel instance to Java code, asdescribed in Section 4.2. An overview of the ServiceJ-to-Java transformationprocess is shown in Figure 1. This compilation process is entirely transparent forthe programmers; they can treat it like a black box process consuming ServiceJsource code (on the left) and producing Java class files (on the right).

4.1 Representing ServiceJ applications in a Metamodel

The first step of the transformation process is the construction of a basic ab-stract syntax tree (AST) representing a ServiceJ program. This AST is built bythe ServiceJ Lexer and Parser. Both tools were built by feeding the languagedefinition of ServiceJ to ANTLR [6]. Basic ASTs represent ServiceJ source pro-grams, but they lack important semantic information about the program. Thisis because ASTs consist of semantically poor nodes, while we need to operate onclasses, methods, and other semantically rich language concepts. Without theappropriate semantic information, it is very hard to decide whether or not to


decorate source code elements with middleware interactions for increasing theinteroperability of the resulting Java program. Therefore, we include anotherpreprocessing step before executing the ServiceJ-to-Java transformation.

Fig. 2. ServiceJ metamodel instances store semantic information of ServiceJ programs

Building a Metamodel from an AST. Once the AST of the ServiceJ programis built by the parser, it is transformed into an instance of the ServiceJ meta-model. This metamodel contains classes representing programming languagesartifacts, such as variables, classes, method invocations, etcetera. Thus, the tran-sition of an AST to a metamodel instance injects semantically rich informationthat is required by the ServiceJ-to-Java transformer.

A simplified example of a metamodel part is shown in Figure 2. The poolvariable is modeled by two metamodel classes: (1) a MemberVariable and (2)a class PoolQualifier. The method invocation quote.getStockQuote("IBM")is created as an instance of MethodInvocation connected to an instance ofInvocationTarget. The latter is linked to the declaration of the quote vari-able, represented by MemberVariable. The major advantage of having this se-mantic link is that it becomes straightforward to check whether or not the op-eration is invoked on a pool variable; if the InvocationTarget is linked to aMemberVariable with a Pool instance attached to it, then the ServiceJ-to-Javatransformer must inject WSIF interactions for realizing transparent interoper-ability; if the MemberVariable is not linked to a PoolQualifier instance, thenthe method invocation is executed on a local object reference, so WSIF injectionmust be avoided.

4.2 Transforming ServiceJ Metamodel Instances to Java & WSIF

The second step of the ServiceJ compilation process is the transformation ofthe ServiceJ metamodel instance to a Java metamodel instance. This finishesthe compilation process because a Java metamodel instance can be written outas Java code, which is eventually fed to the Java compiler so as to obtain therelevant .class files. The transformation is depicted in Figure 3, which presentsa more detailed version of the process depicted on the right part of Figure 1.

Transformation Inputs. Figure 3 shows that the ServiceJ transformer re-quires two inputs. The first one is the ServiceJ metamodel instance À, obtainedafter semantic information was injected in the abstract syntax tree representingthe service client (see Section 4.1). The second input comprises a list of precom-piled stubs Á. For each pool variable of type T, the ServiceJ transformer requires


Fig. 3. Metamodel instance transformation and Java code injection

a stub of type T. These stubs are used to typecheck the original ServiceJ code,as such allowing the compiler to provide static guarantees on the correctnessof the service client. Other information, such as the location, the platform andthe protocol are ignored by the ServiceJ transformer because hardwiring thatinformation dramatically reduces the interoperability of the service client be-ing compiled. Instead, the transformer injects instructions that deal with thesechallenges at runtime, as discussed next.

Code Transformation. The ServiceJ transformer Â starts by iterating overthe ServiceJ metamodel instance, transforming each program element to its cor-responding Java metamodel element. The transformation from ServiceJ methodinvocations to Java method invocations represents the major challenge duringthis process. Indeed, ServiceJ uses different transformation strategies based onthe type qualifier (pool, sequence, or nothing) that was used to declare thevariable on which the method is invoked. Method invocations on regular fieldsare left unmodified during the transformation whereas interactions with poolor sequence fields require the ServiceJ compiler to inject code that handles (1)interoperability challenges and (2) middleware-specific tasks. Both are depictedas step Ã in Figure 3, and they are discussed below.

1. Interoperability Provisioning.– Service Discovery. Code is injected for dynamically discovering service

candidates before starting the interaction. This increases interoperabilitywhen compared with WSIF, which relies on service endpoints of whichthe location was hardwired during the implementation phase.

– Service Selection. Programmers may have constrained the candidate setof services to those services that exhibit special characteristics using awhere or orderby operation (see Section 3). The ServiceJ transformerinjects code for interacting with these services using a dynamically se-lected protocol so as to obtain information about their QoS level.

– Service Binding. The ServiceJ transformer injects instructions for dy-namically binding a pool variable to a service after the service selectionphase. To increase interoperability, the ServiceJ transformer also injects


instructions for dynamically negotiating on the protocol that will be usedwhen invoking operations on the selected service. It is important to notethat service binding is done just-in-time. This is because service qualitylevels may be subject to continuous change, so it is important to use themost recent data when selecting and binding a service.

– Service Invocation. After injecting instructions for selecting and bindingthe service, the ServiceJ transformer injects instructions for dealing withdynamic protocol changes. If compatibility problems or other protocolerrors arise during a client-service interaction, then these instructionswill rollback the conversation and negotiate dynamically on the newprotocol before restarting the interaction.

2. Other Middleware Tasks.– Service Fail-over. Given the distributed nature of services, every client-

service interaction may fail due to reachability or availability problems.The ServiceJ transformer therefore decorates every service interactionwith code for service fail-over. When confronted with remote problems,the injected instructions search for another compatible service from theconstrained pool of candidate services and restart negotiations on theprotocol that will be used during the interaction with that new service.Then, the operation is transparently reinvoked on that new endpoint.

– Service Transactions. ServiceJ introduces additional language conceptsfor demarcating service sessions, which comprise multiple interactionsbetween a client and a service so as to complete a complex businesstransaction (see [5] for more information). Instructions are injected so asto successfully support such transactional behaviour.

– Service Volatility handling. Newer services may be added to the architec-ture at runtime, and these are overlooked by WSIF’s hardwired servicereferences. The ServiceJ transformer, on the other hand, injects instruc-tions for dynamic service discovery and binding, and is therefore able toadequately handle volatility issues.

Code Output and Compilation. The transformation of the ServiceJ meta-model triggers the injection of new Java instructions, as discussed above. Thisprocess incrementally leads to the construction of a Java metamodel instance Äin which various instructions for improving interoperability are inserted. Thus,this newly built metamodel represents a Java application of which the functional-ity is equivalent to the original ServiceJ application. To complete the compilationprocess, a codewriter [7] is used to turn the metamodel instance into a set ofJava source files Å, which are eventually compiled with the Java compiler toJava bytecode. This concludes the process that was shown in Figure 3.

5 Example

In this section, we illustrate how responsibilities are divided between the devel-opers of a service client and the ServiceJ compiler. The top part of Figure 4shows how a service interaction for printing a file is implemented. A variable


Fig. 4. ServiceJ & WSIF cooperate transparently to enable interoperable interactions

of type Printer is decorated with a type qualifier (sequence), denoting thata non-deterministic service selection and injection strategy is to be followed atruntime. An additional constraint is provided using the declarative where clause,stating that the printer must support color printing with an output of at least 20pages per minute. Multiple printers may satisfy these constraints, so the file mustbe printed on the printer with the shortest job queue. The non-deterministic se-lection strategy enforced by the sequence qualifier will use this preference tosort the Printer services that remain after applying the constraint.

The programmer can easily implement this service interaction by using thenew language concepts that ServiceJ provides. They are no longer responsiblefor realizing service interoperability, nor are they forced to insert instructions forservice selection, service binding, and service failover. These tasks are now trans-parently handled by feeding the source file of the service client to the ServiceJ-to-Java transformer. The latter injects the appropriate middleware interactions,and compiles the service client to Java bytecode.


ServiceJ Runtime Behaviour. Under the hood, ServiceJ and WSIF cooper-ate tightly to enable interoperable service invocation. Before the print operationcan be invoked on a remote service, the ServiceJ middleware has to search forservices that satisfy all the constraints that were imposed when the pool fieldwas declared. It does so by contacting a ServiceJ registry, requesting the list ofURLs that publish the WSDL definitions of those services that conform to thestatic service type (step 1 in Figure 4). ServiceJ passes these URLs to the WSIFmiddleware and requests a protocol-independent stub for contacting the services(steps 2–4). All these stubs are returned to the ServiceJ middleware layer, wherethey are added to a service pool (step 5). Next, the pool must be constrained.Each service is contacted using its own specific protocol in order to check whetherit satisfies the QoS requirements of the service client. ServiceJ transparently re-lies on WSIF and its dynamic providers architecture [4] to communicate withthese services. Given this information, the ServiceJ middleware constrains theservice pool, retaining only those services that comply with the constraint asrepresented by the where operation (step 6). Finally, the first service from theresulting service sequence (S1 in Figure 4) is injected into the printer variable.The print operation can now be invoked. Assume this invocation fails becauseS1 has become unreachable (steps 8a–8b). The middleware then automaticallytries to invoke the operation on the second-best service from the sequence, S4,which successfully handles the request (steps 9a–9b).

6 Related WorkDue to space restrictions, we cannot provide an extensive discussion of relatedwork. A more complete discussion of how our language extension relates to otherframeworks and runtime platforms can be found in [5].

One important related Java technology is Jini [8], which supports late bindingand dynamic discovery of services registered in a central services registry. Similarto ServiceJ, developers express service constraints, although preference-drivenservice optimisation is not supported. The drawback of Jini, however, is thatit lacks provisions for ensuring interoperability during service interactions andforces developers to write a considerable amount of boilerplate code for servicelookup, service selection and fault tolerance, thus further reducing transparency.

ProActive [9] and JavaGroups [10] are Java-based languages and librariesdeveloped for supporting service failover and multicast service communication.They turn out to have serious interoperability problems, since they assume re-mote services to be Java-compliant, and each framework relies on a hardwiredprotocol. They also require the service provider to install additional software,thus further jeopardizing interoperability in cross-enterprise service architec-tures. Similar liabilities were detected in Java RMI extensions that support faulttolerance and constrained method invocation, such as mChaRM [11], RMI Tac-tics [12] and [13].

ServiceJ is not the first extension that introduces language concepts for ser-vice programming. Similar constructs were introduced by Cardelli et al. in [14].They introduce service combinators such as the sequential execution operator(denoted “S1?S2”) for stating that S2 must be contacted if S1 is unreachable.


Service combinators are used in other object-oriented languages such as WebOz[15] and XL [16] to enable web service failover. The use of such combinators islimited in volatile service environments, however, because they rely on hardwiredservice references (S1 and S2). Additionally, by relying on hardwired communi-cation protocols, they break interoperability in environments where services canchange their protocols.

7 ConclusionCurrent Java frameworks and API’s increase interoperability at the cost of de-creased transparency. They put the burden of guaranteeing sustainable interop-erability on the programmer, even though interoperability is essentially a mid-dleware responsibility that has little or nothing to do with the business logic.

To solve these problems, ServiceJ introduces special language concepts thatallow programmers to focus on the business logic, at the same time allowingthem to fine-tune service selection in a declarative, type-safe way. We have shownhow the ServiceJ compiler translates ServiceJ to Java, a process during whichlocation- and protocol-independent service interactions cooperate with ServiceJ’sservice selection algorithms so as to dynamically bind the optimal service to thosefields depending on external services.

References

1. WSDL Specification v1.1: www.w3.org/TR/wsdl. (2001)2. SOAP Specification: http://www.w3.org/TR/soap/3. Apache Axis: http://ws.apache.org/axis/ (2004)4. Duftler, M., Mukhi, N., Slominski, A., Weerawarana, S.: Web Service Invocation

Framework (WSIF), http://www.research.ibm.com/. (2001)5. De Labey, S. et al.: ServiceJ. A Java Extension for Programming Web Service

Interactions. In: International Conference on Web Services. ICWS07. (2007)6. Ashley, A.J.: ANTLR: http://supportweb.cs.bham.ac.uk/documentation/tutorials/7. M. van Dooren, K. Vanderkimpen, and S. De Labey: The Jnome and Chameleon

Metamodels for OOP, http://www.cs.kuleuven.be/˜marko. (2007)8. Jini Architecture Specification: http://www.jini.org9. Baduel, L., Baude, F., Caromel, D.: Efficient, Flexible, and Typed Group Com-

munications in Java. In: The Java Grande Conference. (2002)10. Ban, B.: JavaGroups. Group Communication Patterns in Java. Technical Report,

Cornell University. (1998)11. Cazzola, W.: mChaRM: Reflective Middleware with a Global View of Communi-

cations. IEEE DS On-Line 3(2) (2002)12. F. Pereira et al.: Tactics for Remote Method Invocation. Journal of Universal

Computer Science 10(7) (2004) 824–84213. W. Cazzola et. al.: Enhancing Java to Support Object Groups. In: 3rd Conference

on Recent Object-Oriented Trends. (2002)14. Cardelli, L., Davies, R.: Service Combinators for Web Computing. In: Trans. on

Softw. Engineering 25(3) (1999)15. Hadim, M., et al.: Service Combinators for Web Computing in Distributed Oz. In:

Conference on Parallel and Distributed Processing Techniques and Appl. (2000)16. Florescu, D., Gruenhagen, A., Kossmann, D.: XL: A Platform for Web Services. In:

Proceedings of the First Conference on Innovative Data Systems Research. (2003)

Documents

Making Service-Oriented Java Applications Interoperable