Web Services Implementation Methodology for SOA Application

Siew Poh LeeSingapore Institute of Manufacturing Technology

71, Nanyang Drive638075

SINGAPOREsplee d,SIMTech. a-star. edu. sg

Lai Peng ChanSingapore Institute of Manufacturing Technology

71, Nanyang Drive638075

SINGAPORElpchan d,SIMTech. a-star. edu.sg

Eng Wah LeeSingapore Institute of Manufacturing Technology

71, Nanyang Drive638075

SINGAPOREewlee d,SIMTech. a-star. edu. sg

Abstract With the popularity ofWeb Services technology andthe increase trend of developing Service-OrientedArchitecture (SOA) software, there is a need for animplementation methodology for Web Services. This paperaddresses the SOA application development challenges,identifies gaps in agile software methodology for Web Servicesdevelopment, and observes Web Services characteristics andits best practices. The contribution of this paper is to extendany existing agile software methodology to include WebServices Best Practices into the agile software methodology.

I. INTRODUCTION

The Service-Oriented Architecture (SOA) is a softwarearchitecture that defines the use of services, to supportsoftware user requirements [2]. The characteristics of theseservices are reusable business components; loosely coupled;building blocks of SOA application with the intent toprovide services to either end user applications or otherservices through published and heterogeneous networkaddressable software component.

The implementation of SOA application is made possiblethrough the realization of Web Services. Web Service is asoftware component representing specific set of businessfunctions that can be described, published and invoked overthe Internet using XML-based open standards such asSOAP [3], WSDL [4] and UDDI [5]. The SOA applicationdevelopment involves developing software components forsoftware reuse and wrapping software components as WebServices for end user applications or other servicesconsumptions. However, there are gaps in the existingsoftware component development methodology as it doesnot include the design and development factors specific forWeb Services.

This paper discusses the research work done in bridgingthe gaps by investigating the characteristics and the bestpractices ofWeb Services development. The outcome of theresearch work is part of the specification developed forOASIS Framework for Web Services Implementation(FWSI) [13] Implementation Methodology Sub-Committee[15] (IMSC) in the effort to develop implementationmethodology for Web Services.

II SOA APPLICATION DEVELOPMENTCHALLENGES

In a dynamic digital economy, the demand for directprocess integration to business partners from organisationsand sharing of information is increasing. Organisations aregradually turning to SOA application to increase theirbusiness agility and IT productivity. The building blocks forSOA application come from different service providers. TheSOA application development process is complex and

tedious. It requires proper software project managementplanning and control to ensure systematic approach forhandling and developing SOA application. This is attributedto the fact that some of these building blocks of services areoutside company's boundary. The confronted challenges forSOA application development are:

1. Difficulty in capturing of user requirements as therequirements no longer derives from a single source. Itcan come from multiple stakeholders who may begeographically distributed.

2. Difficulty in collating different services as not all theservices are implemented using the same technology.Some services could be implemented using C++, C#,Java, PERL, etc. The hosting of services on differenttechnology platforms also contributed to the collatingdifficulties.

3. Difficulty in services consumption due to differenttypes of services provided. Some services only supportasynchronous interaction; some may supportsynchronous interaction, etc. This poses difficulty inSOA application.

4. Difficulty in services communication because ofdifferent interfaces, e.g. document-oriented messageexchange; parameters-oriented message exchange,supported by different services.

5. Different services offer different degrees of servicecoupling. Document-based services are more looselycouple than non document-based (i.e. parameter-based)services.

6. Complicated task in conducting SOA application test asit requires a well-coordinated effort from all services'providers to ensure all services are available.

To address the challenges mentioned, we need to analyzethe characteristics of Web Services and the best practicesfor Web Services development in order to explore thepossibility of enhancing the existing software developmentmethodology with the inclusion of Web Services specificactivities for SOA application development. With this asour research basis, our approach for carrying this research isdescribed in the following section.

III RESEARCH APPROACH

Our approach is to first study an existing agilemethodology and identifies gaps in the methodology. Thesecond is to study the Web Services development steps toidentify the steps specific to Web Services. The third is tostudy the Web Services characteristics and its best practices.

335

0-7803-9701-0/06/$20.00 (C2006 IEEE

The result of these is the proposed methodology for WebServices development. The workflow of our approach isshown in Figure 1.

| | S)rlgg StudyfWeb Services1 Study f We4bS;evicestIl SMWaMthM dgy Development Steps & Bhctri§tic§ BdM Practices

apAnatyslv \ Steps / es raty e

Fig. 1 Research Approach

IV ANALYSIS STUDY

A. Software Components, Web Services and SQAApplication

A component is a reusable software building block: apre-built piece of encapsulated application code that can becombined with other components and with additional codeto produce custom application [1]. A software component isan independently deliverable package of reusable softwareservices. Software components are the reusable buildingblocks of SOA application. The relationship of softwarecomponent, Web Services and SOA application is shown inFigure 2. The development of Web Services is based onsoftware component through public interfaces exposed forservices consumption. For example, Order Analyzer andOrder Generator are software components derived fromobjects/classes. The Order Processor is a web service thatuses components Order Analyzer and Order Generator toprovide richer business functionality as building blocks forSOA application.

Web Services

Components Ore = Odr

Fi 2. We S GrervieaBDvlpetol

A =

Fig.I I Reeac ApproachLLL2Ljl

FigSotwr Copoebnerics, WeBD ServelopesndtO

B. Agile Software Development

Component-based development is a softwaredevelopment approach where the entire lifecycle of thesoftware creation, development deployment andmaintenance is centred on the start-to-finish concept ofcomponent lifecycle. Figure 3 depicts a component-baseddevelopment (CBD) process. The CBD process has fivephases, namely Requirements, Analysis, Design,Implementation and Testing. Artifact is produced at eachphase which in turn is the inputs to different types of testingshown in Figure 3. The component has its own lifecycle and

it is related with the whole system lifecycle. Agile softwaredevelopment can be applied in component-based softwaredevelopment. Further reading for the adaptation of agiletechniques into traditional software methodology forRational Unified Process (RUP), for example, is describedin [19]. Any of the agile software developmentmethodologies such as extreme programming (XP) [11],IBM Rational Unified Process (RUP) [11], etc can beapplied to component-based software development:

Fig. 3. An Illustration ofCBD Process

The following Figure 4 gives a snapshot of softwaredevelopment lifecycle activities, for RUP.

Analyze Problem -Define a C::andidate -Structure the -Deline MilssionCapture a C:ommnnr Areffterture ImnplLerntatton Model Ieray ETest MeotivatorsVocabulary - Architectural Structure the Agee on MissionDevelop Visionl Anabyss Imnplementation Begne Asse"mnent &f

Understtand St8keholderF vnalyze Behaviour (Ifor Miadel traccabgildy NeedsNeeds each UC) -ImplementComponents *DefineTestApproach

ElicFtNeeds - UC Analysis GIplement Design Identi&fy Tet madeaDevelop Vlision -Refine the Archirecture Elem ents -Define Test BedManage Dependencies Identify Design -integrate Each dentify TestFind Actors & UGs Elenents Subsystem Environment

Define System Identify Design Integrate Subsystem Prepare H/W & S/WFind Actors A LUs Muechanism s MVanage Scope Of infrastriucture

Manage Scope Of System -Design Components System Prepare Test Data SetsPriorities the US UC Design DvPrioritize the usef DeveoptTest A Evaluate

Refine System Definition *Subsystem Design cases Define Test DetailsDetaira eC nass Design -Refine System Definition TmplementsTestDetail the SoRtare v Detail a UC Implement Test SuiteReqFirernegts tyDetais twe Sofdl are if Execute Test Suite

Requirements *Analyze Test FailuresT Determine Test Resuttsssmprove Test Assets

T bbefine Test Approan hIdentify Test Ideas

*Prepare Guidelines forProject

Requirements Analysis and Design Implementation Testing

RUP Software Development Lifecycle

Fig. 4. A typical software development lifecycle activities

The context for Web Services activities in each of thesoftware lifecycle phases is -abusent from the methodology.The best approach of bridging this gap is to analyze thespecial characteristics ofWeb Services and its best practicesto be considered at different phases of the softwarelifecycle. The following section discusses the Web Servicesdevelopment steps and its characteristics.

C. Web Services Development

Figure 5 shows the workflow for Web Servicesdevelopment. There are eight steps, namely:

1.2.

3.4.

Gather user requirements.Analyze business components to be reused or createnew service.Design the Web Service (WS).Develop WS by implementing business logic withthe used of interface and implementation classes.

2006 IEEE International Conference on Industrial Informatics336

The interface class is where the service interface willbe exposed for consumption and the implementationclass is actual implementation ofthe services derivedfrom software components

5. Build WS by wrapping component into WS.6. Deploy WS to the target web server based on the

deployment script (which is server specific).7. Test and debug WS using web service client (where

the client is server specific).8. Publish WS if publishing to service registry is

required.

As shown in Figure 5, Step 5: Build, Step 6: Deploy andStep 8: Publish are specific to Web Services development as

compared to component-based development. Step 7: WSTest requires a platform specific WS client to test the WS.The artifacts generated from these steps are also specific toWeb Services. The outputs (i.e. interface andimplementation classes) produced from Step 4 are specificto Web Services as well.

(1 ) > (5) WSDLBdiild

(6)I+ WS

Script

3)~~~~~~~~7(3) W1TesignnDeb

_np Develop

Fig. 5. Web Services Development Workflows

By comparing agile software development steps and WebServices development steps, we are able to extend WebServices specific steps into the agile developmentmethodology

D. Web Services Characteristics and Best Practices

The realization of SOA is centered on Web Services(WS). It is important to understand fully the characteristicsof Web Services, in terms of the dos and don'ts for WS,form the basis of the best practices for Web Servicesdevelopment. These characteristics affect the design andimplementation of Web Services. The followingsub-sections discuss the characteristics ofWeb Services andits associated best practices.

WSBP1. Web Services Styles. There are two mostcommon styles of Web Services, namely remoteprocedure call (RPC) style WS and document styleWS. The differences between these two styles are

summarized in Table 1. The RPC-styled offerssimplicity and better tooling support. Thedocument-styled offers greater flexibility anddecoupling of services.

TABLE 1 Web Services Styles

WSBP2. Web Services Interaction Mode. WebServices have four interaction modes. They are

synchronous interaction (i.e. request and wait forresponse), asynchronous interaction (i.e. fire andforget), solicit-response interaction (i.e. the servicesends a message followed by a correlated messagefrom client), and notification interaction (i.e. theservice sends a message). Any one of this modewill affect the way of designing andimplementation Web Services.

WSBP3. Web Services Client Implementation-Interaction Mode. The client implementation willbe determined by Web Services Interaction modes.If it is an asynchronous WS, an asynchronous WSclient implemented using Java API for XMLMessaging JAXM, for example, will be used.Otherwise, Java API for XML for RemoteProcedure Call (JAX-RPC) will be used.

WSBP4. Web Services Client Implementation -

Client Types. The client implementation isaffected by the types of Web Services client.Particularly in Java-based RPC service, there are

three different types of Web Services client,namely static stub, dynamic proxy and dynamicinvocation proxy (DII) of web service clients forconsuming a service. The three types ofclient offerdifferent degree of client flexibility. For example,static stub is the least flexible as any changes to theservice would require rebuilding of service client.DII is the most flexible as the client parses theservice's WSDL in constructing a SOAP messagefor service invocation. Any change to the end pointservice does not require rebuilding of client.

WSBP5. Right Level of Service InterfaceGranularity. The granularity of the serviceinterface affects the design and implementation ofweb service. In addition, it also affects theperformance of the service. The finer thegranularity for service interface, the slower theperformance as it is an overhead to the networkand drop in web service performance.

WSBP6. Interoperability. Interoperability issuescould be caused by different versions of SOAPstandard implementation, different types ofsecurity algorithms for digital signature,encryption/decryption, and variation in supportingWeb Services standards from multiple vendors.The adoption of primitive data type for parameterswhenever possible. Avoid using customized SOAPserializer/deserializer and different types ofencoding standards.

2006 IEEE International Conference on Industrial Informatics

RPC-Styled Diocument-StyledProcessing Business Document-centricMode object-centricInteraction Request and Fire and forget

Response (Asynchronous)(Synchronous)

Implementation Java, EJB JMS

337

WSBP7. Binding Style The use of rpclencoded or WSBP12. Addressable S(docliteral binding style is determined by the needs Every end point serviceof data information being exchange between Web universal resource locatService client and the service. If it is data intensive whether service is availablor the exchanged information is a file, then the service URL would pdoc/literal binding is preferred. If the data status ofthe service.information exchanged is relatively static, then WSBP13. Web Services rrpclencoded binding is preferred. Technology is applied to

WSBP8. Request and Response Performance. needs and objectives. TIWeb Services itself is network intensive. It include reuse businessdemands extra network bandwidth and CPU different IT platforms anprocessing time and memory due to the needs for technologies, directSOAP message serialization and de-serialization integration (B2Bi) betweeoverhead. The common practices for optimizing information sharing. Un(the request and response performance are: (a) needs would ascertain betteperform data caching in either client or server side Technology to be applied a(b) decide Web Services operation granularity, (c) WSBP14. Web Services LUse XML judiciously in document-centric Web The consideration for hierServices by careful considering whether to use Web Services enables the (

whole or segment ofXML document. for services. This facilitzWSBP9. Security. There are various ways to representing ordered grot

secure the information sent between initial SOAP abstraction for domain-spesender and ultimate SOAP receiver via numerous layer), across domains appintermediary SOAP nodes. Different means of and deployment environm(security can affect the way how Web Services are (lower layer).designed and implemented. The security meanscan be through: The best practices for Web Ser

a. Transport Level Security (TLS). In this don'ts ofWeb Services) will be basemean, it leverages on transport security of Web Services listed. Understandimechanism. Only the initial SOAP sender Web Services helps us in addressinand ultimate SOAP receiver are secured. implementation challenges discusseIntermediary nodes are not secured. Thetwo most common means are securesocket layer (SSL) or HTTPS.

b. Message Level Security (MLS). In this The analysis of the gaps of sotfcan ~ .bescrdtruhu Web Services (WS) and stud,mean, message can be secured throughoutmean,~~ ~messag characteristics and best practic

the whole SOAP message path. Standardssuch as XML EncryptionO, XML complement each other. This forms

SignatureO, XML Key ManagementO, the existing agile software methodolWS-SecurityO, SAML[9], etc. can be best practices (WSBP).applied to secure the XML message and Our major effort is to go throuitasks defined for each phase of thec. Infrastructural Level Security. In this analyzing howth Services bemean it everges n th secrity analyzing how the Web Services be,mean, it leverages on the security Tepae dniidt esi

mechanism provided by Web Services implementation lifecycle are:rshosting platform. design, implementation, test, a]

WSBP1O. Web Services Implementation following sub-sections describe theTechnology and Platform. What is the discussed earliertechnology platform, such as J2EE or NET based,to be used? What kind of application server is A. Requirements Phaserequired to host services? The understanding theselead to better services interoperability. The objective of this phase is to t

WSBP1 1. Industry Standard Conformance. The requirements and translating them iconformance of industry standard, such as terms of the features, the functiofRosettaNetTmO and ebXMLO provided by the requirements, and the WS consservice determines the type of services. As it gives provides a guideline for identirise to the consideration of the requirement for categorizing the needs into Webwell-formed XML document and document-styled required for the respective Web Se]Web Service for the service. models for the respective Web Servi

338 2006 IEEE International Conference on Industrial Informatics

cftware Component.is identifiable using

or (URL). To knowle, an invocation test to)rovide the availability

Needs. Web Servicesmeet certain businesshe considering factorscomponents, integrated disparate islands of

business-to-businessn partners to facilitatederstanding the basicr drive ofWeb Servicesippropriately.,ayering Architecture.^archical abstraction fordecoupling relationship;tes layered hierarchyuping of functionalitycific application (upper)lication (middle layer),Lent-specific application

-vices (i.e. the dos anded on the characteristicsing the best practices ofig the SOA design andd earlier.

DLOGY

tware methodology forIy of Web Serviceswes discussed earlier,our basis of extendinglogy with Web Services

gh every activities ande software lifecycle byst practices could fit in.able for Web Serviceequirements, analysis,[nd deployment. Theconsideration ofWSBP

understand the businessinto WS requirement innal and non-functionalstraint. The WSBP13ifying Web Services,Services. The featuresrvices. Define use caseices.

B. Analysis Phases

The objective of this phase is to refine the requirementsfurther and translate the requirements into conceptualmodels. Architecting analysis is done to define high-levelstructure and identify the Web Services interfaces contracts.The WSBP1, WSBP2, WSBP5, WSBP6, WSBP1O andWSBP11 provide analysis guidelines for the followingactivities:

* Analyzing the granularity of Web Services interfacecontracts.

* Selecting technology platform for implementationframework.

* Defining Web Services candidate architecture.Identify architectural components to be exposed asWSs and specify major information exchanged withclient.

C. Design Phase

The objective of this phase is to do detail design of WebService. In this phase, the WS interface is refined further.The interaction of between the service and the client, e.g.asynchronous/synchronous or rpc/document is considered.The Web Services best practices for WSBP1, WSBP2,WSBP3, WSBP5, WSBP6, WSBP7 and WSBP14 areconsidered.

D. Implementation Phase

The objective of this phase is to do the actual coding ofWeb Services. The wrapping of components APIs to WebServices interface is done. The generations of WSDL andWS test client are produced. The WS will be deployed to thetarget application server. The WS best practices for WSBP1to WSBP1 1 provide the guidelines for the implementationof Web Services.

E. Testing Phase

The objective of this phase is to conduct a complete testfor Web Services including functional and non-functionalrequirements. The WS best practices for WSBP1 toWSBP1 1 provide guidelines for the testing of WebServices.

F. Deployment Phase

The objective of this phase is to ensure Web Service isproperly deployed to the targeted application server. Tovalidate proper deployment of WS, the server specific WSclient is used to conduct the deployment.From WSBP1, the user would specify ifthe publishing of

their web services is required for internal organisation, orextended to their trading partners or external used. Thisleads to the decision whether to have a private or publicservice registry to serve their company's needs. If there is aneed to publish to a service registry, then activity forgathering additional information for registry publishing is

considered for the phase.Figure 5 depicts the overview of the extended software

methodology lifecycle that has incorporation Web Servicesbest practices in different phases of the lifecycle.

Requirements Analysis and Design Implementation Testing Deployment

Extended Software Development Lifecycle

Fig. 6 Extended Methodology

VI. FWSI WEB SERVICES IMPLEMENTATIONMETHODOLOGY

The outcome ofthis research study is the key contributionto the OASIS FWSI TC Implementation MethodologySub-Committee (IMSC) for Web Services ImplementationMethodology (WSIM) guidelines [13].

The purpose of FWSI TC is to facilitate implementationof robust Web Services by defining a practical andextensible methodology consisting of implementationprocesses and common functional elements thatpractitioners can adopt to create high quality Web Servicessystems without re-inventing them for each implementationby defining only the Web Services-specifics activities spansacross software development lifecycle.The methodology itself is iterative and incremental. The

Web Service would go through all the phases therebydeveloping and refining the Web Services throughout theproject lifecycle per iteration. As compared with the normalstructured methodology and agile software methodology,the WSIM has an extra deployment phase after the Testingphase. This phase is specific to Web Services as thedeveloped services need to be deployed and hosted in atargeted application server that provides the referenceimplementation for Web Services Architecture [14] definedby W3C. Figure 6 outlines the FWSI WSIM Web Servicesspecific activities.

VII. CONCLUSION

Service-oriented architecture application faces a numberof challenges. The nature of SOA application is centred onsoftware components. Web Services technology facilitatesthe realization of SOA application. The investigation ofexisting agile software methodology for component-baseddevelopment is analyzed for identifying the gaps for WebServices development. The comparison study between Web

2006 IEEE International Conference on Industrial Informatics 339

Services development and the agile methodology areconducted to identify the additional steps required for WebServices development. In addition, the study of WebServices characteristics and the best practices are analyzed.The practical approach is proposed to extend the existingagile methodology with the inclusion of Web Services bestpractices to every phases of agile software lifecycle.Without reinventing a new software methodology, asystematic and practical methodology for SOA applicationdevelopment is developed. Our research team has done adetailed case study on applying the methodology mentionedto IBM-Rational RUP and extreme programming (XP).These two case study reports [20], [22] are available atOASIS FWSI IMSC. The reports show the web servicesspecific activities and tasks for RUP and XP softwaredevelopment phases respectively. The research team iscurrently conducting survey with the selected Singaporecompanies ranging from end users to IT solution providers,to validate against the WSIM based on the analysis madeWSIM.

Springer-Verlag London 2006, pp 193 - 204.[20] OASIS FWSI IMSC Web Services Implementation

Methodology - Rational Unified Process (Example)Working Draft 02, published 23rd December, 2004

[21] OASIS FWSI IMSC Web Services ImplementationMethodology - Case Example using ExtremeProgramming, published 14th August 2005

VIII. REFERENCES

[1] S.H. Kaisler Software Paradigms, John Wiley & Son,2005, pp 99- 100

[2] H. Hao "What is Service-Oriented Architecture"xml.com published 30th Sep. 2003.

[3] SOAP Version 1.2 Part 0 Primer W3CRecommendation published 24th June 2003

[4] WSDL Version 1.1 W3C Note published 15th March2001

[5] Evolution of UDDI The Stencil Group White Paperpublished I9th July 2002 at UDDI.org

[6] XML Encryption Syntax and Processing SpecificationW3C Recommendation published 10th December 2002

[7] XML Signature Syntax and Processing W3CRecommendation published 12th February 2002

[8] XML Key Management Specification v2.0 W3CRecommendation published 28th June 2005

[9] Technical Overview of the OASIS Security AssertionMarkup Language (SAML) Version 1.1 CommitteeDraft published 11th May 2004

[10] Web Services Security: SOAP Message Security 1.1OASIS Standard Specification published 1st February2006

[11] Agile Software Construction John Hunt Springer[12] IBM RUP Training Course Materials[13] OASIS Framework for Web Services Implementation

Technical Committee FWSI[14] Web Services Architecture W3C Working Group Note

published 11th February 2004[15] OASIS FWSI IMSC version 1.0 guidelines[16] Deciphering RosettaNetTM WebMethods Whitepaper

published April 2000.[17] ebXML Technical Architecture Specification version

1.04 published 16th February 2001[18] A.S. Koch, Agile Software Development Evaluating

the Methods for Your Organisation Artech House,2005

[19] John Hunt, Agile Software Construction,

2006 IEEE International Conference on Industrial Informatics340