Integrating ServiceJ with Interoperable Web Service Invocation - Lirias

Integrating ServiceJ with Interoperable WebService Invocation

Sven De Labey and Eric Steegmans

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

{svendl,eric}@cs.kuleuven.be

Abstract. The Web Services paradigm is promising because it excels inuniting systems that were previously thought to be incompatible. Hence,a growing number of applications are built as interconnected, cooperatingservices, where the business logic of each service is typically implementedin an object-oriented programming language.

But current object-oriented programming languages do not integratewell with the Web Services paradigm. Various frameworks were proposedto increase transparency, but these APIs fail to provide appropriate ab-stractions for guiding service selection and for handling service failures.Hence, they make the programmer responsible for dealing with infras-tructural technicalities, resulting in ad-hoc solutions that comprise error-prone and obfuscated code.

In this paper, we evaluate the Web Service Invocation Framework(WSIF), a popular API for writing web service clients in Java. We showhow the weaknesses of WSIF can be solved by integrating it with Ser-viceJ, our Java extension that introduces language features for interact-ing with remote services. By directly integrating support for web servicesin object-oriented programming languages, we allow programmers to fo-cus on the implementation of the business logic, rather than on techni-cal challenges such as locating services, installing service communicationprotocols, and detecting service failures.

1 Introduction

Enterprise systems rarely comprise a homogeneous combination of applicationservices that were built for the same platform and that communicate via a stan-dardized protocol. Instead, a service architecture is a network of interconnectedservices running on various platforms such as .Net [1] or the Java EnterpriseEdition [2]. Platform and protocol heterogeneity are therefore increasingly be-coming an issue. This heterogeneity does not only occur during cross-enterpriseoperations, but also in intra-organizational enterprise systems that arose as theresult of repeated mergers and acquisitions, where service architectures of ac-quired companies, like pieces of a puzzle, are combined so as to create a single,unified enterprise SOA.

Next to platform heterogeneity and protocol diversity, the distributed andvolatile nature of services creates even more challenges for the developers of

2 Sven De Labey and Eric Steegmans

service applications. Network problems or unanticipated server outages, on onehand, may cause the service provider to become unreachable. Incompatible ser-vice updates and service migration, on the other hand, may break clients whenthey statically depend on the old version of that updated service.

Currently, object-oriented programming languages such as Java are poorly in-tegrated with the paradigm of Service-Oriented Computing. Java fails to provideappropriate support for dealing with the challenges that arise when interactingwith services. This lack of support forces programmers to devise their own solu-tions for discovering and selecting services, handling protocol diversity, creatinginput and output messages, and anticipating problems that relate to the dis-tributed and volatile nature of a remote service endpoint. Often, programmersmust invoke operations on port types in the same way read/write operations hadto be executed on sockets years ago. The resulting code entanglement decreasesthe comprehensibility of the source code, as such prolonging maintenance cyclesas well as increasing the odds for introducing bugs in either the business logicor in the code that deals with infrastructural SOA-related technicalities.

In this paper, we build a programming model that integrates object-orientedprogramming languages and Web Service programming. We start from the WebService Invocation Framework (WSIF) to show how Java can be used to interactwith web services. We discuss how this framework frees the programmer fromhaving to deal with protocol-specific and platform-dependent service invocations.Then, we show how the Web Service Invocation Framework can be integratedinto ServiceJ, our Java dialect that provides specialized concepts for interactingwith services at a higher level of abstraction.

This paper is structured as follows. Section 2 enumerates the challenges ofService-Oriented Computing that are relevant for our integration project. Closelyrelated to these challenges is a list of design goals, discussed in Section 3. Sec-tion 4 then describes the Web Service Invocation Framework and points out itsstrengths and weaknesses according to the aforementioned design goals. Section 5shows how these weaknesses can be cured by integrating the WSIF project intoServiceJ, our Java dialect. Section 6 shows how ServiceJ is compiled to Java.Section 7 illustrates how ServiceJ and WSIF join forces in order to increase thelevel of abstraction for programmers. Finally, Section 8 describes related workand Section 9 concludes.

2 The Challenges of Service Oriented Computing

Every new programming paradigm brings its own technical challenges. The WebServices paradigm is not different from this point of view, and as this paperproposes abstractions for interacting with remote services, we consider only thosechallenges that are relevant for successfully interacting with a service endpointor a service provider :

– Distributed. Services are modular components that typically live in dis-tributed environments. This is particularly true for web services, as this

Integrating Web Services and Object-Oriented Programming 3

paradigm was devised for executing cross-enterprise operations. This createsa major challenge for the developers of service clients. Such a client appli-cation can never take for granted the availability of the remote service sincevarious problems can occur that are not necessarily under the control ofthe client or the service provider. Examples of such problems include linkfailures, network partitioning and server downtime.

– Volatile. Decentralized management of an SOA which is maintained by co-operating business partners is challenging because such architectures are sub-ject to continuous change. First, incompatible service upgrades break clientswhenever a service provider decides to upgrade one of its services in a waythat is incompatible with the older version. Second, service migration mayoccur when the service provider decides to revise his part of the servicearchitecture, for instance, to improve load balancing. This requires serviceclients to dynamically discover the new location of the service endpoint. Yetanother consequence of a service’s volatility is service deletion, which oc-curs, for instance, when an enterprise discontinues a product branch. Thus,volatile services challenge their clients to react on dynamic changes to theSOA, which often comprises a search for alternative services.

– Competing Landscape. The main benefit of service-oriented computingis that it creates a market where competing providers offer similar servicesat different quality levels. But this is also an important challenge, because itcreates a need for fine-tuned service selection at the service client. That is,clients must be able to dynamically select the service that best approximatesa number of functional and non-functional requirements. Quality levels of ser-vices are as volatile as their location and compatibilty, so a related challengeis to make a service client dynamically react to changing quality levels.

– Platform Heterogeneity. Full interoperability requires all technical,platform-dependent issues to be hidden for all stakeholders. Web Servicesare an example of a successful attempt to overcome heterogeneity by relyingon vendor-neutral XML documents (WSDL [3]) and protocols (SOAP [4]).Service-based technologies such as Jini [5] and OSGi [6], on the other hand,still rely heavily on vendor-specific protocols and platforms. This compro-mises the degree of interoperability of an enterprise system: those compo-nents that are exposed as web services will be able to communicate withother runtime platforms; those exposing itself as Jini or OSGi services willnot.

– Protocol Heterogeneity. The underlying protocol used during service in-teractions often causes similar interoperability problems. If a client wantsto invoke a service that is offered by two providers (one using SOAP andthe other using RMI/IIOP), it will need to use an entirely different protocolto contact each service. Worse yet, if the protocol at the service endpointis changed to another one, the client will no longer be able to speak withthat service. It is clear that the main challenge in this area is to hide thetechnicalities of protocol selection for the programmer. The Web Service In-vocation Framework [7] is a first step in that direction and it is discussed inSection 4.


This is not an extensive list of the challenges that come with service-orientedcomputing. Service orchestration and dynamic composition, for example, areother important challenges that are actively researched, but they are outside thedomain of this paper as we are mainly interested in client-service interactions.

3 Design Goals for an Integrated Language

Our main objective is to design a programming model that integrates Web Ser-vices programming and Object-Oriented programming. This model must fosterrapid integration of heterogeneous software components. Our objective can besplit into a number of goals:

– Dynamic Service Binding. Section 2 has shown that compile-time servicebinding not only neglects the volatility of a service, it also obstructs theadaptability and extensibility of a service client: reusing such clients withdifferent providers would be impossible without making all service referencespoint to the new provider. Dynamic service binding effectively avoids theseproblems by wiring service references at runtime.

– Transparent Failover. Programmers must be freed from having to dealwith failures that are caused due to network problems or server outages.For any given service reference that cannot reach its target web service, themiddleware should transparently select another target service from a storeof alternatives and then reinvoke the operation.

– Constraint-driven Service Selection. Our programming model must en-able programmers to specify their business constraints and non-functionalrequirements so as to allow the middleware to transparently select the opti-mal service for each service interaction.

– Platform & Protocol Independence. Applications developed using ourprogramming model must be able to communicate with every service thatdescribes its functionality by means of a WSDL document, regardless of theplatform and the protocol used by the service provider.

– Transparency. Our programming model must hide technical middlewareinteractions for programmers. Ideally, developers are only faced with imple-menting the business logic, whereas all infrastructure-related technicalitiesare injected by the compiler.

Taking this list of design objectives as a reference, the next section evaluatesthe Web Services Invocation Framework, a popular framework for programmingplatform-independent, protocol-independent service interactions.

4 Web Service Invocation Framework

The Web Service Invocation Framework (WSIF) [7] was initially developed byIBM and has later been donated to Apache as an open source project. WSIF’smain objective is to introduce a clear and simple API to invoke web services


in a protocol-independent way. Doing so, WSIF tries to combine protocol inde-pendence with the platform independence property of web services. WSIF usesthe term “web services” in a very broad sense: every resource that describes itsfunctionality in a WSDL document can be invoked by the framework.

Fig. 1. Protocol dependence (left) versus WSIF’s protocol independence (right).

The left side of Figure 1 shows a simple service architecture not using the WebService Invocation Framework. A Java client interacts with two remote servicesand is forced to use different communication protocols to invoke operations oneach service. The main problem with this protocol-dependent approach is thatprogrammers must be familiar with both protocols. A second problem is thatthe Java client breaks if a service provider switches to another protocol (orprotocol version). This is because the protocol used for invoking operations ona service endpoint is hardwired in the business logic of the service client. Suchprotocol changes are problematic in the context of cross-enterprise operations,where internal decisions to update the communication infrastructure are notnecessarily communicated to external business partners.

WSIF solves this problem by letting the middleware dynamically decide onthe protocol to be used for interacting with a service. Programmers no longerhave to obfuscate their code with protocol-specific API interactions; instead,they interact with the WSIF API and are thus shielded from the technical de-tails of service interactions, as shown in the right part of Figure 1. In order toinvoke operations on remote services in a transparent, protocol-independent way,WSIF relies on dynamic providers. Each of these providers understands one pro-tocol and they can be added or removed at runtime. Such a pluggable providerarchitecture enables to dynamically extend or reduce the number of protocolsthat the service client can use when interacting with a remote service, at thesame time minimizing programmer intervention. Invoking operations on remoteservices using WSIF can be done in two ways:

– Stub-based Invocation. The stub-based approach requires program-mers to extract Java classes from WSDL descriptions of services using aWSDL2Java compiler. Such stubs allow for type-safe invocations on remoteservices, at the same time removing all protocol-specific interactions from thesource code. Even with these precompiled stubs the decision which protocolto use can be taken at runtime due to the pluggable provider architecture.

– Stubless Invocation. Next to stub-based invocation, WSIF also supportsstubless invocation. This approach allows programmers to dynamically build


1 try {

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

3 WSIFServiceFactory factory = WSIFServiceFactory.newInstance();

4

5 // --2-- Parse WSDL

6 WSIFService service =

7 factory.getService(

8 "/example/StockQuote.wsdl", // WSDL location

9 null, // Service Namespace

10 null, // Service Name

11 "http://...url...", // PortType Namespace

12 "StockQuotePortType" // PortType Name

13 );

14

15 // --3-- Get the stub

16 StockQuote stub = (StockQuote)service.getStub(StockQuote.class);

17

18 // --4-- interact with the service

19 float quote = stub.getQuote(aQuote);

20 System.out.println(quote);

21 }

22 catch (WSIFException we) {

23 we.printStackTrace();

24 }

25 catch (RemoteException re) {

26 re.printStackTrace();

27 }

Listing 1.1. Invocation of a StockQuote web service using WSIF stubs

and execute a web service interaction using operations provided by the WSIFAPI. This functionality resembles the functionality that is offered by the JavaReflection API. Stubless invocation is not considered in detail in this paper,as it firmly decreases the level of abstraction by requiring programmers towrite a considerable amount of interactions with the WSIF API before a ser-vice can be dynamically invoked. Additionally, dynamic invocation providesless compile-time guarantees (refer to [8] for more details).

4.1 Evaluation of WSIFSection 2 enumerated the challenges of service interactions in service architec-tures that are subject to continuous change, leading to the list of design goals ofSection 3. Here, we evaluate the WSIF framework with respect to these objec-tives. The identified weaknesses will be tackled in the next sections.

Strengths. The protocol independence property of WSIF-driven service clientsincreases the customizability and robustness of service clients because they can


survive protocol switches without requiring human intervention. An additionaladvantage of WSIF is that protocol-specific interactions are entirely transparentfor programmers, which allows the latter to concentrate on the implementationof the business logic. WSIF also obtains a high degree of platform-independencebecause it allows a service client to communicate with any service that exposesits functionality by means of a WSDL description.

Weaknesses. WSIF is very effective when it comes to automated protocol pro-visioning in heterogeneous service architectures. But other challenges were over-looked and currently, no other frameworks exist that enrich WSIF with adequatesupport for dealing with them. This leads to the following list of shortcomingsrefraining WSIF from realizing the objectives enumerated in Section 3:

– Hardwired Service Locations. WSIF cannot hide the location of services.Developers must provide their WSDL location to the WSIFServiceFactorywhen invoking the getService operation (as shown on line 8 in Listing 1.1).This static binding strategy leads to volatility problems because WSIF cannotdeal with dynamically varying Quality of Service levels, service migrationand service deprecation. Clients that use WSIF also become very vulnerableto distribution problems such as network problems or server outages.

– No Service Selection. By relying on a single, hardwired service endpoint,WSIF cannot deal with dynamically changing Quality of Service levels, norcan it cope with the multitude of substitutable, competing services. Theuser must decide statically which service to invoke, and then hardwire itsendpoint URL in the source code of the service client. If more interestingservices are added to the service architecture, then older clients will not findthese services; they will continue to use their hardwired, outdated services.

– Lack of Transparency. As shown in listing 1.1, programmers are stillresponsible for (1) creating a WSIFServiceFactory instance, (2) using thatfactory to create a WSIFService, and (3) requesting a stub from that reifiedweb service. By forcing programmers to write these API interactions, WSIFdecreases the level of transparency between service interactions and localobject invocations, and this overshadows the reduction in code size that wasachieved by the benefit of protocol transparency.

– Compilation. Every stub must be compiled separately using theWSDL2Java compiler before the application can be compiled. Also, changesto the WSDL document require manual recompilation of the stub.

In summary, the benefits of WSIF focus on providing protocol-independentinvocations of web services that execute in heterogeneous environments. But theframework suffers from integration problems as well. The level of transparencyis still too low, and programmers are still forced to decorate service invocationswith code for handling infrastructural technicalities. In order to solve these prob-lems, we have integrated the Web Service Invocation Framework with ServiceJ[8], our Java dialect with specialized concepts for web service interactions. Thenext section describes how ServiceJ extends Java with new language concepts.


Section 6 explains how WSIF and ServiceJ are integrated, and how WSIF oper-ations can be injected during the compilation of ServiceJ to Java.

5 ServiceJ. Abstractions for Client-Service Interactions

Driven by the need for a high-level language to implement client-service interac-tions, we have designed a Java extension, called ServiceJ. This dialect extendsJava in two ways. Type qualifiers (Section 5.1) signal the compiler to inject codefor service retrieval and for handling communication failures. Declarative opera-tions (Section 5.2) provide programmers with high-level abstractions to fine-tuneservice selection according to predefined quality attributes, such as functional re-quirements or Quality of Service constraints.

5.1 ServiceJ extends the Java Type System with Type Qualifiers

ServiceJ introduces a special type qualifier to distinguish external service ref-erences from local object references. A field referring to a service reference isdeclared using the pool qualifier. An example is shown below:

pool PrinterService printer;printer.print(aFile);

This code declares a field printer of type PrinterService decorated with thepool qualifier. That qualifier signals to the compiler that the printer field mayrefer to any service of which the type is compatible with the PrinterServicetype. In other words, by using the pool qualifier, programmers allow the ServiceJmiddleware to use a non-deterministic service selection algorithm; they considerall service endpoints to be equal.

Contrary to WSIF references, pool fields are never initialized by program-mers. This would hardwire the field to a single service endpoint, leading to theproblems that were encountered in WSIF (see Section 4.1). Instead, the ServiceJcompiler injects instructions that perform service selection and dynamic servicebinding, as such exonerating programmers from having to write infrastructure-specific middleware interactions. Interactions for service lookup are now trans-parently injected during compilation, while service selection and service bindingare executed at runtime, in a non-deterministic, fault-tolerant way.

Solving Distribution Problems. WSIF cannot handle distribution problemsso programmers are forced to decorate each service invocation with failure han-dling logic, as such obfuscating the business logic. ServiceJ solves this problemby integrating support for service failover with the pool qualifier. If such a poolfield becomes the target of a method invocation, the necessary logic for dealingwith distribution problems is injected by the compiler. Solving an availabilityproblem typically comprises (1) the selection of another service that conformsto the static type of the pool field, (2) binding the new service reference to thatfield, and (3) reinvoking the operation that was unsuccessfully invoked on the


unavailable service. These instructions are injected by the ServiceJ compiler forall method invocations on fields that were qualified as pool fields.

Solving Volatility Problems. As discussed in Section 4.1, WSIF cannot dealwith service volatility. ServiceJ provides a solution to this problem by removingfrom the source code all infrastructure-specific service information. Program-mers declare a single virtual service using a pool field without initializationcode. This approach increases reusability and transparency, leads to better codecomprehension, and thus reduces the possibility for introducing bugs.

The non-deterministic service binding strategy of the pool qualifier increasesload balancing and enables service failover. Often, however, developers will wantto fine-tune service selection, limiting the set of assignable services to those ser-vices that exhibit specific functional or non-functional characteristics. This levelof configurability is not supported by the pool qualifier. ServiceJ therefore intro-duces special operations for further constraining service selection, as discussedin the next section.

5.2 Declarative Operations for Fine-tuning Service Selection

Several substitutable services often provide different Quality of Service (QoS)levels and these levels may be subject to continuous change. This allows devel-opers of service clients to finetune service selection, limiting the set of invocationtargets to those services that provide the appropriate Quality of Service. WSIFlacks this functionality, but ServiceJ introduces two declarative operations, whereand orderby to allow developers to specify constraints at a high level of abstrac-tion. Both operations are discussed next.

Fig. 2. A hierarchy of type qualifiers

Constrained Service Selection. ServiceJ allows programmers to specify aservice selection policy using a declarative operation, where, which accepts aboolean condition representing the service selection constraint. An example is


shown in Listing 1.2, which shows code for binding the printer pool field to acolor printer found at the second floor of a building.

Dealing with Client Preferences. The pool qualifier advocates non-deterministic service selection. Sometimes, however, some services are preferredabove others based on service-specific characteristics. ServiceJ introduces theorderby operation to specify such client preferences. This radically changes theservice selection strategy: in stead of arbitrarily selecting a service from a con-strained set, now a deterministic service selection policy is required. To dis-tinguish between both non-deterministic service fields and deterministic servicefields, ServiceJ introduces a second type qualfier, sequence, which is a subtypeof the pool qualifier. Technically, a sequence can be seen as a sorted list ofservices, whereas a pool corresponds to an unordered collection of services, asshown in Figure 2. Listing 1.2 shows the declaration of a printer sequence fieldthat prefers to print files on cheap printers.

1 // unsorted collection, no preferences

2 pool Printer printer

3 where printer.supportsColorPrinting()

4 && printer.getFloor().getNumber()==2;

5

6 // sorted list, preference-driven

7 sequence Printer printer

8 where printer.supportColorPrinting()

9 orderby printer.getPriceFor(aFile);

Listing 1.2. Declarative operations for fine-tuning service selection

More details about ServiceJ’s language concepts, as well as a formal proof of itstype soundness, can be found in a preceding paper [8].

6 Implementation Issues for Integrating ServiceJ & WSIF

Our goal is to reuse both the Java compiler and the Java Virtual Machine for thedevelopment and execution of ServiceJ applications. Being able to reuse bothtools is beneficial for two reasons. By reusing the Java compiler, we are able tooptimize ServiceJ applications in the same way regular Java code is optimized atcompile time. Additionally, by reusing the standard JVM, ServiceJ applicationsbecome interoperable with all other Java applications that run on the standardJVM. This means that existing Java code, such as libraries and APIs, can bereused in ServiceJ programs without requiring source code modification.

Obviously, simply reusing both tools to run ServiceJ programs is insufficient,as the Java compiler is unable to recognize our newly introduced language fea-tures. Therefore, we introduce a preprocessing step in which ServiceJ applicationsare transformed to Java applications. This transformation injects middlewareinteractions for guiding the integrated ServiceJ and WSIF middleware duringservice interactions. The overall process of compiling ServiceJ to Java is shownin Figure 3 and runs through several steps:


– Lexer & Parser. First, the source code of a ServiceJ program is read bya lexer and a parser. These where generated by ANTLR [9] after the Javagrammar had been extended with the ServiceJ syntax extensions. The resultof this parsing step is a basic Abstract Syntax Tree (AST).

– Acquiring Semantics. The AST as built by the parser provides only basicinformation about a program, and this makes it hard to transform the Ser-viceJ program into an equivalent Java program. Therefore, we first turn thisbasic AST into a semantic AST, which can be seen as a metamodel of theServiceJ program. In this semantic AST, all elements of a program are rei-fied by classes that provide functionality for querying and manipulating themetamodel instance.

– Compiling ServiceJ to Java. In this step, the ServiceJ metamodel instanceis queried so as to build an equivalent Java metamodel instance, in which allServiceJ-specific instructions are translated to a number of Java instructions.This transformation is responsible for the injection of interactions with theServiceJ middleware and WSIF into the Java metamodel instance.

– Code output and Compilation. Finally, the obtained Java metamodel in-stance is written out as Java files using a codewriter. This Java code is thencompiled, yielding a compilable Java program. This program contains inter-actions with the ServiceJ and WSIF middleware that where injected duringthe transformation process.

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

7 Illustration

This section illustrates how responsibilities are divided between the developer,the ServiceJ middleware, and the WSIF middleware. First, we focus on the taskof the programmer (Section 7.1). Then, we show how the ServiceJ application,after being compiled with the ServiceJ compiler, interacts with the ServiceJmiddleware, which in turn cooperates tightly with the WSIF middleware so asto successfully execute an interoperable service interaction (Section 7.2).

7.1 The Task of the Developer

In this example, the task of the programmer is to implement a service interactionfor printing a file, represented by the variable aFile. This file must be printed on


a color printer offering a throughput of more than 20 pages per minute. Severalprinters may satisfy these constraints, so the file must be printed on the printerwith the lowest number of queued jobs. As shown in the overview figure of thissection (Figure 4), the programmer can easily implement this service interactionby using the language constructs introduced by ServiceJ. A pool field printeris declared along with a where operation representing the service constraints,and an orderby operation specifying the preferences of the service client. Theresulting code is small, elegant, and statically type-checkable. The programmerworks at a very high level of abstraction, since operations are invoked on a virtualservice endpoint and not on a hardwired physical service endpoint.

Contrary to existing Java frameworks, programmers no longer have to locatephysical services, nor are they forced to insert instructions for service selection,service binding, and service failover. These responsibilities are deferred to theServiceJ middleware, which transparently interacts with WSIF, as will be ex-plained in the next section.

7.2 The Task of the Integrated ServiceJ-WSIF Middleware

Under the hood, ServiceJ and WSIF cooperate tightly to enable successful serviceinvocation. Before the print operation can be invoked on a remote service, theServiceJ middleware has to search for services that satisfy all the constraintsthat are imposed on the pool field. This search functionality was injected duringthe ServiceJ-to-Java transformation (see Section 6).

First, a ServiceJ registry is contacted, requesting the list of URLs that publishthe WSDL definitions of those services that conform to the static service type(step 1 in Fig. 4). ServiceJ passes these URLs to the WSIF middleware. It doesso by creating a WSIFServiceFactory, which creates a WSIFService instancerepresenting a reified version of each physical service endpoint (step 2). ThatWSIFService is then used to request a stub for contacting the service (step 3).All these stubs are returned to the ServiceJ middleware layer, where they areadded to a service pool (step 4).

Steps 1–4 enforce that each remaining service conforms to the static type ofprinter, but there are no guarantees about whether they satisfy the constraintsthat were specified in the where clause of the printer field. Therefore, steps5–7 further constrain the service pool. Each service is contacted in order tocheck whether it satisfies the requirements of the user. To do this, ServiceJ relieson WSIF and its dynamic providers to communicate with these services, butthis is not shown in the overview figure (refer to [10] for more information).ServiceJ and WSIF contact each service using its preferred protocol and, whenthe required information is retrieved, the ServiceJ middleware constrains theservice pool, retaining only those services that comply with the constraint asrepresented by the where operation. A similar interaction is needed to enforcethe user preferences as represented by the orderby operation, but this is notshown in Figure 4.

Finally, the best service from the remaining service sequence is chosen (S1

in Fig. 4) as the active service, i.e. S1 is bound to the printer variable. The


print operation can now be invoked, but this invocation fails because S1 can nolonger be contacted (steps 8a–8b in Fig.4). Therefore, the ServiceJ middlewareautomatically retries to invoke the operation on the second-best service from thesequence, S4, which successfully handles the request (steps 9a–9b in Fig. 4).

Fig. 4. Illustrative execution scenario of ServiceJ & WSIF integration

8 Related Work

Language constructs for handling connectivity problems in web computing werefirst introduced by Cardelli et al. in [11]. They use service combinators such as


the sequential execution operator (denoted “S1?S2”) for stating that S2 must becontacted if S1 is unreachable. These Service combinators are used in object-oriented languages such as WebOz [12], WebL [13], and XL [14] to enable webservice failover. Their dependence on hardwired service references, however, doesnot capture the volatility of web service architectures and it disables dynamicservice discovery. Also, these languages lack support for defining constraints andselection policies.

JR [15] is a Java extension with specialized concepts for distributed pro-gramming. Similar to ServiceJ, JR programs are translated to Java before beingcompiled with the Java compiler. The concepts for JR are more geared towardslanguage support for synchronization primitives in distributed computing andthis makes JR less interesting for implementing the business logic of a serviceapplication. One major drawback of the language is that it expects each serviceprovider to install a JR-specific virtual machine. These assumptions cannot bemade in the context of cross-enterprise operations.

Jini [5] and JavaSpaces [16] are Java-based technologies aimed at implement-ing service-oriented applications. They use a public registry as a common placewhere providers register their services and where clients search for the servicethey need. Services can be registered along with a number of entry objects,where each entry object represents a characteristic of that particular service. APrinterService, for example, may have an entry object denoting the locationwhere that printer is found in a building. One drawback is that Jini forces theprogrammer to write a considerable amount of boilerplate code for retrievingservices [17].

BPEL is a language for defining orchestrations of services, but this lan-guage lacks support for dynamic service binding. Service endpoints are hard-wired in executable processes, so network problems and service volatility maybreak client processes. This problem is partially solved in [18] by introducingflow parametrization. Parametrized flows allow to invoke operations on servicereferences that were obtained as the result of a query, so they enable dynamicservice binding. GPSL [19] is another language with similar concepts. These lan-guages provide service selection, but they fail to support protocol independencebecause every process must communicate by exchanging WSDL documents. Thismakes it hard to integrate GPSL processes with services that don’t understandthe underlying protocol.

The GridRPC protocol, a communication protocol for scientific computa-tional grids, is implemented using web service protocols in [20]. The main reasonis that existing GridRPC-based systems rely on vendor-specific protocols, thusjeopardizing interoperability. Designing such a web services layer is a step inthe good direction, since interoperability is improved. But other issues, such asservice volatility and distribution problems are not tackled. One solution couldbe to incorporate a GridRPC-to-WSDL transformer into our ServiceJ compiler.That way, the applications would remain interoperable thanks to WSIF, andthey would be more robust in a distributed setting thanks to ServiceJ.


The Java Commodity Grid Kit (CoG) [21, 22] is a framework for implement-ing Java applications for service grids. The framework offers classes for accessingspecialized information and security services, as well as management services forconfiguring the grid. By abstracting these interactions in a framework, the pro-grammer is able to approach these issues at a higher level. The main advantageof commodity kits like Java CoG is that they enable rapid development of sophis-ticated client-server applications. One drawback when compared with ServiceJis that programmers need to insert a large amount of framework interactions intheir source code. A lot of these API calls are also based on the Java ReflectionAPI, e.g. passing class names as String objects, which gives programmers lessstatic guarantees than our language extension.

ServiceJ extends the Java type system with type qualifiers. These qualifierscan be traced troughout the source code and thus allow the compiler to injectmiddleware interactions whenever a service is to be invoked. Similar extensionswere proposed in [23], which adds type qualifiers for creating transparent proxiesfor future objects and in [24], which adds qualifiers for supporting referenceimmutability in Java.

9 Conclusion and Future Work

ServiceJ introduces special language concepts that allow programmers to focuson the business logic, at the same time allowing them to fine-tune service selec-tion in a declarative, type-safe way. We have shown how the ServiceJ compilertranslates ServiceJ to Java, a process during which WSIF’s protocol-independentservice interactions and ServiceJ’s infrastructure-specific service selection algo-rithms cooperate so as to dynamically bind the optimal service to each pool fieldoccurring in a ServiceJ program.

There are two major future directions for the ServiceJ research project. First,we plan to extend its type system with semantic information. Currently, ServiceJrelies on explicit type conformance, so it cannot detect that a PrinterServiceand a PrintingService provide similar functionality if both types are not re-lated in a type hierarchy. The injection of semantic information in the typesystem provides a solution to this problem. Second, we will define abstractionsfor implicit service interactions. Such interactions often occur in event drivenservice architectures, but currently, ServiceJ only integrates support for explicitclient-service interactions.

References

1. C# Spec.: http://www.ecma-international.org/2. Java EE 5.0 Spec.: http://www.jcp.org/en/jsr/detail?id=2443. WSDL Specification v1.1: www.w3.org/TR/wsdl. (2001)4. SOAP Specification: http://www.w3.org/TR/soap/5. Jini Architecture Specification: http://www.jini.org6. Open Services Gateway Initiative: http://www.osgi.org


7. M. Duflter et al.: Web Service Invocation Frameworkhttp://www.research.ibm.com/people/b/bth/OOWS2001

8. S. De Labey, M. van Dooren, and E. Steegmans: ServiceJ. A Java Extension forProgramming Web Service Interactions. In: Proceedings of the 5th InternationalConference on Web Services, Salt Lake City, Utah (2007)

9. Ashley, A.J.: ANTLR tutorial.http://supportweb.cs.bham.ac.uk/documentation/tutorials/

10. De Labey, S., van Dooren, M., Steegmans, E.: Ser-viceJ. Service-oriented Programming in Java. Technical Reporthttp://www.cs.kuleuven.be/publicaties/reports/CW/2006/

11. Cardelli, L., Davies, R.: Service Combinators for Web Computing. In: Trans. onSoftw. Engineering 25(3) (1999)

12. Hadim, M., et al.: Service Combinators for Web Computing in Distributed Oz.In: Proc. Intl. Conference on Parallel and Distributed Processing Techniques andAppl. (2000)

13. Kistler, T., Marais, H.: WebL - A Programming Language for the Web. In: 7thIntl. Conference on the WWW. (1998)

14. Florescu, D., Gruenhagen, A., Kossmann, D.: XL: A Platform for Web Services. In:Proceedings of the First Biennial Conference on Innovative Data Systems Research.(2003)

15. Keen, A.W., Ge, T., Maris, J.T., Olsson, R.A.: Jr: Flexible distributed program-ming in an extended java. ACM Trans. Program. Lang. Syst. 26(3) (2004) 578–608

16. Mamoud, Q.: JavaSpaces Technology: Beyond Conventional Distributed Program-ming Paradigms – www.javaspaces.org. (2005)

17. S. De Labey and E. Steegmans: Advanced Language Constructs for DevelopingIntra-organizational Service Architectures. In: Proceedings of the 2nd EuropeanYoung Researchers Workshop on Service Oriented Computing (YRSOC’07). (2007)

18. D. Karastoyanova, et al.: An Approach to Parametrizing Web Service Flows. In:Proceedings of the 3rd International Conference on Service Oriented Computing.ICSOC05. (2005)

19. D. Cooney, et al.: Programming and Compiling Web Services with GPSL. In:Proceedings of the 3rd International Conference on Service Oriented Computing.ICSOC05. (2005)

20. Shirasuna, S., Nakada, H., Sekiguchi, S.: Evaluating web services based imple-mentations of gridrpc. In: HPDC ’02: Proceedings of the 11th IEEE InternationalSymposium on High Performance Distributed Computing, Washington, DC, USA,IEEE Computer Society (2002) 237

21. von Laszewski, G., Gawor, J., Lane, P., Rehn, N., Russell, M., Jackson, K.: Featuresof the Java Commodity Grid Kit. Concurrency and Computation: Practice andExperience 14 (2002) 1045–1055

22. von Laszewski, G., Foster, I., Gawor, J., Smith, W., Tuecke, S.: CoG Kits: ABridge between Commodity Distributed Computing and High-Performance Grids.In: ACM Java Grande 2000 Conference. (2000) 97–106

23. Pratikakis, P., Spacco, J., Hicks, M.: Transparent Proxies for Java Futures. In:OOPSLA04. (2004) 206–223

24. Tschantz, M.S., et al.: Javari: adding reference immutability to Java. In: OOPSLA’05: Proc. of the 20th Conf. on OOP, Systems, Languages, and Applications. (2005)

Date post:	11-Feb-2022
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Integrating ServiceJ with Interoperable Web Service Invocation - Lirias

Documents