OASIS FWSI Web Service Implementation Methodology

fwsi-im-1.0-guidlines-doc-wd-publicReviewDraft.doc 6 July 2005Copyright © OASIS Open 2005. All Rights Reserved. of 36

1

Web Service Implementation2

Methodology3

Public Review Draft, 6 July 20054

Document identifier:5fwsi-im-1.0-guidelines-doc-wd-01b.doc6

Location:7http://www.oasis-open.org/committees/documents.php?wg_abbrev=fwsi8

Editors:9Eng Wah LEE, Singapore Institute of Manufacturing Technology10<[email protected]>11

12

Contributors:13Marc HAINES, individual <[email protected]>14Lai Peng CHAN, Singapore Institute of Manufacturing Technology15<[email protected]>16Chai Hong ANG, Singapore Institute of Manufacturing Technology17<[email protected]>18Puay Siew TAN, Singapore Institute of Manufacturing Technology19<[email protected]>20Han Boon LEE, Singapore Institute of Manufacturing Technology21<[email protected]>22Yushi CHENG, Singapore Institute of Manufacturing Technology23<[email protected]>24Xingjian XU, Singapore Institute of Manufacturing Technology25<[email protected]>26Zunliang YIN, Singapore Institute of Manufacturing Technology27<[email protected]>28

29

Abstract:30This document specifies Web Service specific activities in a Web Service31Implementation Methodology and illustrates the approach to incorporate these32activities into an existing agile software development methodology.33

Status:34This document is updated periodically on no particular schedule. Send comments to35the editor.36Committee members should send comments on this specification to the [email protected] list. Others should subscribe to and send comments to38the [email protected] list. To subscribe, send an email message [email protected] with the word "subscribe" as the body of40the message.41For information on whether any patents have been disclosed that may be essential to42implementing this specification, and any offers of patent licensing terms, please refer43to the Intellectual Property Rights section of the FWSI TC web page44(http://www.oasis-open.org/committees/fwsi/).45

http://www.oasis-open.org/committees/documents.php?wg_abbrev=fwsi/

mailto:[email protected]













http://www.oasis-open.org/committees/fwsi/


Table of Contents46

1 Introduction ....................................................................................................................... 847

1.1 Purpose ........................................................................................................................... 848

1.2 Target Audience.............................................................................................................. 849

1.3 Scope .............................................................................................................................. 850

1.3.1 Not in Scope ............................................................................................................ 851

2 Implementation Methodology Overview.......................................................................... 1052

2.1 Objective ....................................................................................................................... 1053

2.2 Web Service Implementation Lifecycle ......................................................................... 1054

2.3 Phase ............................................................................................................................ 1055

2.3.1 Requirements Phase ............................................................................................. 1156

2.3.2 Analysis Phase ...................................................................................................... 1157

2.3.3 Design Phase......................................................................................................... 1258

2.3.4 Coding Phase ........................................................................................................ 1259

2.3.5 Test Phase............................................................................................................. 1260

2.3.6 Deployment Phase................................................................................................. 1261

2.4 Role ............................................................................................................................... 1362

2.5 Glossary ........................................................................................................................ 1363

3 Web Service Implementation Methodology .................................................................... 1464

3.1 Overview ....................................................................................................................... 1565

3.2 Requirements Phase..................................................................................................... 1666

3.2.1 Activity: Determine the need for Web Service ....................................................... 16673.2.1.1 Tasks ............................................................................................................................16683.2.1.2 Roles ............................................................................................................................16693.2.1.3 Artifacts.........................................................................................................................1670

3.2.2 Activity: Elicit Web Service requirements .............................................................. 16713.2.2.1 Tasks ............................................................................................................................16723.2.2.2 Roles ............................................................................................................................16733.2.2.3 Artifacts.........................................................................................................................1674

3.2.3 Activity: Manage the Web Service requirements................................................... 17753.2.3.1 Tasks ............................................................................................................................17763.2.3.2 Roles ............................................................................................................................17773.2.3.3 Artifacts.........................................................................................................................1778

3.2.4 Activity: Model the usage scenarios ...................................................................... 17793.2.4.1 Tasks ............................................................................................................................17803.2.4.2 Roles ............................................................................................................................17813.2.4.3 Artifacts.........................................................................................................................1782

3.2.5 Activity: Prepare Test Cases for User Acceptance Test (UAT) and System Test. 1783


3.2.5.1 Tasks ............................................................................................................................17843.2.5.2 Roles ............................................................................................................................18853.2.5.3 Artifacts.........................................................................................................................1886

3.3 Analysis Phase.............................................................................................................. 1887

3.3.1 Activity: Select a technology platform as implementation framework.................... 18883.3.1.1 Tasks ............................................................................................................................18893.3.1.2 Roles ............................................................................................................................19903.3.1.3 Artifacts.........................................................................................................................1991

3.3.2 Activity: Define a candidate architecture for the Web Service............................... 19923.3.2.1 Tasks ............................................................................................................................19933.3.2.2 Roles ............................................................................................................................19943.3.2.3 Artifacts.........................................................................................................................1995

3.3.3 Activity: Decide on the granularity of the Web Service.......................................... 19963.3.3.1 Tasks ............................................................................................................................19973.3.3.2 Roles ............................................................................................................................20983.3.3.3 Artifacts.........................................................................................................................2099

3.3.4 Activity: Identify reusable Web Services................................................................ 20100


3.3.5 Activity: Identify service interface for new Web Services ...................................... 20104


3.3.6 Activity: Prepare Test Cases for Performance Test .............................................. 21108

3.3.6.1 Task..............................................................................................................................211093.3.6.2 Roles ............................................................................................................................211103.3.6.3 Artifacts.........................................................................................................................21111

3.3.7 Activity: Prepare Test Cases for Integration / Interoperability Test ....................... 21112


3.3.8 Activity: Prepare Test Cases for Functional Test .................................................. 211163.3.8.1 Task..............................................................................................................................211173.3.8.2 Roles ............................................................................................................................211183.3.8.3 Artifacts.........................................................................................................................21119

3.3.9 Activity: Testbed preparation ................................................................................. 211203.3.9.1 Task..............................................................................................................................211213.3.9.2 Roles ............................................................................................................................221223.3.9.3 Artifacts.........................................................................................................................22123

3.4 Design Phase................................................................................................................ 23124

3.4.1 Activity: Transform signatures of reusable Web Services ..................................... 23125



3.4.2 Activity: Refine service interface of the new Web Service..................................... 23129


3.4.3 Activity: Design Web Service................................................................................. 24133


3.4.4 Activity: Refine Test Cases for Functional Test..................................................... 24137


3.5 Coding Phase................................................................................................................ 25141

3.5.1 Activity: Construct Web Service code.................................................................... 25142


3.5.2 Activity: Construct Web Service client code .......................................................... 25146


3.5.3 Activity: Unit Test Web Service.............................................................................. 26150


3.6 Test Phase .................................................................................................................... 26154

3.6.1 Activity: Test functionality of Web Service............................................................. 27155


3.6.2 Activity: Integration Test on the Web Service........................................................ 28159


3.6.3 Activity: System Test on the Web Service............................................................. 28163


3.6.4 Activity: User Acceptance Test on the Web Service ............................................. 28167



3.7 Deployment Phase........................................................................................................ 30171

3.7.1 Activity: Prepare deployment environment ............................................................ 301723.7.1.1 Tasks ............................................................................................................................301733.7.1.2 Roles ............................................................................................................................301743.7.1.3 Artifacts.........................................................................................................................30175

3.7.2 Activity: Deploy Web Service................................................................................. 301763.7.2.1 Tasks ............................................................................................................................301773.7.2.2 Roles ............................................................................................................................311783.7.2.3 Artifacts.........................................................................................................................31179

3.7.3 Activity: Test deployment....................................................................................... 311803.7.3.1 Tasks ............................................................................................................................311813.7.3.2 Roles ............................................................................................................................311823.7.3.3 Artifacts.........................................................................................................................31183

3.7.4 Activity: Create end user support material............................................................. 31184


3.7.5 Activity: Publish Web Service ................................................................................ 32188


4 References...................................................................................................................... 33192

Appendix A. Acknowledgments ............................................................................................... 34193

Appendix B. Revision History .................................................................................................. 35194

Appendix C. Notices ................................................................................................................ 36195196


List of Figures197

Figure 1: Web Service Implementation Lifecycle .................................................................... 11198Figure 2: The “V” Model incorporates the Web Services specific Interoperability test............ 15199Figure 3: Relationship between phase, activities, tasks, roles and artifacts ........................... 16200

201


List of Tables202

Table 1: Mapping between phases and roles assigned .......................................................... 12203Table 2: Overview of activities, tasks, roles and artifacts in the Requirements Phase ........... 18204Table 3: Overview of activities, tasks, roles and artifacts in the Analysis Phase .................... 23205Table 4: Overview of activities, tasks, roles and artifacts in the Design Phase ...................... 24206Table 5: Overview of activities, tasks, roles and artifacts in the Coding Phase ...................... 26207Table 6: Overview of activities, tasks, roles and artifacts in the Test Phase .......................... 30208Table 7: Overview of activities, tasks, roles and artifacts in the Deployment Phase .............. 32209

210211


1 Introduction212

1.1 Purpose213

The purpose of this document is to define a practical and extensible Web Service214Implementation Methodology that can be used as a reference for Web Services development215and deployment. This document is a consolidation of the best practices by Web Services216practitioners and aims to improve the Web Services implementation process through the217formalization of a Web Service implementation lifecycle and defining Web Service specific218activities and artifacts.219

220This document should be used in conjunction with the Functional Elements1 specifications to221govern the approach by which the Functional Elements are implemented.222

223

1.2 Target Audience224

The target audiences are likely to be:225226

• Project Managers227This document provides a formal methodology for Web Services implementation, which228can be used for management and control.229

• Software Architects/Designers/Developers/Testers230This document identifies activities that are repeatable and which can be abide by, so as231to ensure the quality of the software produced.232

233

1.3 Scope234

This document focuses Web Service specific activities, artifacts, roles and responsibilities that235can be incorporated into an existing agile software development methodology (e.g. RUP,236Extreme Programming, Feature Driven Development etc). For a few common agile237methodologies the technical committee is preparing examples that show in detail how the238generic activities, artifacts, roles, and responsibilities described in this document can be239incorporated and used in a given methodology. These case examples are provided in240separate documents that will be published along with this document when they become241available. Currently the technical committee is preparing cases for RUP and Extreme242Programming (XP).243

244245

1.3.1 Not in Scope246

This document does not define yet another novel software development methodology.247Instead, the Web Service implementation methodology highlights important features in the248context of Web Services. The elements of the Web Service implementation methodology are249based on existing agile software methodology and extend it by incorporating Web Service250specific activities.251

252Also, it is not in the scope of this document to specifically address how each of these software253development methodologies should be tailored to incorporate Web Service specific parts.254Examples are provided only to illustrate just one possible way of tailoring a specific agile255development methodology for Web Service implementation.256

1 The Functional Elements are to be specified as components, which are to be exposed asWeb Services where appropriate.


257This document does not intend to define a new software development methodology. Instead,258the Web Service Implementation Methodology leverages on an existing agile software259methodology and extend it by incorporating the Web Services specific activities.260

261This document also does not cover the detailed description or explanation of any of the262existing agile software development methodology nor does it recommend one particular agile263software development methodology over another.264


2 Implementation Methodology Overview265

2.1 Objective266

The Web Service Implementation Methodology defines a systematic approach to Web267Service development by leveraging on an agile software development methodology and268extending that methodology by specifying the Web Services specific activities and the269corresponding roles and work-products that are produced in the process.270

271This methodology will define a set of common practices that create a method-independent272framework, which can be applied by most software teams for developing Web Service273applications.274

275276

2.2 Web Serv ice Implementation Lifecycle277

A Web Service Implementation Lifecycle refers to the phases for developing Web Services278from requirement to deployment.279

280The Web Service implementation lifecycle typically includes the following phases:281

1. Requirements Phase [see 2.3.1]2822. Analysis Phase [see 2.3.2]2833. Design Phase [see 2.3.3]2844. Coding Phase [see 2.3.4]2855. Test Phase [see 2.3.5]2866. Deployment Phase [see 2.3.6]287

288The transitions through these phases need not be a single-pass sequential process. On the289contrary, the process tends to be iterative and incremental in nature and should be agile290enough to accommodate revisions in situations where the scope cannot be completely291defined up front.292

293294

2.3 Phase295

A Phase when used in the context of a Web Service implementation lifecycle refers to the296period of time a set of related software implementation activities are carried out.297

298In general, the phases detailed in the sub-sections are identified to be pertinent in a Web299Service implementation lifecycle. These phases may overlap with each other in the course of300the implementation process as shown in Figure 1.301

302303


304

Web ServicesRequirements

Web ServicesAnalysis

Web ServicesDesign

Web ServicesCoding

Web ServicesTesting

Web ServicesDeployment

Leverage on Existing

Agile Software

Development MethodologyIteration 1 .. n

Web ServicesRequirements

Web ServicesAnalysis

Web ServicesDesign

Web ServicesCoding

Web ServicesTesting

Web ServicesDeployment

Leverage on Existing

Agile Software

Development MethodologyIteration 1 .. n

305306

Figure 1: Web Service Implementation Lifecycle307

308309

2.3.1 Requirements Phase310

The objective in the requirements phase is to understand the business requirements and311translating them to Web Service requirements in terms of the features, the functional and non-312functional requirements, and the constraints within which the Web Service has to abide.313

314Requirements elicitation should be done by the requirements analyst and should involve the315project stakeholders such as the project champion, customers, end users, etc. Following316which, the analyst should interpret, consolidate and communicate these requirements to the317development team.318

319If possible, Requirements should be aggregated in a centralized repository where they can be320viewed, prioritized, and “mined” for iterative features. In all cases, enabling the team to easily321capture requirements, search, prioritize and elaborate as necessary is the primary function of322the repository.323

324

2.3.2 Analysis Phase325

In the analysis phase, the requirements of the Web Service are further refined and translated326into conceptual models by which the technical development team can understand. It is also in327this phase that an architecture analysis is done to define the high-level structure and identify328the Web Service interface contracts. This process should be performed by both the329requirements analyst and the architect and communicated to the design and development330teams.331

332


2.3.3 Design Phase333

The detailed design of Web Services is done in this phase. In this phase, the designers334should define the Web Service interface contract that has been identified in the analysis335phase. The defined Web Service interface contract should identify the elements and the336corresponding data types (possibly using a XML schema) as well as mode of interaction337between the Web Service and the client, for example, whether it should be338synchronous/asynchronous or RPC/Document style etc.339

340

2.3.4 Coding Phase341

The coding and debugging phase for Web Service implementation is essentially quite similar342to other software component-based coding and debugging phase. The main difference lies in343the creation of additional Web Service interface wrappers (to expose the components’ public344APIs), generation of WSDLs and client stubs. Web Services in addition have to be deployed345to a Web Server/Application Server before the test clients can consume them.346

347The component developer and/or the tester should perform these activities.348

349

2.3.5 Test Phase350

For testing of Web Services, besides testing for functional correctness and completeness,351testers should also perform interoperability testing between different platforms and clients‘352programs. Furthermore, performance testing has to be conducted to ensure that the Web353Services are able to withstand the maximum load and stress as specified in the non-functional354requirements specification. Other tasks like profiling of the Web Service application and355inspection of SOAP messages should also be done in this phase.356

357

2.3.6 Deployment Phase358

The purpose of the deployment phase is to ensure that the Web Service is properly deployed.359The phase will be executed after the service has been tested. The deployment of the Web360Service is platform specific. The service end points of the Web Service specifies where the361service is deployed and it needs to be identified and configured accordingly. The deployer362primary tasks are to ensure that the Web Service has been properly configured and managed363(e.g. version controlled, presetting of configuration files, packaged and loaded in the correct364location etc.) and running post-deployment tests to ensure that the Web Service is indeed365ready for use. Other optional tasks like specifying and registering the Web Service with an366UDDI registry may also be performed in this phase.367

368Table 1 summaries the overview of each phase against its’ respective assigned roles.369

370Phases Primary RolesRequirements Requirements AnalystsAnalysis Requirements Analysts

ArchitectsDesign DesignersCoding Developers

TestersTest TestersDeployment Deployers

371

Table 1: Mapping between phases and roles assigned372

373


2.4 Role374

Commonly defined roles in software development methodology include the following:375376

Roles ResponsibilitiesRequirements Analyst Responsible for eliciting and interpreting the stakeholders’ needs,

and communicating those needs to the entire team.Architect Responsible for the software architecture, which includes the key

technical decisions that constrain the overall design andimplementation for the project.

Designer Responsible for designing a part of the system, within theconstraints of the requirements, architecture, and developmentprocess for the project.

Developer Responsible for developing and unit testing the components, inaccordance with the project's adopted standards.

Deployer Responsible for planning the product's transition to the usercommunity, ensuring those plans are enacted appropriately,managing issues and monitoring progress.

Stakeholder Responsible for providing the domain expertise and specifying thesystem requirements. Stakeholder usually includes the projectchampion and the end users.

Project Manager Responsible for managing and monitoring the project including theproject scope, schedule and staffing of the project team.

Test Manager Responsible for the total test efforts including the quality and testadvocacy, resource planning and management of the testingschedule, and resolution of issues that impede the test effort.

Test Designer Responsible for defining the test approach and ensuring itssuccessful implementation. The role involves identifying theappropriate techniques, tools and guidelines to implement therequired tests, and to give guidance on the corresponding resourcesrequirements for the test effort. The role also involves monitoringdetailed testing progress and results in each test cycle andevaluating the overall quality as a result of testing activities.

Tester Responsible for the core activities of the test effort, which involvesconducting the necessary tests and logging the outcomes of thattesting.

System Administrator Responsible for planning, installing and maintaining the hardwareand software of the different environments e.g. development, test,live environment

377378

2.5 Glossary379

380Activity An Activity refers to a unit of work a role may be assigned to perform.

Activities are performed within each of the phases in the Web Serviceimplementation lifecycle.

Artifact An Artifact refers to the work-product that is used or produced as a resultof performing an activity. Examples of Artifacts include models, sourcefiles, scripts, and binary executable files.

Role A Role refers to the responsibilities that a person or a team has beenassigned with.

381


3 Web Service Implementation Methodology382

The term Web Service describes a specialized type of software, which is designed to support383a standardized way for provision and consumption of services over the Web, through the384compliance with open standards such as eXtensible Markup Language (XML), SOAP, Web385Services Description Language (WSDL) and Universal Description, Discovery and Integration386(UDDI).387

388Web Services, unlike traditional client/server systems, such as browser/Web server systems,389are not meant for direct end-user consumption. Rather, Web Services are pieces of business390logic, which have programmatic interfaces and it is through these interfaces that developers391can create new application systems.392

393The motivation behind Web Services is to facilitate businesses to interact and integrate with394other businesses and clients, without having to go through lengthy integration design and/or395to expose its confidential internal application details unnecessarily. This is made possible by396leveraging on the non-platform dependent and non-programming language dependent XML to397describe the data to be exchanged between businesses or between the business and its398clients, using a WSDL to specify what the service is providing; using a UDDI to publish and399locate who is providing the service; and typically using SOAP over HTTP to transfer the400message across the internet2.401

402A Web Service, naturally, is a software element, but because of its specialized interface and403mechanism to interoperate with others, all the prevalent generic software development404methodology would need to be tailored to handle the unique features of Web Service. This405could translate to identification of Web Service specific requirements (e.g. conformance to406Web Services standards), analysis of the specific implications of Web Service on the overall407system, design of the Web Service interface and XML message structure, coding, testing,408deployment and execution of the Web Service.409

410The Web Service Implementation Methodology that we define is to promote a systematic411approach to Web Service development. Rather than defining a new software development412methodology and expecting software practitioners to forget their own familiar and established413methodology to re-learn another, the better alternative is to leverage on what is already414available and customize that methodology to incorporate the specifics of Web Services.415

416The candidate software development methodology should, ideally, be agile and able to417accommodate refinement throughout the development cycle in an iterative and incremental418approach. The methodology should consist of phases that cover from the conception of the419need of the Web Service, to the construction of the Web Service and finally to be deployed for420use by the eventual client application. In this document, these phases are identified as421requirements, analysis, design, code, test and deployment.422

423The Web Service Implementation Methodology would leverage on any of the candidate agile424software development methodology and extend the said methodology by specifying additional425and/or customized Web Service specific activities and its corresponding roles and work-426products.427

428The Web Service Implementation Methodology is iterative and incremental. In each iteration,429the Web Service would go through all the phases (i.e. requirements, analysis, design, code,430testing and finally deployment), thereby developing and refining the Web Services throughout431the project lifecycle.432

433

2 SOAP is transport agnostic. Therefore, other Internet (e.g. SMTP) or non-Internet (IBM MQSeries) may be used. From a practical perspective, however, SOAP over HTTP appears tobe the typical scenario.


In addition, for Web Service testing, a multitude of tests have to be conducted to ensure that434the Web Service is developed according to its functional as well as non-functional435requirements. Figure 2 illustrates using the “V” Model to perform these tests.436

437

438

439

Figure 2: The “V” Model incorporates the Web Services specific Interoperability test440

441The specifications produced in each of the development phases are sources of input to derive442the test scenarios and test cases. From these test cases, test scripts and test data are443compiled, which will be used in unit testing, functional testing, integration/interoperability444testing, system/performance testing and the final user acceptance testing.445

446

3.1 Overview447

The Web Service Implementation Lifecycle describes the phases a typical Web Service would448undergo, from the identification of the need of the Web Service to the final deployment and449usage by the end-users. The phases identified to be relevant in the Web Service450Implementation Lifecycle are: requirements, analysis, design, code, test and deployment. In451each of these phases, Web Service specific activities are carried out. These activities, as well452as the roles and responsibilities, and the artifacts will be elaborated in the subsequent sub-453sections. Figure 3 illustrates the above-mentioned relationship between phase, activities and454their respective tasks, roles and artifacts.455

456

457

Legend Development PhaseDevelopment Phase Test Phase

ArchitecturalDesign Spec

ImplementationImplementation Source Codes

RequirementsRequirements RequirementsSpec

DesignDesign Design Spec

Unit Test

User AcceptanceTest Cases / Scripts

AnalysisAnalysis

System / Performance Test

Functional Test

Integration / Interoperability Test

System / PerformanceTest Cases / Scripts

User Acceptance Test

Integration / InteroperabilityTest Cases / Scripts

Functional TestCases / Scripts

Unit TestCases / Scripts

DeploymentDeployment

TestTest

Legend Development PhaseDevelopment Phase Test Phase

ArchitecturalDesign Spec

ImplementationImplementation Source Codes

RequirementsRequirements RequirementsSpec

DesignDesign Design Spec

Unit Test

User AcceptanceTest Cases / Scripts

AnalysisAnalysis

System / Performance Test

Functional Test

Integration / Interoperability Test

System / PerformanceTest Cases / Scripts

User Acceptance Test

Integration / InteroperabilityTest Cases / Scripts

Functional TestCases / Scripts

Unit TestCases / Scripts

DeploymentDeployment

TestTest

PhasePhase

TasksTasks

ActivitiesActivities

RolesRoles ArtifactsArtifacts

PhasePhase

TasksTasks

ActivitiesActivities

RolesRoles ArtifactsArtifacts


Figure 3: Relationship between phase, activities, tasks, roles and artifacts458

3.2 Requirements Phase459

3.2.1 Activity: Determine the need for Web Service460

3.2.1.1 Tasks461

• Identify the stakeholders462Stakeholders would usually include the end users, project champion, project463manager, etc.464

465• Understand the inadequacies/problems to address466

Understand the stakeholders’ need for Web Services.467468

• Identify the need for Web Service technology469Based on the current technology available, identify needs specially for Web Services.470

471• Determine the positioning of the Web Service within the boundaries of the problem472

identified473474

• Define the features of the Web Service based on the needs list475476

• Identify the limitations to be imposed on the Web Service477

3.2.1.2 Roles478

Architect, Requirements Analyst, Stakeholders, Project Manager479

3.2.1.3 Artifacts480

The results should be recorded in Business Requirement Specifications.481482

3.2.2 Activity: E licit Web Service requirements483

3.2.2.1 Tasks484

• Identify the sources for requirements gathering based on the features list485Identify the departments, end users, domain experts, etc. who would be impacted by486the introduction of Web Services.487

488• Gather information from these sources and elicit the requirements for the Web489

Service490491

• Identify functional requirements for the Web Service and categorise them492493

• Identify non-functional requirements for the Web Service494Non-functional requirements are requirements pertaining to Usability, Reliability,495Performance, Scalability, Supportability and other design considerations.496

3.2.2.2 Roles497

Requirements Analyst, Architect, Test Manager498


The results should be recorded in Requirement Specifications.500


501

3.2.3 Activity: Manage the Web Service requirements502

3.2.3.1 Tasks503

• Based on the functional requirements categories, identify the Web Services and504establish the dependencies and priorities505

506• Create traceability matrices from the requirements to the identified Web Services507

Traceability matrices help to track the requirements that have been taken care of by508the Web Services identified.509

510• Manage changes to the requirements511

3.2.3.2 Roles512




3.2.4 Activity: Model the usage scenarios517

3.2.4.1 Tasks518

• Translate the functional requirements into conceptual usage models using some form519of analysis modeling techniques520

521• Specify the major interaction scenarios with the Web Service clients522

This is to highlight the usage of Web Services involved. Especially, the message523exchange scenarios should be captured.524

3.2.4.2 Roles525




3.2.5 Activity: P repare Test Cases for User Acceptance Test (UAT)530and System Test531

3.2.5.1 Tasks532

• Write business scenario test case(s) based on the requirements gathered to be used533for UAT and System Test534Test case(s) can be derived from requirements. This is also a way to verify the535requirements when they are implemented.536

537• Build requirement validation matrix538

The requirement validation matrix will include the requirements and a reference to the539test case(s) that will validate the requirement.540

541


• Manage changes to the test cases when requirements changed542

3.2.5.2 Roles543

Requirements Analyst, Test Manager, Test Designer544


The results should be recorded in Test Plan – UAT and System Test.546547

Table 2 summaries the overview of each activities and the corresponding tasks, roles and548artifacts under the activities.549

550Activities Tasks Roles Artifacts Determineneeds

Identify stakeholders Understand the inadequacies/problemsto address

Identify need for WS technology Determine positioning of WS within theboundaries of the problem identified

Define features of WS based on needs Identify limitations

Architect Requirements

Analyst Stakeholders Project Manager

BusinessRequirementSpecifications

Elicitrequirements

Identify sources for requirementsgathering

Gather information Identify functional requirements Identify non-functional requirements


Analyst Test Manager

RequirementSpecifications

Managerequirements

Identify WS and establish dependenciesand priorities

Create traceability matrices Manage changes to requirements




Model usagescenarios

Translate functional requirements intoconceptual usage models

Specify major interaction scenarios withWS clients




Prepare testcases for UATand SystemTest

Write business scenarios test cases Build requirement validation matrix Manage changes to test cases

RequirementsAnalyst

Test Manager Test Designer

Test Plan –UAT andSystem Test

551Notes: WS stands for Web Services552

553

Table 2: Overview of activities, tasks, roles and artifacts in the Requirements Phase554

555556

3.3 Analysis Phase557

3.3.1 Activity: Select a technology platform as implementation558framework559

3.3.1.1 Tasks560

• Specify the Web Services standards that the implementation must adhere561Identify the Web Service standards based on the requirements and implementation562constraints. Consider issues like the standards compatibility, version of standards,563standards adoption in industry sector, and the organization approving the standards.564

565• Decide the technology platform for implementing Web Services566


Choose a technology platform that is suitable for implementation. E.g. dotNet or Java567platform.568

569• Decide the technology platform for hosting Web Services570

Based on implementation constrains and considerations for standards support and571interoperability requirements, choose the appropriate hosting platform for Web572Services.573

574• Decide the IDE tools used to develop Web Services575

Available options include commercial vendor’s IDE tools, open source IDE tools.576Normally, the selection of IDE is tied together with the implementation platforms.577

3.3.1.2 Roles578

Architect579


The results should be recorded in Software Architecture Specifications.581582

3.3.2 Activity: Define a candidate architecture for the Web Service583

3.3.2.1 Tasks584

• Define a high-level architecture585586

• Identify the architectural component that expose functionality as Web Services587It is necessary to identify the architectural components that implement the wrapping588of functionality as Web Services and implement the message exchanges in the high589level architecture.590

591• Specify the major information exchange with Web Service clients592

Identify and specify the first cut definition of message that is exchanged with Web593Services clients. The definition includes the element of data, data type and format.594

3.3.2.2 Roles595

Architect596



3.3.3 Activity: Decide on the granularity of the Web Service600

3.3.3.1 Tasks601

• Decide on the coarseness of the Web Service operations to be exposed602Set up criteria on the coarseness of Web Services operations. Its definition depends603on the usage scenarios and requirements.604

605• Identify and group functionality into the Web Service606

Based on the requirements and criteria mentioned above, identify the functions that607are needed to group into the Web Services.608

609• Decide on the mechanisms to compose or aggregate functionality610


In case there is a need to compose individual Web Services, choose and decide the611mechanism to implement the compositions.612

3.3.3.2 Roles613

Architect614



3.3.4 Activity: Identify reusable Web Services618

3.3.4.1 Tasks619

• Identify the architectural components that can be realized by existing Web Services620If the functionality of the architecture component can be fulfilled with existing Web621Services (internal or third party Web Services), the architectural components should622be identified to make use of these existing Web Services.623

624• Identify the Web Service providers for the reusable Web Services625

Identify and gather the information about provider of existing Web Services.626627

• Define the major invocation scenarios of re-use628Identify the functions that are going to be used. Define the interface of invocation.629

3.3.4.2 Roles630

Architect631



3.3.5 Activity: Identify service interface for new Web Services635

3.3.5.1 Tasks636

• Define the new Web Service operation signatures637Based on the usage models and analysis models, identify the operations and its638signatures.639

640• Define XML schema for the message exchange641

If message exchanges are involved, the XML schema that guides the structure of the642message should be defined.643

3.3.5.2 Roles644

Architect, Designer645


Web Service Signature Specifications, XML schema.647648


3.3.6 Activity: P repare Test Cases for Performance Test649

3.3.6.1 Task650

• Write performance test case(s) to be used for Performance Test651Test case(s) can be derived from Architectural Design Specifications.652

653• These test cases should cover load testing scenarios to see how the system will654

perform under various loads (in terms of concurrent users/requests and/or655transactions).656

3.3.6.2 Roles657

Test System Administrator, Test Designer658


The results should be recorded in Test Plan – Performance Test.660661

3.3.7 Activity: P repare Test Cases for Integration / Interoperability662Test663

3.3.7.1 Task664

• Write integration / interoperability test case(s) to be used for Integration /665Interoperability Test666Test case(s) can be derived from Architectural Design Specifications.667

3.3.7.2 Roles668

Test Designer, Tester669


The results should be recorded in Test Plan – Integration / Interoperability Test.671672

3.3.8 Activity: P repare Test Cases for Functional Test673

3.3.8.1 Task674

• Write functional test case(s) to be used for Functional Test675Test case(s) can be derived from Architectural Design Specifications.676

3.3.8.2 Roles677



The results should be recorded in Test Plan - Functional Test.680681

3.3.9 Activity: Testbed preparation682

3.3.9.1 Task683

• Set up testing environment that include hardware and software684


685• This environment may be similar to the production/live environment in terms of686

hardware, OS, Web Server/Application Server, etc.687

3.3.9.2 Roles688

Test System Administrator, Test Designer689


The results should be recorded in Test Plan - Testbed.691692


695Activities Tasks Roles Artifacts Select a technologyplatform as implementationframework

Specify implementationstandards

Decide technologyplatform forimplementation

Decide technologyplatform for hosting

Decide IDE tools used fordevelopment

Architect SoftwareArchitectureSpecifications

Define candidatearchitecture

Define high-levelarchitecture

Identify architecturalcomponent that exposefunctionality as WS

Specify major informationexchange with WS clients


Decide granularity Decide on coarseness ofthe operations to beexposed

Identify and groupfunctionality

Decide on mechanisms tocompose or aggregatefunctionality


Identify reusable WS Identify architecturalcomponents that can berealized by existing WS

Identify WS providers forreusable WS

Define major invocationscenarios of re-use


Identify service interface Define new WS operationsignatures

Define XML schema formessage exchange

Architect Designer

WS SignatureSpecifications

XML Schema

Prepare test cases forPerformance Test

Write Performance testcases

Test SystemAdministrator

Test Designer

Test Plan –Performance Test

Prepare test cases forIntegration / InteroperabilityTest

Write Integration /Interoperability test cases

Test Designer Tester

Test Plan –Integration /InteroperabilityTest

Prepare test cases forFunctional Test

Write functional test cases Test Designer Tester

Test Plan –Functional Test

Testbed preparation Set up testingenvironment

Test SystemAdministrator

Test Designer

Test Plan -Testbed



698

Table 3: Overview of activities, tasks, roles and artifacts in the Analysis Phase699

700701

3.4 Design Ph ase702

3.4.1 Activity: T ransform signatures of reusable Web Services703

3.4.1.1 Tasks704

• Identify the data type mapping if required705If the type of a parameter of the reusable service is not directly supported by the706identified platform, data type mapping should be performed.707

708• Identify the design patterns for mapping the re-used Web Service interface to the709

identified (desired) one710Certain design patterns could be used to reuse existing Web Service(s), such as711adapter pattern, façade pattern etc. Adapter pattern could be used to expose a new712interface of an existing Web Service. The façade pattern could be used to713encapsulate the complexity of existing Web Services and provide a coarse-grained714Web Service.715

3.4.1.2 Roles716

Designer717


The results should be recorded in Design Specifications.719720

3.4.2 Activity: Refine service interface of the new Web Service721

3.4.2.1 Tasks722

• Refine Web Service interfaces signature723In the detailed design stage, the signature may be refined further. Care must be724taken to ensure that the design decision should not affect the interoperability of the725service.726

727• Refine XML schema for message exchange728

The XML schema may be refined to further expand on the data structure, data types,729namespaces etc.730

3.4.2.2 Roles731

Designer732




3.4.3 Activity: Design Web Service736

3.4.3.1 Tasks737

• Use some form of modeling techniques to describe the internal structure of the Web738Service739The design of the internal structure needs to consider the receiving and pre-740processing of request, delegating of the request, processing of the request and741sending of the response. Existing modeling techniques such as UML, design742patterns could be applied to the design.743

744• Consider non-functional requirements (e.g. usability, reliability, performance,745

scalability etc.) and design constraints (e.g. interoperability etc.)746

3.4.3.2 Roles747

Designer748



3.4.4 Activity: Refine Test Cases for Functional Test752

3.4.4.1 Task753

• Refine functional test case(s) to be used for functional Test754Test case(s) can be refined by Design Specifications.755

3.4.4.2 Roles756



The results should be recorded in Test Plan – Functional Test.759760761


764Activities Tasks Roles Artifacts Transformsignatures ofreusable WS

Identify data type mapping if required Identify design patterns for mapping there-used WS interface to the desired one

Designer DesignSpecifications

Refine serviceinterface of newWS

Refine WS interface signature Refine XML schema for messageexchange


Design WS Use modeling techniques to describeinternal structure of WS

Consider non-functional requirements anddesign constraints


Refine testcases forFunctional Test

Refine functional test cases Test Designer Tester

Test Plan –FunctionalTest


767

Table 4: Overview of activities, tasks, roles and artifacts in the Design Phase768


769770

3.5 Coding Phase771

3.5.1 Activity: Construct Web Service code772

3.5.1.1 Tasks773

• Based on the implementation language choice, code the Web Service according to774the design775Consider other constraints that are imposed by the specific implementation language776itself. For example, consider the language dependent data types and the need to777map these data types to the ones specified by the Web Service interface.778

779• Expose public APIs as Web Service interface780

For example, in Java, to create the interface class to expose the class method as a781Web Service operation or in dotNet, to annotate the class API as a [WebMethod].782

783• Generate WSDL for client to consume784

Most IDEs can auto-generate the WSDL from the interface code.785

3.5.1.2 Roles786

Developer787


Web Service Implementation Codes.789790

3.5.2 Activity: Construct Web Service client code791

3.5.2.1 Tasks792

• Decide on the Web Service Client programming model793Among the three available are:794

795a) Static Stub796The client invokes the Web Service operation through a stub. Any IDE can generate797this stub at compile time.798

799b) Dynamic Proxy800As the name implies, dynamic proxy is dynamically generated when the client801application is executed. Because dynamic proxy is generated during runtime, Web802Service invocation using this method takes the longest time amongst the three803approaches.804

805c) DII (Dynamic Invocation Interface)806It is the most flexible approach among the three programming models. The client807does not even need to know the signature of the Web Service operation until runtime.808The Web Service invocation can be dynamically constructed.809

810Hence, identify and decide on a suitable client programming model based on the811weightage of flexibility against performance requirements.812

813• Write client code to consume the Web Service814


Use the WSDL to generate client stubs, which can be used in the client code to815invoke the methods provided by the Web Service.816

3.5.2.2 Roles817

Developer818


Web Service Client Codes.820821

3.5.3 Activity: Unit Test Web Service822

3.5.3.1 Tasks823

• Deploy Web Service in local test environment and perform functional unit testing824The emphasis is on the correctness of the functionality and the exceptions handling.825

3.5.3.2 Roles826

Developer827


Unit Test Scripts.829830831


834Activities Tasks Roles Artifacts Construct WScode

Code based on implementationlanguage chosen

Expose public APIs as interface Generate WSDL for client

Developer Implementationcodes

Construct WSclient code

Decide client programming model Write client codes

Developer Client codes

Unit test Deploy in local test environment andperform functional unit testing

Developer Unit test scripts


837

Table 5: Overview of activities, tasks, roles and artifacts in the Coding Phase838

839840

3.6 Test Phas e841

For Web Services, additional tests may be conducted to ensure that the Web Services are842interoperable, secured and scalable.843

844Interoperability is an issue in Web Services because the standards governing Web Services845are still evolving. Furthermore, different vendors that implement these specifications may846interpret and comply with these specifications differently. Currently there is an effort by Web847Services Interoperability Organization (WS-I) to recommend basic profiles to minimise these848incompatibilities. The aim of conducting interoperability tests is to ensure that these849reccomendations are followed and the Web Service developed will interoperate with other850Web Services and products without problems.851

852


Network congestion created by Web Services is the major contributor to Web Services’ slow853performance. Not only is the messaging between requesters and Web Services impacted by854network latency, but also the service discovery and description protocols that precede those855message exchanges. The cumulative effect of these delays can seriously degrade the856performance of Web Services. Therefore it is necessary to do a performance test on the Web857Services before they are deployed for operation, and then to monitor the Web Services to858determine if they can meet the service level agreements.859

860Web Services introduce special security issues e.g. in privacy, message integrity,861authentication and authorization. Tests have to be conducted to ensure that these security862requirements have been fulfilled. However, security schemes could complicate the process of863testing and debugging Web Service basic functionality. For example, non-intrusive monitors864are often used in functional testing but encrypted traffic presents an obvious complication to865this approach to testing.866

867

3.6.1 Activity: Test functionality of Web Service868

3.6.1.1 Tasks869

• Testing basic Web Service functionality870The Web Service should respond correctly to requests from their clients. The format871of the SOAP message should be in compliance with the specifications. WSDL files,872which contain metadata about Web Services’ interfaces, should be in compliance with873the WSDL specifications published by W3C. Perform fault checking to see how it874handles unexpected input. The test scripts and data prepared in the earlier phases875are executed in this activity. The test results should be recorded, and bugs found876should be reported to the code owners and fixed by them.877

878• Test for security879

If a service requires a certain level of privacy, or if it requires that messages be880authenticated in a certain way, then specific tests are needed to ensure that these881security requirements are met. The test scripts and test data prepared in the earlier882phases should be executed in this activity. Any inadequacies that may lead to883possible security breaches should be reported and resolved by the code owner,884designer or architect.885

886• Test the UDDI functionality887

If a service is registered to a registry server, perform registering of Web Service, then888write test clients to perform finding and binding of Web Service on the registry, and889then use the registry data to actually invoke the service. Test results from the test890scripts and data should be recorded and bugs should be fixed by the code owners.891

892• Test for SOAP intermediary capability893

If particular SOAP message has one or more intermediaries along the message route894that take actions based upon the instructions provided to them in the header of the895SOAP message. Web Service SOAP intermediary testing must verify the proper896functionality of these intermediaries. Test results from the test scripts and data897should be recorded and bugs should be fixed by the code owners.898

3.6.1.2 Roles899

Tester, Test Designer900


The results should be recorded in Client Test Code, Test Scripts and Test Results.902903


3.6.2 Activity: In tegration Test on the Web Service904

3.6.2.1 Tasks905

• Test for conformance to Web Services Interoperability Organization (WS-I)906recommendations. Execute test scripts and data according to the test cases based907on the WS-I recommendations.908

909• Perform interoperability testing based on various scenarios910

This is to highlight the interoperability issues of Web Services implementation. Refer911to Interoperability Guideline for the interoperability testing scenarios.912

913• Perform integration testing based on various scenarios914

Based on the test cases prepared in the Analysis Phase, test scripts and test data,915which are prepared are executed and analyzed in this activity.916

3.6.2.2 Roles917

Tester, Test Designer, Test System Administrator918



3.6.3 Activity: S ystem Test on the Web Service922

3.6.3.1 Tasks923

• Check system functionality and response time under different degrees of load924increases925The test cases that are prepared in the earlier phases are executed in this activity.926The load increases can be sudden surges or gradual ramp-ups. The test results927should be analyzed to determine potential bottlenecks and if the system is scalable.928

929• Check functionality and response time under different combinations of valid and930

invalid requests931The results from the test execution should be analyzed to determine if the system can932still render the expected quality of service as specified in the non-functional933requirement specifications.934

3.6.3.2 Roles935

Tester, Test Designer, Test System Administrator936



3.6.4 Activity: User Acceptance Test on the Web Service940

3.6.4.1 Tasks941

• Run the user acceptance test cases(s) for the Web Services system942The test cases prepared in the Requirement Phase are used in this activity to validate943the correctness and completeness of the Web Service system. Any bugs found944should be reported and fixed by the code owners.945


3.6.4.2 Roles946

User, Test Manager, Test System Administrator947





953Activities Tasks Roles Artifacts Testfunctionality

Test basic WS functionality Test for security Test UDDI functionality Test for SOAP intermediary capability

Tester Test Designer

Client testcode

Test scripts Test results

Integrationtest

Test for conformance to WS-I Perform interoperability test based onvarious scenarios

Perform integration test based onvarious scenarios

Tester Test Designer Test System

Administrator

Client testcode


System test Check system functionality andresponse time under different degreesof load increases

Check functionality and response timeunder different combinations of validand invalid requests

Tester Test Designer Test System

Administrator

Client testcode


Useracceptancetest

Run UAT test cases User Test Manager Test System

Administrator

Client testcode



956

Table 6: Overview of activities, tasks, roles and artifacts in the Test Phase957

958959

3.7 Deployme nt Phase960

3.7.1 Activity: P repare deployment environment961

3.7.1.1 Tasks962

• Set up and configure the hardware for Web Service deployment963964

• Set up and configure the software for Web Service deployment965The software may include application server, database, etc. The application server966should have a SOAP listener to support Web Services. Some Web Services may967need the SOAP handler to be configured.968

3.7.1.2 Roles969

System Engineer970


Release Notes.972973

3.7.2 Activity: Deploy Web Service974

3.7.2.1 Tasks975

• Determine service URL976Web Service URL is unique and used to identify the Web Service and where it is977located.978


979• Prepare the deployment script980

Deployment script is used to determine the steps of deployment. Although it is981different for different application server, most of them will include creation of directory,982copying files, shutting down and restarting the server.983

984• Deploy the Web Service985

Execute the prepared deployment script.986987

• Generate WSDL file988After successfully deploying the Web Service, a WSDL file is needed to describe the989functions provided by the Web Service. WSDL can be created manually or by most990application servers, which will automatically generate the WSDL file after deployment.991

3.7.2.2 Roles992

Developer993


WSDL File, Deployment Script.995996

3.7.3 Activity: Test deployment997

3.7.3.1 Tasks998

• Create (reuse) Web Service client code999The Web Service client code should be created by the developer during code and1000debug phase.1001

1002• Consume Web Service with the client code1003

Because the functionality of the Web Service is properly tested, there is no need to1004test all the operations. To make sure the Web Service is properly deployed and1005configured, the best candidates of operations for invocation are the ones needed for1006database connection, configuration of SOAP handler or any other special features of1007the application server.1008

3.7.3.2 Roles1009

Tester1010


Web Service Client Codes.10121013

3.7.4 Activity: C reate end user support material1014

3.7.4.1 Tasks1015

• Create end user support material1016The support material is needed to help the users to understand and use the Web1017Service. For example, an interoperability guide of the Web Service.1018

3.7.4.2 Roles1019

Developer1020



Interoperability Guide, User Guide, On-line Help, Tutorials and Training Material.10221023

3.7.5 Activity: Publish Web Service1024

3.7.5.1 Tasks1025

• Identify the UDDI registry for publishing the Web Service1026Based on the requirements, decide whether a private or public UDDI registry is1027needed and the version of the UDDI Business Registry specifications to follow.1028

1029• Prepare the information needed for publishing1030

The information may include key words for searching, description of Web Service,1031URL of WSDL file, etc.1032

1033• Publish the Web Service in the UDDI registry1034

Normally, the UDDI registry will support the publishing via browser.10351036

• Search the Web Service by key words after publishing1037Search the Web Service through browser provided by UDDI registry or tools provided1038by other vendors.1039

3.7.5.2 Roles1040

Developer1041


None.10431044


1047Activities Tasks Roles Artifacts Preparedeploymentenvironment

Set up and configure hardware Set up and configure software

SystemEngineer

Release Notes

Deploy WS Determine service URL Prepare deployment script Deploy WS Generate WSDL

Developer WSDL file Deployment script

Testdeployment

Create (reuse) client code Consume WS with client code

Tester Client codes

Create enduser supportmaterial

Create support material Developer Interoperabilityguide

User guide On-line help Tutorials Training material

Publish WS Identify UDDI registry for publishing Prepare information for publishing Publish in UDDI registry Search by key words after publishing

Developer --


1050

Table 7: Overview of activities, tasks, roles and artifacts in the Deployment Phase1051

10521053


4 References1054

1. “Rational Unified Process”, Version 2003.06.00.65, IBM-Rational Software.10551056

2. “Rational Unified Process for Developing Web Services”, Version 1.0, Java Smart1057Services Laboratory and Rational Software Pte. Ltd., Aug 2003.1058


Appendix A. Acknowledgments1059

The following individuals were members of the committee during the development of this1060documentation:1061• Ravi Shankar, CrimsonLogic Pte. Ltd.1062

• Jagdip Talla, CrimsonLogic Pte. Ltd.1063

• Andy Tan, Individual1064

• Roberto Pascual, The Infocomm Development Authority of Singapore1065

1066


Appendix B. Revision History1067

Rev Date By Whom Whatwd-01 2004-09-30 Lai Peng CHAN

Chai Hong ANGInitial version

- 2004-12-23 Chai Hong ANG Split the document into twowd-01a 2005-05-24 Chai Hong ANG

Puay Siew TANHan Boon LEE

Remover Section 2.1 Terminology,Section 2.2 Concepts and Section2.2.1 Web Service and combinedthem as Section 2.1 Objective

Renumber Section 2.2.2 to Section2.2

Renumber Section 2.2.3 to 2.3. Therest of the sub-sections arerenumbered accordingly

Added Table 1 as summary forphase and its assigned roles

Section 2.2.4 Activity and Section2.2.6 Artifact are moved into Section2.5 Glossary

Renumber Section 2.2.5 to 2.5 andput them into table format

Section 3 is renamed as WebService Implementation Methodology

Removed Section 3.1 Renumber Section 3.1.1 to 3.1 Renumber Section 3.1.2 to 3.2. The

rest of the sub-sections arerenumbered accordingly

Tables are added into each phasefor summary

Removed Normative and Non-Normative from Section 4

wd-01b 2005-06-02 Chai Hong ANGProf. Marc Haines

Edited based on Prof. Haines’comments

1068


Appendix C. Notices1069

OASIS takes no position regarding the validity or scope of any intellectual property or other1070rights that might be claimed to pertain to the implementation or use of the technology1071described in this document or the extent to which any license under such rights might or might1072not be available; neither does it represent that it has made any effort to identify any such1073rights. Information on OASIS's procedures with respect to rights in OASIS specifications can1074be found at the OASIS website. Copies of claims of rights made available for publication and1075any assurances of licenses to be made available, or the result of an attempt made to obtain a1076general license or permission for the use of such proprietary rights by implementors or users1077of this specification, can be obtained from the OASIS Executive Director.1078

OASIS invites any interested party to bring to its attention any copyrights, patents or patent1079applications, or other proprietary rights which may cover technology that may be required to1080implement this specification. Please address the information to the OASIS Executive Director.1081

Copyright © OASIS Open 2005. All Rights Reserved.1082

This document and translations of it may be copied and furnished to others, and derivative1083works that comment on or otherwise explain it or assist in its implementation may be1084prepared, copied, published and distributed, in whole or in part, without restriction of any kind,1085provided that the above copyright notice and this paragraph are included on all such copies1086and derivative works. However, this document itself does not be modified in any way, such as1087by removing the copyright notice or references to OASIS, except as needed for the purpose1088of developing OASIS specifications, in which case the procedures for copyrights defined in1089the OASIS Intellectual Property Rights document must be followed, or as required to translate1090it into languages other than English.1091

The limited permissions granted above are perpetual and will not be revoked by OASIS or its1092successors or assigns.1093

This document and the information contained herein is provided on an “AS IS” basis and1094OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT1095LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL1096NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY1097OR FITNESS FOR A PARTICULAR PURPOSE.1098

1099

OASIS FWSI Web Service Implementation Methodology

Documents

Transcript of OASIS FWSI Web Service Implementation Methodology