What Are The Steps Involved In Defining And Using A Web Service?

Web Service Implementation Methodology

Public Review Typhoon, half dozen July 2005

Document identifier:

fwsi-im-one.0-guidelines-doc-wd-01b.doc

Location:

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

Editors:

Eng Wah LEE, Singapore Plant of Manufacturing Engineering science

<ewlee@SIMTech.a-star.edu.sg>

Contributors:

Marc HAINES, private <mhaines@uwm.edu>

Lai Peng CHAN, Singapore Found of Manufacturing Technology

<lpchan@SIMTech.a-star.edu.sg>

Chai Hong ANG, Singapore Institute of Manufacturing Technology

<chang@SIMTech.a-star.edu.sg>

Puay Siew TAN, Singapore Constitute of Manufacturing Technology

<pstan@SIMTech.a-star.edu.sg>

Han Boon LEE, Singapore Institute of Manufacturing Applied science

<hblee@SIMTech.a-star.edu.sg>

Yushi CHENG, Singapore Institute of Manufacturing Technology

<ycheng@SIMTech.a-star.edu.sg>

Xingjian XU, Singapore Institute of Manufacturing Applied science

<xjxu@SIMTech.a-star.edu.sg>

Zunliang YIN, Singapore Constitute of Manufacturing Technology

<zlyin@SIMTech.a-star.edu.sg>

Abstruse:

This document specifies Web Service specific activities in a Web Service Implementation Methodology and illustrates the approach to comprise these activities into an existing agile software development methodology.

Status:

This certificate is updated periodically on no particular schedule.� Send comments to the editor.

Committee members should send comments on this specification to the fwsi-imsc@lists.oasis-open.org list.� Others should subscribe to and send comments to the fwsi-annotate@lists.oasis-open up.org list.� To subscribe, send an electronic mail bulletin to fwsi-comment-request@lists.haven-open.org with the word "subscribe" as the torso of the bulletin.

For information on whether whatever patents have been disclosed that may exist essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights department of the FWSI TC web page (http://www.oasis-open.org/committees/fwsi/).

Table of Contents

1 �� Introduction . 8

1.1 Purpose . 8

1.2 Target Audience . eight

1.3 Scope . 8

1.three.1 Not in Scope . 8

2 �� Implementation Methodology Overview . 10

2.1 Objective . 10

ii.2 Spider web Service Implementation Lifecycle . 10

2.three Phase . ten

2.3.ane Requirements Phase . 11

2.three.2 Assay Phase . eleven

2.3.iii Design Stage . 12

2.3.4 Coding Phase . 12

2.3.five Exam Phase . 12

2.3.6 Deployment Phase . 12

2.iv Role . 13

2.5 Glossary . thirteen

3 �� Web Service Implementation Methodology . 14

three.1 Overview . 15

3.2 Requirements Stage . 16

3.2.one Action: Determine the need for Web Service . 16

3.ii.one.i Tasks . 16

3.2.i.2 Roles . 16

iii.ii.1.3 Artifacts . sixteen

three.two.ii Activity: Elicit Web Service requirements . sixteen

3.2.ii.1 Tasks . sixteen

3.2.2.2 Roles . 16

3.2.2.3 Artifacts . 16

3.2.3 Activity: Manage the Spider web Service requirements . 17

three.2.3.1 Tasks . 17

3.ii.3.ii Roles . 17

three.2.3.3 Artifacts . 17

3.2.4 Activity: Model the usage scenarios . 17

three.2.iv.1 Tasks . 17

3.2.4.2 Roles . 17

3.two.4.iii Artifacts . 17

3.two.v Action: Set up Examination Cases for User Acceptance Test (UAT) and System Test 17

three.2.5.ane Tasks . 17

3.2.v.2 Roles . xviii

3.2.v.three Artifacts . eighteen

3.three Assay Phase . 18

3.three.1 Action: Select a engineering science platform as implementation framework . eighteen

iii.3.1.ane Tasks . xviii

3.3.i.two Roles . nineteen

3.3.1.3 Artifacts . 19

iii.3.2 Activeness: Define a candidate architecture for the Web Service . 19

iii.3.2.i Tasks . 19

three.three.ii.2 Roles . xix

3.3.2.iii Artifacts . 19

3.3.3 Activity: Decide on the granularity of the Web Service . 19

three.iii.3.1 Tasks . 19

3.three.3.2 Roles . 19

3.3.three.iii Artifacts . xx

three.3.iv Activity: Place reusable Web Services . 20

3.three.4.1 Tasks . 20

3.iii.4.2 Roles . 20

3.3.4.3 Artifacts . 20

3.3.5 Activeness: Identify service interface for new Spider web Services . 20

iii.iii.v.one Tasks . 20

3.iii.5.2 Roles . 20

iii.three.5.iii Artifacts . xx

iii.iii.6 Activeness: Prepare Test Cases for Functioning Test 20

three.3.6.ane Chore . 20

3.iii.6.2 Roles . 21

3.3.6.3 Artifacts . 21

3.3.seven Activity: Prepare Test Cases for Integration / Interoperability Test 21

3.3.seven.1 Task . 21

iii.iii.7.2 Roles . 21

3.iii.seven.3 Artifacts . 21

3.iii.viii Activeness: Set Examination Cases for Functional Test 21

3.3.eight.1 Task . 21

3.3.viii.2 Roles . 21

iii.3.viii.3 Artifacts . 21

three.3.nine Action: Testbed preparation . 21

3.iii.nine.i Job . 21

iii.3.9.2 Roles . 21

3.iii.9.three Artifacts . 21

3.iv Design Stage . 23

3.iv.1 Activity: Transform signatures of reusable Spider web Services . 23

3.4.1.1 Tasks . 23

3.4.1.2 Roles . 23

3.4.1.iii Artifacts . 23

iii.4.ii Activity: Refine service interface of the new Spider web Service . 23

iii.iv.2.one Tasks . 23

3.4.2.2 Roles . 23

3.4.2.3 Artifacts . 23

3.4.3 Action: Design Web Service . 23

iii.4.3.i Tasks . 23

3.4.3.ii Roles . 24

3.four.three.3 Artifacts . 24

iii.4.4 Activity: Refine Examination Cases for Functional Test 24

iii.4.4.1 Task . 24

3.four.4.2 Roles . 24

3.four.iv.3 Artifacts . 24

3.five Coding Phase . 24

3.five.1 Activity: Construct Web Service code . 24

3.5.i.1 Tasks . 24

three.five.1.two Roles . 25

3.5.1.3 Artifacts . 25

3.5.2 Activity: Construct Web Service client code . 25

3.v.2.1 Tasks . 25

3.5.2.2 Roles . 25

three.5.2.3 Artifacts . 25

three.five.3 Activeness: Unit of measurement Test Web Service . 26

3.5.3.1 Tasks . 26

3.5.3.2 Roles . 26

3.v.three.3 Artifacts . 26

3.6 Test Phase . 26

three.6.one Activity: Test functionality of Web Service . 27

iii.six.1.i Tasks . 27

three.half dozen.one.2 Roles . 27

three.half dozen.1.3 Artifacts . 27

3.6.2 Activity: Integration Examination on the Web Service . 27

iii.6.2.1 Tasks . 27

three.six.2.2 Roles . 28

3.6.2.three Artifacts . 28

iii.half dozen.3 Activeness: System Test on the Web Service . 28

iii.6.3.1 Tasks . 28

three.6.three.ii Roles . 28

iii.half dozen.3.3 Artifacts . 28

three.vi.4 Activity: User Credence Examination on the Spider web Service . 28

iii.half-dozen.iv.1 Tasks . 28

3.6.4.2 Roles . 28

3.half-dozen.iv.3 Artifacts . 28

3.7 Deployment Phase . 29

3.7.1 Activeness: Prepare deployment environment 29

3.7.1.1 Tasks . 29

3.seven.1.2 Roles . 29

three.seven.ane.3 Artifacts . 29

three.7.two Activity: Deploy Spider web Service . 29

3.seven.2.ane Tasks . 29

3.7.two.two Roles . thirty

iii.vii.2.iii Artifacts . 30

3.7.3 Activity: Examination deployment thirty

three.7.three.1 Tasks . 30

3.7.3.ii Roles . 30

3.seven.iii.iii Artifacts . 30

3.seven.4 Activity: Create end user support material 30

3.7.4.1 Tasks . 30

3.7.4.2 Roles . 30

iii.vii.4.3 Artifacts . 30

iii.seven.five Action: Publish Web Service . 31

iii.seven.v.1 Tasks . 31

3.7.5.2 Roles . 31

3.7.five.3 Artifacts . 31

four �� References . 32

Appendix A. Acknowledgments . 33

Appendix B. Revision History . 34

Appendix C. Notices . 35

List of Figures

Figure ane: Spider web Service Implementation Lifecycle . xi

Figure 2: The �5� Model incorporates the Spider web Services specific Interoperability test 15

Effigy iii: Relationship betwixt phase, activities, tasks, roles and artifacts . 15

List of Tables

Table 1: Mapping between phases and roles assigned . 11

Tabular array 2: Overview of activities, tasks, roles and artifacts in the Requirements Phase . 17

Table three: Overview of activities, tasks, roles and artifacts in the Assay Stage . 21

Table 4: Overview of activities, tasks, roles and artifacts in the Design Stage . 23

Table 5: Overview of activities, tasks, roles and artifacts in the Coding Phase . 25

Table six: Overview of activities, tasks, roles and artifacts in the Examination Stage . 28

Table vii: Overview of activities, tasks, roles and artifacts in the Deployment Phase . 31

1 Introduction

1.ane Purpose

The purpose of this document is to define a practical and extensible Web Service Implementation Methodology that can exist used as a reference for Spider web Services development and deployment.� This document is a consolidation of the best practices by Spider web Services practitioners and aims to improve the Spider web Services implementation process through the formalization of a Spider web Service implementation lifecycle and defining Web Service specific activities and artifacts.

This document should exist used in conjunction with the Functional Elements [1] specifications to govern the approach past which the Functional Elements are implemented.

1.2 Target Audition

The target audiences are probable to be:

� Project Managers

This document provides a formal methodology for Web Services implementation, which can exist used for management and control.

� Software Architects/Designers/Developers/Testers

This document identifies activities that are repeatable and which can be abide past, so as to ensure the quality of the software produced.

1.3 Scope

This certificate focuses Web Service specific activities, artifacts, roles and responsibilities that can be incorporated into an existing agile software development methodology (e.g. RUP, Farthermost Programming, Feature Driven Development etc).� For a few common agile methodologies the technical commission is preparing examples that testify in item how the generic activities, artifacts, roles, and responsibilities described in this document can be incorporated and used in a given methodology.� These case examples are provided in separate documents that will be published forth with this certificate when they go available.� Currently the technical committee is preparing cases for RUP and Farthermost Programming (XP).

1.3.1 Not in Telescopic

This document does not define yet another novel software development methodology.� Instead, the Spider web Service implementation methodology highlights important features in the context of Web Services.� The elements of the Spider web Service implementation methodology are based on existing active software methodology and extend it by incorporating Web Service specific activities.

Besides, information technology is non in the scope of this document to specifically accost how each of these software development methodologies should be tailored to incorporate Web Service specific parts. Examples are provided only to illustrate just one possible way of tailoring a specific active development methodology for Web Service implementation.

This certificate does non intend to ascertain a new software evolution methodology.� Instead, the Spider web Service Implementation Methodology leverages on an existing agile software methodology and extend it past incorporating the Web Services specific activities.

This document also does not cover the detailed description or caption of any of the existing agile software development methodology nor does it recommend i detail agile software development methodology over another.

ii Implementation Methodology Overview

ii.1 Objective

The Spider web Service Implementation Methodology defines a systematic approach to Web Service development by leveraging on an agile software development methodology and extending that methodology past specifying the Web Services specific activities and the respective roles and piece of work-products that are produced in the process.

This methodology will ascertain a set of common practices that create a method-independent framework, which tin can exist practical by near software teams for developing Web Service applications.

two.2 Spider web Service Implementation Lifecycle

A Web Service Implementation Lifecycle refers to the phases for developing Web Services from requirement to deployment.

The Web Service implementation lifecycle typically includes the following phases:

Requirements Phase [see 2.3.i ]
Analysis Phase [run into ii.three.2 ]
Blueprint Phase [run into two.3.3 ]
Coding Phase [come across ii.3.4 ]
Examination Stage [see two.3.v ]
Deployment Phase [see ii.three.6 ]

The transitions through these phases demand non exist a single-pass sequential process.� On the contrary, the process tends to be iterative and incremental in nature and should exist active plenty to arrange revisions in situations where the telescopic cannot be completely defined upwards front.

2.3 Phase

A Stage when used in the context of a Spider web Service implementation lifecycle refers to the period of time a ready of related software implementation activities are carried out.

In general, the phases detailed in the sub-sections are identified to be pertinent in a Web Service implementation lifecycle. � These phases may overlap with each other in the course of the implementation process as shown in Figure one.

Figure one : Spider web Service Implementation Lifecycle

two.3.i Requirements Phase

The objective in the requirements phase is to empathize the business organisation requirements and translating them to Web Service requirements in terms of the features, the functional and non-functional requirements, and the constraints within which the Web Service has to abide.

Requirements elicitation should be done past the requirements analyst and should involve the project stakeholders such every bit the project champion, customers, end users, etc.� Following which, the annotator should interpret, consolidate and communicate these requirements to the evolution team.

If possible, Requirements should be aggregated in a centralized repository where they tin be viewed, prioritized, and �mined� for iterative features.� In all cases, enabling the team to hands capture requirements, search, prioritize and elaborate as necessary is the primary function of the repository.

ii.three.2 Analysis Phase

In the assay phase, the requirements of the Spider web Service are further refined and translated into conceptual models by which the technical development team can understand.� Information technology is too in this phase that an architecture assay is done to define the high-level construction and identify the Web Service interface contracts.� This process should be performed by both the requirements annotator and the builder and communicated to the design and evolution teams.

2.three.three Design Phase

The detailed design of Spider web Services is done in this phase.� In this phase, the designers should define the Web Service interface contract that has been identified in the analysis phase.� The defined Web Service interface contract should identify the elements and the respective data types (possibly using a XML schema) every bit well every bit mode of interaction between the Web Service and the client, for example, whether it should be synchronous/asynchronous or RPC/Document mode etc.

two.3.iv Coding Phase

The coding and debugging phase for Web Service implementation is essentially quite similar to other software component-based coding and debugging stage.� The main difference lies in the creation of boosted Spider web Service interface wrappers (to expose the components� public APIs), generation of WSDLs and client stubs.� Web Services in addition have to be deployed to a Web Server/Application Server earlier the test clients can consume them.

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

2.3.v Examination Phase

For testing of Web Services, besides testing for functional correctness and abyss, testers should also perform interoperability testing between unlike platforms and clients� programs.� Furthermore, performance testing has to be conducted to ensure that the Web Services are able to withstand the maximum load and stress as specified in the non-functional requirements specification.� Other tasks like profiling of the Web Service application and inspection of Soap messages should likewise exist done in this phase.

2.three.six Deployment Phase

The purpose of the deployment phase is to ensure that the Web Service is properly deployed.� The phase volition be executed later on the service has been tested.� The deployment of the Web Service is platform specific.� The service end points of the Web Service specifies where the service is deployed and it needs to be identified and configured appropriately.� The deployer primary tasks are to ensure that the Web Service has been properly configured and managed (e.g. version controlled, presetting of configuration files, packaged and loaded in the correct location etc.) and running post-deployment tests to ensure that the Spider web Service is indeed ready for use.� Other optional tasks like specifying and registering the Web Service with an UDDI registry may as well exist performed in this phase.

Table 1 summaries the overview of each phase against its� corresponding assigned roles.

Phases	Main Roles
Requirements	Requirements Analysts
Assay	Requirements Analysts Architects
Design	Designers
Coding	Developers Testers
Test	Testers
Deployment	Deployers

Table 1 : Mapping betwixt phases and roles assigned

2.4 Office

Commonly defined roles in software development methodology include the following:

Roles	Responsibilities
Requirements 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 and implementation for the project.
Designer	Responsible for designing a part of the system, within the constraints of the requirements, compages, and development procedure for the project.
Developer	Responsible for developing and unit testing the components, in accordance with the project's adopted standards.
Deployer	Responsible for planning the product's transition to the user community, ensuring those plans are enacted appropriately, managing issues and monitoring progress.
Stakeholder	Responsible for providing the domain expertise and specifying the system requirements.� Stakeholder usually includes the projection champion and the cease users.
Project Manager	Responsible for managing and monitoring the project including the project scope, schedule and staffing of the project team.
Test Director	Responsible for the full test efforts including the quality and test advocacy, resource planning and management of the testing schedule, and resolution of issues that impede the examination effort.
Test Designer	Responsible for defining the test approach and ensuring its successful implementation.� The part involves identifying the advisable techniques, tools and guidelines to implement the required tests, and to give guidance on the respective resources requirements for the test endeavour.� The function also involves monitoring detailed testing progress and results in each examination bicycle and evaluating the overall quality every bit a result of testing activities.
Tester	Responsible for the cadre activities of the test endeavor, which involves conducting the necessary tests and logging the outcomes of that testing.
Arrangement Administrator	Responsible for planning, installing and maintaining the hardware and software of the dissimilar environments e.g. development, test, live environment

2.5 Glossary

Activeness	An Activity refers to a unit of work a part may exist assigned to perform.� Activities are performed within each of the phases in the Web Service implementation lifecycle.
Artifact	An Artifact refers to the work-production that is used or produced as a outcome of performing an activity.� Examples of Artifacts include models, source files, scripts, and binary executable files.
Role	A Role refers to the responsibilities that a person or a squad has been assigned with.

three Web Service Implementation Methodology

The term Web Service describes a specialized type of software, which is designed to support a standardized style for provision and consumption of services over the Web, through the compliance with open up standards such as eXtensible Markup Linguistic communication (XML), Lather, Web Services Clarification Language (WSDL) and Universal Description, Discovery and Integration (UDDI).

Spider web Services, different traditional client/server systems, such as browser/Web server systems, are not meant for directly finish-user consumption.� Rather, Web Services are pieces of business logic, which have programmatic interfaces and it is through these interfaces that developers tin create new awarding systems.

The motivation behind Web Services is to facilitate businesses to interact and integrate with other businesses and clients, without having to become through lengthy integration design and/or to expose its confidential internal awarding details unnecessarily.� This is made possible past leveraging on the non-platform dependent and non-programming language dependent XML to depict the data to be exchanged betwixt businesses or between the business organisation and its clients, using a WSDL to specify what the service is providing; using a UDDI to publish and locate who is providing the service; and typically using SOAP over HTTP to transfer the message across the internet [2] .

A Web Service, naturally, is a software element, but considering of its specialized interface and machinery to interoperate with others, all the prevalent generic software development methodology would demand to be tailored to handle the unique features of Web Service.� This could interpret to identification of Spider web Service specific requirements (e.g. conformance to Web Services standards), analysis of the specific implications of Web Service on the overall system, design of the Web Service interface and XML message structure, coding, testing, deployment and execution of the Web Service.

The Spider web Service Implementation Methodology that we define is to promote a systematic arroyo to Web Service development.� Rather than defining a new software development methodology and expecting software practitioners to forget their ain familiar and established methodology to re-acquire another, the better alternative is to leverage on what is already bachelor and customize that methodology to contain the specifics of Web Services.

The candidate software development methodology should, ideally, exist active and able to accommodate refinement throughout the evolution cycle in an iterative and incremental approach.� The methodology should consist of phases that cover from the formulation of the need of the Web Service, to the construction of the Web Service and finally to be deployed for utilize by the eventual client application.� In this certificate, these phases are identified equally requirements, analysis, blueprint, code, exam and deployment.

The Web Service Implementation Methodology would leverage on whatever of the candidate agile software evolution methodology and extend the said methodology by specifying additional and/or customized Web Service specific activities and its corresponding roles and piece of work-products.

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

In improver, for Spider web Service testing, a multitude of tests have to be conducted to ensure that the Web Service is adult according to its functional also equally non-functional requirements.� Figure two illustrates using the �5� Model to perform these tests.

Effigy 2 : The �5� Model incorporates the Web Services specific Interoperability test

The specifications produced in each of the development phases are sources of input to derive the test scenarios and exam cases.� From these test cases, test scripts and exam information are compiled, which will be used in unit testing, functional testing, integration/interoperability testing, system/performance testing and the last user acceptance testing.

3.ane Overview

The Web Service Implementation Lifecycle describes the phases a typical Spider web Service would undergo, from the identification of the need of the Spider web Service to the final deployment and usage past the end-users.� The phases identified to be relevant in the Web Service Implementation Lifecycle are: requirements, analysis, design, code, test and deployment.� In each of these phases, Web Service specific activities are carried out.� These activities, as well as the roles and responsibilities, and the artifacts will exist elaborated in the subsequent sub-sections.� Figure three illustrates the above-mentioned relationship betwixt phase, activities and their corresponding tasks, roles and artifacts.

Effigy iii : Relationship between phase, activities, tasks, roles and artifacts

3.two Requirements Phase

three.2.1 Activity: Determine the need for Web Service

3.ii.1.1 Tasks

Place the stakeholders

Stakeholders would usually include the end users, project champion, project manager, etc.

Understand the inadequacies/problems to address

Empathize the stakeholders� demand for Web Services.

Identify the need for Web Service technology

Based on the electric current technology available, identify needs specially for Spider web Services.

Determine the positioning of the Spider web Service inside the boundaries of the problem identified

Define the features of the Web Service based on the needs list

Identify the limitations to be imposed on the Web Service

3.2.ane.2 Roles

Builder, Requirements Analyst, Stakeholders, Projection Managing director

iii.ii.ane.three Artifacts

The results should be recorded in Business concern Requirement Specifications.

3.2.2 Action: Arm-twist Web Service requirements

3.2.2.1 Tasks

Place the sources for requirements gathering based on the features list

Identify the departments, terminate users, domain experts, etc. who would be impacted by the introduction of Web Services.

Gather information from these sources and elicit the requirements for the Web Service

Identify functional requirements for the Web Service and categorise them

Identify non-functional requirements for the Web Service

Non-functional requirements are requirements pertaining to Usability, Reliability, Performance, Scalability, Supportability and other blueprint considerations.

3.2.2.2 Roles

Requirements Analyst, Architect, Test Director

3.two.2.three Artifacts

The results should exist recorded in Requirement Specifications.

3.2.three Activity: Manage the Spider web Service requirements

three.2.three.i Tasks

Based on the functional requirements categories, place the Spider web Services and establish the dependencies and priorities

Create traceability matrices from the requirements to the identified Spider web Services

Traceability matrices assist to track the requirements that have been taken intendance of by the Web Services identified.

Manage changes to the requirements

iii.2.3.2 Roles

Requirements Analyst, Builder, Exam Manager

3.2.3.iii Artifacts

The results should be recorded in Requirement Specifications.

3.2.four Activity: Model the usage scenarios

iii.2.4.1 Tasks

Interpret the functional requirements into conceptual usage models using some form of assay modeling techniques

Specify the major interaction scenarios with the Web Service clients

This is to highlight the usage of Web Services involved.� Especially, the message exchange scenarios should be captured.

3.ii.4.ii Roles

Requirements Analyst, Architect, Test Director

3.2.4.3 Artifacts

The results should be recorded in Requirement Specifications.

3.2.5 Activity: Ready Test Cases for User Acceptance Test (UAT) and System Test

3.2.5.1 Tasks

Write business scenario exam case(s) based on the requirements gathered to be used for UAT and Organisation Examination

Exam example(due south) can be derived from requirements.� This is also a fashion to verify the requirements when they are implemented.

Build requirement validation matrix

The requirement validation matrix will include the requirements and a reference to the test case(southward) that will validate the requirement.

Manage changes to the examination cases when requirements changed

3.2.v.two Roles

Requirements Analyst, Examination Manager, Test Designer

3.2.5.three Artifacts

The results should be recorded in Examination Programme � UAT and System Test.

Table 2 summaries the overview of each activities and the corresponding tasks, roles and artifacts nether the activities.

Activities	Tasks	Roles	Artifacts
� Determine needs	� Place stakeholders � Understand the inadequacies/problems to address � Place demand for WS engineering science � Decide positioning of WS within the boundaries of the problem identified � Define features of WS based on needs � Identify limitations	� Builder � Requirements Annotator � Stakeholders � Project Manager	� Concern Requirement Specifications
� Elicit requirements	� Identify sources for requirements gathering � Get together information � Place functional requirements � Place not-functional requirements	� Architect � Requirements Analyst � Test Manager	� Requirement Specifications
� Manage requirements	� Place WS and establish dependencies and priorities � Create traceability matrices � Manage changes to requirements	� Builder � Requirements Analyst � Test Manager	� Requirement Specifications
� Model usage scenarios	� Interpret functional requirements into conceptual usage models � Specify major interaction scenarios with WS clients	� Builder � Requirements Annotator � Test Manager	� Requirement Specifications
� Prepare exam cases for UAT and System Examination	� Write business concern scenarios test cases � Build requirement validation matrix � Manage changes to test cases	� Requirements Analyst � Test Director � Test Designer	� Test Programme � UAT and System Test

Notes: WS stands for Web Services

Tabular array two : Overview of activities, tasks, roles and artifacts in the Requirements Phase

3.3 Analysis Phase

three.iii.1 Activity: Select a engineering platform as implementation framework

iii.three.one.i Tasks

Specify the Spider web Services standards that the implementation must adhere

Place the Spider web Service standards based on the requirements and implementation constraints.� Consider issues like the standards compatibility, version of standards, standards adoption in industry sector, and the organization approval the standards.

Determine the technology platform for implementing Web Services

Choose a technology platform that is suitable for implementation.� E.g. dotNet or Coffee platform.

Determine the engineering science platform for hosting Web Services

Based on implementation constrains and considerations for standards support and interoperability requirements, cull the appropriate hosting platform for Web Services.

Decide the IDE tools used to develop Web Services

Available options include commercial vendor�south IDE tools, open source IDE tools.� Commonly, the selection of IDE is tied together with the implementation platforms.

3.3.1.2 Roles

Builder

three.3.1.three Artifacts

The results should be recorded in Software Architecture Specifications.

3.three.ii Activeness: Define a candidate architecture for the Spider web Service

3.three.2.i Tasks

Ascertain a high-level compages

Identify the architectural component that expose functionality as Web Services

It is necessary to identify the architectural components that implement the wrapping of functionality as Spider web Services and implement the message exchanges in the high level architecture.

Specify the major data exchange with Web Service clients

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

3.iii.2.two Roles

Builder

3.3.2.3 Artifacts

The results should be recorded in Software Architecture Specifications.

3.3.three Activeness: Decide on the granularity of the Web Service

3.3.3.one Tasks

Decide on the coarseness of the Spider web Service operations to be exposed

Fix up criteria on the coarseness of Web Services operations.� Its definition depends on the usage scenarios and requirements.

Place and grouping functionality into the Web Service

Based on the requirements and criteria mentioned in a higher place, place the functions that are needed to group into the Web Services.

Decide on the mechanisms to compose or aggregate functionality

In case there is a need to compose individual Web Services, cull and make up one's mind the mechanism to implement the compositions.

three.3.3.two Roles

Architect

3.three.3.3 Artifacts

The results should exist recorded in Software Compages Specifications.

iii.3.4 Activity: Identify reusable Web Services

iii.iii.4.i Tasks

Identify the architectural components that tin can exist realized by existing Web Services

If the functionality of the architecture component can be fulfilled with existing Web Services (internal or third political party Web Services), the architectural components should be identified to make employ of these existing Spider web Services.

Identify the Web Service providers for the reusable Web Services

Identify and gather the data virtually provider of existing Spider web Services.

Define the major invocation scenarios of re-utilise

Identify the functions that are going to be used.� Define the interface of invocation.

3.3.4.2 Roles

Builder

3.iii.4.3 Artifacts

The results should be recorded in Software Architecture Specifications.

3.3.5 Activity: Identify service interface for new Web Services

three.iii.5.1 Tasks

Define the new Web Service operation signatures

Based on the usage models and analysis models, identify the operations and its signatures.

Define XML schema for the bulletin exchange

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

3.3.5.2 Roles

Builder, Designer

3.three.5.3 Artifacts

Web Service Signature Specifications, XML schema.

three.3.6 Activeness: Prepare Examination Cases for Performance Test

three.three.six.1 Job

Write performance test case(s) to exist used for Functioning Exam

Test case(south) can exist derived from Architectural Pattern Specifications.

These exam cases should cover load testing scenarios to see how the system will perform nether various loads (in terms of concurrent users/requests and/or transactions).

3.3.6.two Roles

Examination Organisation Ambassador, Test Designer

3.3.6.iii Artifacts

The results should be recorded in Test Program � Performance Examination.

three.iii.vii Activity: Ready Test Cases for Integration / Interoperability Test

3.3.7.i Chore

Write integration / interoperability test case(s) to be used for Integration / Interoperability Test

Test case(south) can be derived from Architectural Design Specifications.

3.three.seven.2 Roles

Test Designer, Tester

3.3.7.iii Artifacts

The results should exist recorded in Examination Program � Integration / Interoperability Test.

3.iii.8 Activity: Set Test Cases for Functional Examination

3.3.eight.one Task

Write functional exam instance(s) to be used for Functional Test

Test case(s) can exist derived from Architectural Design Specifications.

3.3.8.2 Roles

Test Designer, Tester

3.3.8.3 Artifacts

The results should exist recorded in Test Plan - Functional Test.

3.3.9 Activeness: Testbed preparation

3.3.9.1 Job

Set upward testing environment that include hardware and software

This environment may exist similar to the product/live surround in terms of hardware, Bone, Web Server/Application Server, etc.

3.iii.9.two Roles

Examination Organisation Administrator, Exam Designer

3.3.nine.3 Artifacts

The results should be recorded in Exam Programme - Testbed.

Table iii summaries the overview of each activities and the corresponding tasks, roles and artifacts under the activities.

Activities	Tasks	Roles	Artifacts
� Select a engineering science platform every bit implementation framework	� Specify implementation standards � Decide applied science platform for implementation � Decide technology platform for hosting � Decide IDE tools used for evolution	� Architect	� Software Architecture Specifications
� Define candidate compages	� Define high-level architecture � Place architectural component that expose functionality as WS � Specify major data exchange with WS clients	� Architect	� Software Compages Specifications
� Decide granularity	� Decide on coarseness of the operations to exist exposed � Identify and group functionality � Decide on mechanisms to compose or aggregate functionality	� Architect	� Software Architecture Specifications
� Place reusable WS	� Identify architectural components that tin be realized by existing WS � Place WS providers for reusable WS � Define major invocation scenarios of re-use	� Architect	� Software Compages Specifications
� Identify service interface	� Define new WS functioning signatures � Define XML schema for message exchange	� Architect � Designer	� WS Signature Specifications � XML Schema
� Set up test cases for Performance Test	� Write Performance test cases	� Test System Administrator � Test Designer	� Exam Program � Operation Exam
� Prepare exam cases for Integration / Interoperability Exam	� Write Integration / Interoperability test cases	� Test Designer � Tester	� Test Plan � Integration / Interoperability Examination
� Ready test cases for Functional Exam	� Write functional test cases	� Test Designer � Tester	� Test Program � Functional Exam
� Testbed preparation	� Gear up up testing environment	� Test Organization Administrator � Test Designer	� Test Programme - Testbed

Notes: WS stands for Spider web Services

Table iii : Overview of activities, tasks, roles and artifacts in the Analysis Phase

3.four Design Phase

iii.4.1 Activity: Transform signatures of reusable Web Services

iii.4.ane.1 Tasks

Identify the data blazon mapping if required

If the type of a parameter of the reusable service is not straight supported by the identified platform, information type mapping should exist performed.

Identify the design patterns for mapping the re-used Spider web Service interface to the identified (desired) ane

Certain design patterns could exist used to reuse existing Spider web Service(s), such as adapter pattern, fa�ade pattern etc.� Adapter pattern could be used to expose a new interface of an existing Web Service.� The fa�ade pattern could be used to encapsulate the complexity of existing Web Services and provide a coarse-grained Web Service.

3.4.1.ii Roles

Designer

iii.4.one.3 Artifacts

The results should be recorded in Design Specifications.

iii.4.ii Activity: Refine service interface of the new Spider web Service

3.4.2.1 Tasks

Refine Web Service interfaces signature

In the detailed design stage, the signature may be refined farther.� Care must be taken to ensure that the design decision should not affect the interoperability of the service.

Refine XML schema for bulletin exchange

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

three.4.2.2 Roles

Designer

3.4.2.3 Artifacts

The results should exist recorded in Pattern Specifications.

3.4.3 Activity: Pattern Web Service

3.4.3.1 Tasks

Use some form of modeling techniques to describe the internal construction of the Web Service

The design of the internal construction needs to consider the receiving and pre-processing of request, delegating of the request, processing of the asking and sending of the response.� Existing modeling techniques such as UML, design patterns could be applied to the blueprint.

Consider non-functional requirements (e.g. usability, reliability, performance, scalability etc.) and design constraints (e.g. interoperability etc.)

3.4.3.2 Roles

Designer

three.4.3.iii Artifacts

The results should be recorded in Pattern Specifications.

three.four.4 Activity: Refine Test Cases for Functional Exam

iii.iv.4.1 Job

Refine functional test instance(s) to be used for functional Test

Test case(s) can be refined by Design Specifications.

three.four.four.2 Roles

Examination Designer, Tester

iii.4.4.3 Artifacts

The results should exist recorded in Exam Plan � Functional Exam.

Tabular array 4 summaries the overview of each activities and the corresponding tasks, roles and artifacts nether the activities.

Activities	Tasks	Roles	Artifacts
� Transform signatures of reusable WS	� Place data blazon mapping if required � Identify design patterns for mapping the re-used WS interface to the desired one	� Designer	� Design Specifications
� Refine service interface of new WS	� Refine WS interface signature � Refine XML schema for bulletin exchange	� Designer	� Design Specifications
� Design WS	� Employ modeling techniques to describe internal structure of WS � Consider not-functional requirements and blueprint constraints	� Designer	� Blueprint Specifications
� Refine test cases for Functional Test	� Refine functional exam cases	� Test Designer � Tester	� Test Programme � Functional Test

Notes: WS stands for Web Services

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

3.v Coding Stage

3.5.one Activity: Construct Web Service code

3.five.1.one Tasks

� Based on the implementation language choice, code the Spider web Service according to the blueprint

Consider other constraints that are imposed by the specific implementation language itself.� For example, consider the language dependent information types and the demand to map these data types to the ones specified by the Web Service interface.

� Expose public APIs as Spider web Service interface

For example, in Coffee, to create the interface class to betrayal the class method every bit a Web Service functioning or in dotNet, to comment the class API as a [WebMethod].

� Generate WSDL for client to consume

Most IDEs tin motorcar-generate the WSDL from the interface code.

iii.5.1.2 Roles

Programmer

3.5.1.three Artifacts

Spider web Service Implementation Codes.

3.v.2 Activity: Construct Web Service client code

3.5.2.i Tasks

� Decide on the Spider web Service Client programming model

Among the three available are:

a) Static Stub

The client invokes the Web Service functioning through a stub.� Any IDE can generate this stub at compile time.

b) Dynamic Proxy

Every bit the proper noun implies, dynamic proxy is dynamically generated when the client application is executed.� Because dynamic proxy is generated during runtime, Web Service invocation using this method takes the longest fourth dimension amidst the three approaches.

c) DII (Dynamic Invocation Interface)

It is the almost flexible arroyo amidst the iii programming models.� The client does non fifty-fifty need to know the signature of the Web Service operation until runtime.� The Web Service invocation can be dynamically constructed.

Hence, identify and determine on a suitable customer programming model based on the weightage of flexibility against performance requirements.

� Write client code to consume the Spider web Service

Apply the WSDL to generate client stubs, which can be used in the customer code to invoke the methods provided past the Web Service.

3.5.ii.2 Roles

Developer

3.5.two.three Artifacts

Web Service Client Codes.

3.5.3 Activity: Unit Examination Web Service

3.five.3.ane Tasks

� Deploy Web Service in local test environment and perform functional unit of measurement testing

The emphasis is on the definiteness of the functionality and the exceptions handling.

3.5.3.2 Roles

Programmer

3.5.iii.3 Artifacts

Unit Test Scripts.

Table 5 summaries the overview of each activities and the corresponding tasks, roles and artifacts under the activities.

Activities	Tasks	Roles	Artifacts
� Construct WS code	� Code based on implementation language chosen � Betrayal public APIs equally interface � Generate WSDL for client	� Developer	� Implementation codes
� Construct WS customer code	� Determine client programming model � Write customer codes	� Developer	� Client codes
� Unit test	� Deploy in local exam environment and perform functional unit testing	� Developer	� Unit test scripts

Notes: WS stands for Web Services

Table five : Overview of activities, tasks, roles and artifacts in the Coding Phase

iii.6 Test Phase

For Spider web Services, boosted tests may be conducted to ensure that the Web Services are interoperable, secured and scalable.

Interoperability is an issue in Web Services because the standards governing Web Services are still evolving.� Furthermore, dissimilar vendors that implement these specifications may interpret and comply with these specifications differently.� Currently there is an effort by Web Services Interoperability Organization (WS-I) to recommend basic profiles to minimise these incompatibilities.� The aim of conducting interoperability tests is to ensure that these reccomendations are followed and the Web Service adult will interoperate with other Web Services and products without issues.

Network congestion created by Web Services is the major contributor to Web Services� tiresome functioning.� Not only is the messaging betwixt requesters and Web Services impacted by network latency, but also the service discovery and description protocols that precede those message exchanges. �The cumulative effect of these delays tin seriously dethrone the performance of Web Services.� Therefore it is necessary to do a functioning examination on the Spider web Services before they are deployed for operation, and and then to monitor the Web Services to determine if they tin can meet the service level agreements.

Web Services introduce special security bug east.g. in privacy, bulletin integrity, authentication and dominance.� Tests have to be conducted to ensure that these security requirements have been fulfilled.� However , security schemes could complicate the process of testing and debugging Spider web Service basic functionality.� For example, non-intrusive monitors are often used in functional testing but encrypted traffic presents an obvious complication to this arroyo to testing.

3.6.1 Activity: Test functionality of Web Service

3.vi.i.1 Tasks

Testing bones Spider web Service functionality

The Web Service should answer correctly to requests from their clients.� The format of the SOAP message should exist in compliance with the specifications.� WSDL files, which comprise metadata nigh Web Services� interfaces, should be in compliance with the WSDL specifications published by W3C. � Perform fault checking to encounter how it handles unexpected input.� The test scripts and data prepared in the earlier phases are executed in this activeness.� The test results should be recorded, and bugs found should be reported to the code owners and fixed by them.

Test for security

If a service requires a certain level of privacy, or if it requires that messages be authenticated in a certain fashion, so specific tests are needed to ensure that these security requirements are met.� The exam scripts and test data prepared in the earlier phases should be executed in this activity.� Any inadequacies that may lead to possible security breaches should be reported and resolved by the code possessor, designer or architect.

Exam the UDDI functionality

If a service is registered to a registry server, p erform registering of Spider web Service, so westward rite test clients to perform finding and binding of Web Service on the registry, and and then use the registry data to really invoke the service.� Test results from the exam scripts and data should be recorded and bugs should exist fixed by the code owners.

Test for Lather intermediary capability

If particular Lather bulletin has ane or more intermediaries along the message road that accept actions based upon the instructions provided to them in the header of the Lather message.� Web Service SOAP intermediary testing must verify the proper functionality of these intermediaries. � Examination results from the test scripts and data should exist recorded and bugs should be fixed by the code owners.

3.vi.1.2 Roles

Tester, Test Designer

3.half dozen.1.3 Artifacts

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

3.half dozen.2 Action: Integration Exam on the Web Service

3.six.2.i Tasks

Test for conformance to Web Services Interoperability Organization (WS-I) recommendations.� Execute examination scripts and information according to the test cases based on the WS-I recommendations.

Perform interoperability testing based on various scenarios

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

Perform integration testing based on various scenarios

Based on the exam cases prepared in the Assay Phase, exam scripts and exam data, which are prepared are executed and analyzed in this activity.

iii.vi.2.2 Roles

Tester, Examination Designer, Test System Administrator

3.6.2.iii Artifacts

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

3.6.three Activity: System Test on the Web Service

iii.half-dozen.3.1 Tasks

C heck organisation functionality and response time under different degrees of load increases

The test cases that are prepared in the earlier phases are executed in this activity.� The load increases can be sudden surges or gradual ramp-ups . The exam results should be analyzed to determine potential bottlenecks and if the organization is scalable.

C heck functionality and response time under unlike combinations of valid and invalid requests

The results from the examination execution should exist analyzed to determine if the system can still return the expected quality of service equally specified in the non-functional requirement specifications.

3.half-dozen.three.2 Roles

Tester, Test Designer, Examination System Administrator

3.six.3.3 Artifacts

The results should exist recorded in Customer Test Lawmaking, Test Scripts and Test Results.

three.six.4 Activity: User Acceptance Test on the Spider web Service

three.6.iv.i Tasks

Run the user acceptance test cases(s) for the Web Services system

The examination cases prepared in the Requirement Phase are used in this activity to validate the correctness and completeness of the Web Service organization.� Any bugs found should be reported and stock-still by the code owners.

3.half dozen.iv.2 Roles

User, Exam Managing director, Test System Administrator

3.half-dozen.iv.3 Artifacts

The results should be recorded in Customer Examination Code, Test Scripts and Test Results.

Tabular array vi summaries the overview of each activities and the corresponding tasks, roles and artifacts nether the activities.

Activities

Tasks

Roles

Artifacts

� Test functionality

� Exam basic WS functionality

� Test for security

� Test UDDI functionality

� Exam for Lather intermediary adequacy

� Tester

� Test Designer

� Client test code

� Exam scripts

� Test results

� Integration test

� Test for conformance to WS-I

� Perform interoperability test based on various scenarios

� Perform integration test based on various scenarios

� Tester

� Test Designer

� Test Arrangement Ambassador

� Customer exam code

� Test scripts

� Test results

� Arrangement test

� Check system functionality and response time nether different degrees of load increases

� Cheque functionality and response time under different combinations of valid and invalid requests

� Tester

� Test Designer

� Examination System Administrator

� Customer test code

� Test scripts

� Examination results

� User credence test

� Run UAT test cases

� User

� Exam Managing director

� Examination System Administrator

� Client test code

� Test scripts

� Test results

Notes: WS stands for Web Services

Tabular array six : Overview of activities, tasks, roles and artifacts in the Test Phase

3.7 Deployment Stage

iii.7.ane Action : Prepare deployment environment

3.7.1.1 Tasks

Ready up and configure the hardware for Spider web Service deployment

Fix upwards and configure the software for Spider web Service deployment

The software may include application server, database, etc.� The application server should have a SOAP listener to support Web Services.� Some Web Services may need the SOAP handler to be configured.

iii.seven.ane.2 Roles

Arrangement Engineer

iii.seven.one.3 Artifacts

Release Notes.

three.7.2 Action: Deploy Web Service

3.7.two.1 Tasks

Determine service URL

Web Service URL is unique and used to place the Web Service and where it is located.

Ready the deployment script

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

Deploy the Web Service

Execute the prepared deployment script.

Generate WSDL file

After successfully deploying the Spider web Service, a WSDL file is needed to describe the functions provided by the Web Service.� WSDL can be created manually or by most application servers, which will automatically generate the WSDL file after deployment.

3.7.2.two Roles

Developer

three.7.two.3 Artifacts

WSDL File, Deployment Script.

3.vii.three Action: Test deployment

3.seven.3.1 Tasks

Create (reuse) Web Service customer lawmaking

The Web Service client code should exist created by the programmer during code and debug phase.

Consume Web Service with the customer code

Because the functionality of the Spider web Service is properly tested, in that location is no demand to test all the operations.� To make sure the Web Service is properly deployed and configured, the best candidates of operations for invocation are the ones needed for database connectedness, configuration of SOAP handler or any other special features of the application server.

3.7.three.2 Roles

Tester

three.seven.three.three Artifacts

Web Service Client Codes.

3.7.iv Action: Create stop user support fabric

3.7.four.one Tasks

Create end user support material

The support material is needed to assistance the users to understand and use the Web Service.� For example, an interoperability guide of the Web Service.

3.7.four.two Roles

Developer

3.seven.4.3 Artifacts

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

3.7.5 Activity: Publish Web Service

3.7.5.1 Tasks

Identify the UDDI registry for publishing the Web Service

Based on the requirements, decide whether a private or public UDDI registry is needed and the version of the UDDI Business concern Registry specifications to follow.

Prepare the information needed for publishing

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

Publish the Web Service in the UDDI registry

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

Search the Web Service by central words after publishing

Search the Web Service through browser provided by UDDI registry or tools provided past other vendors.

3.7.5.2 Roles

Developer

3.7.v.iii Artifacts

None.

Tabular array 7 summaries the overview of each activities and the corresponding tasks, roles and artifacts under the activities.

Activities	Tasks	Roles	Artifacts
� Fix deployment surround	� Set up and configure hardware � Set up and configure software	� Organisation Engineer	� Release Notes
� Deploy WS	� Make up one's mind service URL � Ready deployment script � Deploy WS � Generate WSDL	� Programmer	� WSDL file � Deployment script
� Test deployment	� Create (reuse) client lawmaking � Consume WS with customer code	� Tester	� Client codes
� Create end user support material	� Create back up material	� Programmer	� Interoperability guide � User guide � On-line help � Tutorials � Training cloth
� Publish WS	� Identify UDDI registry for publishing � Prepare data for publishing � Publish in UDDI registry � Search by central words after publishing	� Programmer	� --

Notes: WS stands for Web Services

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

iv References

1. �Rational Unified Process�, Version 2003.06.00.65, IBM-Rational Software.

ii. �Rational Unified Process for Developing Web Services�, Version 1.0, Java Smart Services Laboratory and Rational Software Pte. Ltd., Aug 2003.

The following individuals were members of the commission during the development of this documentation:

� Ravi Shankar, CrimsonLogic Pte. Ltd.

� Jagdip Talla, CrimsonLogic Pte. Ltd.

� Andy Tan, Individual

� Roberto Pascual, The Infocomm Evolution Dominance of Singapore

Rev	Date	Past Whom	What
wd-01	2004-09-xxx	Lai Peng CHAN Chai Hong ANG	Initial version
-	2004-12-23	Chai Hong ANG	Split the document into two
wd-01a	2005-05-24	Chai Hong ANG Puay Siew TAN Han Benefaction LEE	� Remover Section ii.1 Terminology, Section 2.2 Concepts and Department 2.ii.1 Web Service and combined them as Section ii.1 Objective � Renumber Section 2.2.2 to Section 2.two � Renumber Section 2.two.iii to 2.3.� The rest of the sub-sections are renumbered accordingly � Added Table ane equally summary for phase and its assigned roles � Section two.2.4 Activeness and Department 2.two.half-dozen Artifact are moved into Section 2.v Glossary � Renumber Section 2.2.5 to ii.5 and put them into table format � Section iii is renamed as Web Service Implementation Methodology � Removed Department 3.i � Renumber Department iii.i.one to 3.1 � Renumber Section 3.1.two to three.2.� The residue of the sub-sections are renumbered accordingly � Tables are added into each stage for summary � Removed Normative and Non-Normative from Section 4
wd-01b	2005-06-02	Chai Hong ANG Prof. Marc Haines	� Edited based on Prof. Haines� comments

OASIS takes no position regarding the validity or scope of any intellectual belongings or other rights that might be claimed to pertain to the implementation or utilize of the technology described in this document or the extent to which any license nether such rights might or might not be available; neither does information technology represent that it has made any effort to place whatsoever such rights. Information on Oasis's procedures with respect to rights in Haven specifications can be found at the OASIS website. Copies of claims of rights made available for publication and whatsoever assurances of licenses to be made available, or the result of an endeavor made to obtain a general license or permission for the use of such proprietary rights past implementors or users of this specification, can exist obtained from the OASIS Executive Director.

OASIS invites any interested party to bring to its attention whatsoever copyrights, patents or patent applications, or other proprietary rights which may embrace technology that may be required to implement this specification. Delight address the data to the Haven Executive Director.

This certificate and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or help in its implementation may be prepared, copied, published and distributed, in whole or in office, without restriction of any kind, provided that the to a higher place copyright observe and this paragraph are included on all such copies and derivative works. Nevertheless, this document itself does not be modified in any way, such equally by removing the copyright observe or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which example the procedures for copyrights divers in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not exist revoked past OASIS or its successors or assigns.

This certificate and the information contained herein is provided on an �Equally IS� basis and Haven DISCLAIMS ALL WARRANTIES, EXPRESS OR Implied, INCLUDING BUT Not Express TO Any WARRANTY THAT THE USE OF THE Information HEREIN Will NOT INFRINGE Any RIGHTS OR Whatever Implied WARRANTIES OF MERCHANTABILITY OR Fitness FOR A Item PURPOSE.

What Are The Steps Involved In Defining And Using A Web Service?,

Source: https://www.oasis-open.org/committees/download.php/13420/fwsi-im-1.0-guidlines-doc-wd-publicReviewDraft.htm

Posted by: benderemenim.blogspot.com