Separation of Concerns in Service-Oriented Applications Based on Pervasive Design Patterns Cristian Mateos, Marco Crasso, Alejandro Zunino, Marcelo Campo ISISTAN Research Institute - UNICEN and CONICET (Argentina)

Problem statement Service-Oriented Computing (SOC) is a relative new and exciting paradigm for distributed computing Key goals (from a developer's perspective): Reusability Discoverability (e.g. UDDI) Loose coupling

The Web Service canonical model

Problem statement (cont.) Service-Oriented Computing (SOC) is a relative new and exciting paradigm for distributed computing Key goals (from a developer's perspective): Reusability Discoverability (e.g. UDDI) Loose coupling

So, how do we take advantage of these three without making SOC development a painful experience?

Related efforts Many of the existing approaches consider service-related details when invoking Web Services as crosscutting concerns Existing efforts share a common idea, i.e. to isolate applications from such details

Separation of concerns seems to be the right path towards truly loose coupling Layering (Daios, WSIF, Apache CXF) Source code annotations (Spring) AOP (WSSI, WSML)

Related efforts (cont.) Some related efforts are contract-subordinated, or API-based: WSIF, Apache CXF, Daios, Spring, WSSI and WSML With such, efforts developers code the application assuming that providers adhere to abstract contracts, which is not true Other efforts also consider service contracts as crosscutting concerns Generative Programming is used to free developer from adapting providers' specific contracts to abstract contracts Motahari Nezhad et al., (framework placeholders) Cavallaro et al. (custom XML-based mapping language) Nagano et al. (generic formal specifications)

Our proposal - DI4WS DI4WS advocates to a code-first approach to service outsourcing Unlike existing code-first approaches, DI4WS avoids the usage of ad-hoc languages and formalisms DI4WS is instead based on pervasive development patterns (Dependency Injection and Adapters) DI4WS is based on the well-established component-oriented development paradigm and assumes good development practices DI4WS is technology-agnostic (we have an implementation based on Java/Spring/WSDL2Java though)

DI4WS - Component model

Loose coupling in DI4WS Lightweight formalism If a SOC application with m internal components {C1..Cm} invokes n services {S1..Sn}, its overall Ce (Efferent Coupling) can be determined by: m n

C e =∑ ∑ C ij i=1 j =1

When Ci j = 1, the in-house component Ci is coupled to the contract of Sj

Loose coupling in DI4WS Lightweight formalism (cont.) non DI4WS

n <= Ce<= n*m

DI4WS

Ce <= n

Corner case: When each service is invoked from exactly one in-house component, Ce = n

DI4WS - Component model instantiation Let us examine the non-DI4WS case...

A solution not using dependency injection

A solution using dependency injection

DI4WS - Component model instantiation (cont.) Combination of DI and Web Service adapters:

✔ Pros: looser coupling, easier testing, cohesiveness ✗ Cons: More classes, potentially decreased performance

DI4WS - Preliminary results Research question 1 (Q1): Does the code obtained via DI4WS perform competitively compared to those resulted from employing a contract-first approach to service consumption? Test conditions: 4 applications coded via Axis 2, and Daios, Spring 2.5 and DI4WS (and thus three forms of separation of concerns; layering, annotations and DI plus adapters) Two LAN-connected machines (54 Mbps wireless LAN) 21 Web Services (including simple/complex datatypes and arrays of these) deployed on a Tomcat 6 container We tested average invocation time, and RAM allocation via jhat http://java.sun.com/javase/6/docs/technotes/tools/share/jhat.html)

DI4WS - Preliminary results (cont.)

Mem. (MB) Static Daios Spring 2.5 DI4WS

App. #1 App. #2 5.74 5.73 10.19 10.12 13.49 13.47 8.23 8.24

App. #3 5.74 10.12 13.50 8.26

App. #4 5.81 10.17 13.55 8.35

DI4WS - Preliminary results (cont.) Research question 2 (Q2): Does the combination of DI and the Adapter design pattern improve code maintainability? [Crasso et al., 2010a]

Test applications: Service-based agenda (four services) Metrics: CBO (Coupling Between Objects), RFC (Response for Class)

DI4WS - A broader view

DI4WS is a sort of “client-side contract-last” model for developing SOC applications

DI4WS - Preliminary results (cont.) Research question 3 (Q3): Does the code obtained via a contract-last approach to service consumption help in finding services? [Crasso et al., 2010b] We used a dataset of nearly 400 publicly available Web Services, 30 applications under several variants (DI4WS versus non-DI4WS; commented versus uncommented) We mined each application variant to ask a search engine, calculate whether the first ranked service was relevant or not and how many relevant services were included before non relevant ones

DI4WS - Preliminary results (cont.) We compared the retrieval effectiveness obtained with each code variant by assessing Recall-at-n, Precision-at-n and Normalized Recall measures: Recall-at-n computes how effective a search engine is in retrieving relevant documents in a window of n documents Precision-at-n computes precision at different cut-off points of the results list. We used three special cases, a case for n=1, another for n=10, and for n=R (a.k.a. R-Precision) Normalized Recall (NR) takes into account Recall and the position of each relevant retrieved document within the result list

DI4WS - Preliminary results (cont.)

DI4WS - Work in progress More empirical evidence to better support the answers to the previously mentioned research questions: For Q1 (performance aspects) and Q2 (code maintainability) we have a running project for rengineering ~1.500 services from ANSES (http://www.anses.gov.ar) For Q3 (discoverability) we are experimenting with a dataset of ~5000 services (http://www.uoguelph.ca/~qmahmoud/qws/)

Semi-automatic generation of service adapters Ongoing project (ANPCyT grant PAE-PICT-2007-002312) Subgoal: Integrating DI4WS with the approach for component replaceability published in [Flores and Polo, 2009] Supporting tools (EasySOC Eclipse plug-in) Binaries: http://mcrasso.sites.exa.unicen.edu.ar/easysoc Video tutorial: http://www.youtube.com/watch?v=yeE7Nxdblwk

Semi-automatic adapter generation Problem: Adapter development is at present the Achilles' heel of the DI4WS model Short-term research: To investigate whether a test-based approach to component substitutability can be used for Web Service outsourcing Component substitutability in a nutshell: Given a component C and a candidate upgrade K, they should match on the functional mapping from input to output, i.e. their behavior input

≈ input

C

K

output

≈ output

Semi-automatic adapter generation (cont.) generate

C

generate

K <> generate Adapters execute test suite

A proof-of-concept of these ideas are being implemented based on the EasySOC plug-in and the JUnit framework

The EasySOC Eclipse plug-in

References ●

●

●

[Crasso et al., 2010a] Marco Crasso, Cristian Mateos, Alejandro Zunino and Marcelo Campo. “EasySOC: Making web service outsourcing easier”. Information Sciences. Elsevier. 2010. To appear. http://dx.doi.org/10.1016/j.ins.2010.01.013. [Crasso et al., 2010b] Marco Crasso, Cristian Mateos, Alejandro Zunino and Marcelo Campo. “Empirically Assessing the Impact of Dependency Injection on the Development of Web Service Applications”. Journal of Web Engineering 9(1):66-94. Rinton Press. 2010. http://www.rintonpress.com/journals/jweonline.html#v9n1. [Flores and Polo, 2009] Andrés Flores and Macario Polo. “Testing-based Process for Component Substitutability”. Software Testing, Verification and Reliability. John Wiley & Sons. 2009. To appear.

Thank you!