Web Services Implementation Methodology Case Example using Extreme Programming Working Draft 04, 14 August 2005



Download 70.07 Kb.
Date conversion07.06.2018
Size70.07 Kb.


Web Services Implementation Methodology Case Example using Extreme Programming

Working Draft 04, 14 August 2005


Document identifier:


Location:

http://www.oasis-open.org/apps/org/workgroup/fwsi/documents.php



Editor:

Andy TAN, individual



Contributors:

Chai Hong ANG, Singapore Institute of Manufacturing Technology



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

Eng Wah LEE, Singapore Institute of Manufacturing Technology



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

Marc HAINES, individual



Abstract:

This document provides a guideline to prepare a case example to be included in the Implementation Methodology Guideline.



Status:

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

Committee members should send comments on this specification to the imsc@lists.oasis-open.org list. Others should subscribe to and send comments to the fwsi-comment@lists.oasis-open.org list. To subscribe, send an email message to fwsi-comment-request@lists.oasis-open.org with the word "subscribe" as the body of the message.

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



Table of Contents

1 Overview 4

2 Terminology Mapping 5

2.1 Implementation Lifecycle 5

2.2 Project Team Roles 5

2.3 Artifact Cross Reference 6

2.4 Concepts not defined in WSIM Guideline 6

2.4.1 Pair Programming 6

2.4.2 Continuous Integration 7

3 Implementation Phases 8

3.1 Planning: Requirement Phase & Analysis Phase 8

3.1.1 Determine the need for Web Services [3.2.1] 8

Elicit Web Service requirements [3.2.2] 8

Manage the Web Service requirement [3.2.3] 8

Model the usage scenarios [3.2.4] 8

Prepare test cases for User Acceptance Test and System test [3.2.5] 9

Selecting a technology platform as implementation framework [3.3.1] 9

Define a candidate structure architecture for the Web Services [3.3.2] 9

Define on the granularity of the Web Services [3.3.3] 10

Identify reusable Web Services [3.3.4] 10

Identify service interface contract for new Web Services [3.3.5] 10

Prepare Test Cases for Performance Test [3.3.6] 10

Prepare Test Cases for Integration / Interoperability Test [3.3.7] 10

Prepare Test Cases for Functional Test [3.3.8] 11

Test bed preparation [3.3.9] 11

Release Plan 11

3.2 Design Phase & Coding Phase 12

Transform signature of reusable Web Services [3.4.1] 12

Refine service interface of the new Web Services [3.4.2] 12

Design Web Services [3.4.3] 12

Refine Test Cases for Functional Test [3.4.4] 13

Code internal workings of Web Services [3.5.1] 13

Write the Web Services Consumer Code [3.5.2] 13

Unit Test Web Services [3.5.3] 13

3.3 Test Phase 14

Test Functionality of Web Services [3.6.1] 14

Integrated Test on the Web Services [3.6.2] 14

System test on the Web Services [3.6.3] 15

User Acceptance Test on the Web Services [3.6.4] 15

3.4 Deployment Phase 16

Prepare deployment environment [3.7.1] 16

Deploy Web Services [3.7.2] 16

Test Deployment [3.7.3] 16

Create end user support material [3.7.4] 16

Publish Web Services [3.7.5] 17

4 Reference 18

Appendix A. Acknowledgments 19

Appendix B. Revision History 20

Appendix C. Notices 21



1Overview


This case example illustrates how Extreme Programming (XP) can be adapted to incorporate the Web Services specific activities described in the Web Services Implementation Methodology (WSIM) Guideline.

We knew of XP in association with software development and wondered if it could solve the problems in Web Services development. XP methodology could potentially deal with a number of Web Services development problems. XP involves the customer (user), integrates teams, generates code and most importantly divides the projects successfully between the developer, the project manager and the customer.

Web Services project involves multi-disciplinary team made up of server-side programmers, interface programmers, testers, project managers and users. Team members cannot work in isolation because the decisions made by one affects the others. There are intersection and overlapping of skills which make it impossible to set strict boundaries of responsibility.

XP is very suitable at getting programmers to communicate among themselves and with customers.

Most software projects create deliverables for one platform at a time; however Web Services project requires it to interoperate with disparate systems implemented in different platforms.

Web Services requires testing to account for the multiple systems interoperability. Often Web Services need to be deployed rapidly and need to harmonies integration with new business partners or customers.

Web Services development needs customers to set priorities, define the problem domain, and make key decisions, because it is the customer who understands the process that the software is trying to emulate. Web Services system and are often new to the organization. Thus, it is hard to find an expert to consult. Customers look to their developers for guidance.

2Terminology Mapping

This section explains the terminology used in XP and how it is related to terminology used in Web Services Implementation Methodology Guideline (Public Review Draft 1.0, 6 July 2005, doc reference: ), herein refer to as WSIM Guideline. The aim is to provide a quick reference to help reader to cross reference terminology used in XP to that used in WSIM Guideline.

2.1Implementation Lifecycle


XP method defines the following phases: Planning, Design, Coding and Testing. These phases are applied in Web Services development and implementation.

Following map XP phases to Web Services phases:



XP phases

WSIM Guideline Phases [section number]

Planning

Requirement Phase [3.2]

Analysis Phase [3.3]



Design

Design Phase [3.4]

Coding

Coding Phase [3.5]

Testing

Testing Phase [3.6]

Releases

Deployment Phase [3.7]

Web Services, unlike traditional software is not meant for end-user consumption. Web Services are pieces of business logic which have programmatic interfaces and it is through these interfaces that developers can create new application systems.

XP method is extremely useful in Web Services implementation. XP method focuses on short "iterations" of two or three weeks, and you select the work to be done in each of those iterations. Your mission is to select work that will maximize the business value completed by the end of the iteration.

2.2Project Team Roles


Not know what you suppose to do will lead to disaster. Defining the role of each member is the first steps. With roles and responsibilities for team members defined, projects run much more smoothly and team morale improves.

Web Services development is different from typical XP projects and therefore the roles need to be modified for Web Services.

Here are some of the main roles that have been suggested in the XP literature.


  • The manager schedules the iteration meetings, ensures that the process is being followed, provides reporting, and removes project obstacles.

  • The customer writes and prioritizes user stories (think of stories as ideas for features) and writes acceptance criteria. She has the authority to make decisions.

  • The coach oversees the entire project to ensure that the team is following XP best practices.

  • The tracker tracks the teams' progress, helping them solve problems and warning the manager of any potential problems.

  • The programmer estimates stories, breaking them up into tasks and estimating tasks; volunteers for stories; and writes unit tests.

  • The tester helps the customer write acceptance criteria, writes and runs functional tests, and reports test results.

  • The doomsayer, or naysayer, is anyone on the team who senses a problem and brings it to the attention of the team.



Following maps the XP roles to WSIM Guideline Roles

XP suggested Roles

WSIM Guideline Roles

Programmer


Requirement Analyst, Architect, Designer, Developer

Customer

Stakeholder

Manager, Coach, Tracker

Project Manager, Deployer

Tester

Tester, Test Designer, Test Manager

Each person can play more than one role and may change roles in different phases of the project. It does not mean that you need 10 people to start a Web Services project.

2.2.1.1Roles not defined in WSIM Guideline


The doomsayer role is symbolic and played by different people at different times.

2.3Artifact Cross Reference


In XP, customer requirements are describe in the form of stories. Each story describes one thing that the system needs to do. Each story must be understood well enough that the programmers can estimate its difficulty.

Stories are similar to Requirements Specification or Use Cases but written as a narration for non-technical audience. XP places the responsibility for writing stories squarely on the customer. However, in Web Services projects customers are not the domain experts we need, so stories are written primarily by a project manager. Customers still set priorities and aid in strategy development, but this is not the traditional XP story writing practice.



On the other hand, XP doctrine does not define the artifact for the process. We will use the terminology proposed in the WSIM Guideline.

2.4Concepts not defined in WSIM Guideline


This section listed the concepts not defined in WSIM Guideline but is necessary in XP.

2.4.1Pair Programming

Pair programming, one of the pillars of XP is important in Web Services development. We started experimenting with Web Services development. First we tried pairing up interface programmer with backend developer. We manage to solve interface problem faster and the quality of code is improved. The programmers are happier and the morale of the team improved.

2.4.2Continuous Integration


XP continuous integration fosters teamwork on a Web Services development project. XP methodology is iterative and incremental.

3Implementation Phases


This section describes the implementation phases using XP terminology and doctrine.

3.1Planning: Requirement Phase & Analysis Phase

3.1.1Determine the need for Web Services [3.2.1]


An XP team plans and builds software in terms of "stories”. For a project spanning a few months, there may be 50 or 100 stories. Larger projects of course have more stories.

3.1.1.1Roles


Customer, Manager

3.1.1.2Artifacts


Stories, Business Requirements and Business Plan

Elicit Web Service requirements [3.2.2]


Stories are individual stories about how the system needs to work. Stories collected in 3.1.1 are described at a higher level and with the help of customer; the manager will break it down into sub stories with focus on requirements. Manager translates these stories into technical specification.

3.1.1.3Roles


Customer, Manager

3.1.1.4Artifacts


Stories, Requirement Specification

Manage the Web Service requirement [3.2.3]

The customer express what must be done in terms of stories. Project Manager documents these stories. Manager translates these stories into technical specification.

3.1.1.5Roles


Customer, Manager

3.1.1.6Artifacts


Stories, Requirement Specification

Model the usage scenarios [3.2.4]


Each story describes one thing that the system needs to do. Each story must be understood well enough that the programmers can estimate its difficulty. The manager translates these stories into technical specification.

3.1.1.7Roles


Customer, Manager, Programmer

3.1.1.8Artifacts


Stories, Requirement Specification

Prepare test cases for User Acceptance Test and System test [3.2.5]


And each story must be testable.

3.1.1.9Roles


Customer, Manager, Tester, Programmer

3.1.1.10Artifacts


Test Plan – UAT and System Test

Selecting a technology platform as implementation framework [3.3.1]

While many companies work on technologies on their own, we like to involve the customer. We start by walking him through the various languages and frameworks that can be employed, describing the benefits and drawbacks of each of them.

For example, it is worth the effort to provide a presentation on the advantages of an object-oriented language, the need for clustering, and the relative merits of Oracle and SQL Server to the customers. These are decisions that the customer should participate in making. Never assume otherwise because the choice of technologies used in Web Services development will affect the lifecycle of the Web Services, ongoing maintenance costs, and other real business concerns.

3.1.1.11Roles


Customer, Manager, Programmer

3.1.1.12Artifacts


None

Define a candidate structure architecture for the Web Services [3.3.2]


Once we are clear about what the customer is trying to achieve, we can discuss what direction the customer should take and types of content to be offered as Web Services.

Several options will arise that the customer has expressed interest in. The next step is to evolve these options into possible Web Services.

We can start to define a high-level architecture. Identify the components that expose functionality as Web Services.

3.1.1.13Roles


Customer, Manager, Tester, Programmer

3.1.1.14Artifacts


Software Architecture Specification

Define on the granularity of the Web Services [3.3.3]


We will start to decide on the coarseness of the Web Services operations to be exposed based on the stories gathered from the customers.

Identify the group of services and group functionality into Web Services. Decide on the mechanisms to compose or aggregate functionality.


3.1.1.15Roles


Manager, Programmer

3.1.1.16Artifacts


Software Architecture Specification

Identify reusable Web Services [3.3.4]


Identify any of the existing Web Services can provide equivalent Web Services. If the functionality can be offered by existing Web Services, then place a remark on the identified Web Services.

3.1.1.17Roles


Manager, Programmer

3.1.1.18Artifacts

Software Architecture Specification

Identify service interface contract for new Web Services [3.3.5]


Those identified Web Services that do not fixed into any of the existing Web Services then new Web Services are needed. Based on the requirements and usage model, identify its operation and signature.

3.1.1.19Roles


Programmer

3.1.1.20Artifacts


Software Architecture Specification

Prepare Test Cases for Performance Test [3.3.6]


Write procedure to test the performance.

3.1.1.21Roles


Programmer, Tester, Manager

3.1.1.22Artifacts


Test Plan – Performance Test

Prepare Test Cases for Integration / Interoperability Test [3.3.7]


Write the procedures to tests integration and interoperability.

3.1.1.23Roles


Programmer, Tester, Manager

3.1.1.24Artifacts


Test Plan – Integration and Interoperability Test

Prepare Test Cases for Functional Test [3.3.8]


Write functional test procedures. These test procedure are prepared to verify each stories gathered in the earlier steps.

3.1.1.25Roles


Programmer, Tester and Manager

3.1.1.26Artifacts


Test Plan – Functional Test

Test bed preparation [3.3.9]

At this stage, we need to setup a testing environment that includes hardware and software. This environment is similar to the production/live environment in terms of hardware, OS, Web Server and Application Server, etc.

Prepare a test system which can execute test script and capture data for analysis. This is to enable automatic testing.

3.1.1.27Roles


Tester

3.1.1.28Artifacts


Test Plan – Test Bed

Release Plan


Generating a Release Plan is as much an exercise in customer relations as it is the writing of a document. Web Services project requirements seem fairly loose to begin with, so simply spending a day with the customer usually is not enough to get all the information you need. If you want a happy customer, you need to firm up information in at least four key areas:

  • What the customer is hoping to achieve through the Web Services

  • What the best strategies are to achieve those goals

  • What technical constraints apply to the target audience for the site

  • What Web technologies are most appropriate

There are no easy answers to writing the release plan, but here is the process we have found most effective in producing successful projects. Keep it short and cover only the important issues. XP is not about generating documents.

3.1.1.29Roles


Customer, Manager, Programmer, Tester, Tracker

3.1.1.30Artifacts


Project Schedule

3.2Design Phase & Coding Phase

Transform signature of reusable Web Services [3.4.1]

We have found that Web Services design requires some closely followed best practices to further this goal:

Prototypes are useful to test and verify some concept, algorithms or methods. Prototypes are disposable and they are used for learning something and testing. Never use prototype code in production code.

To identify problems early in the project, try to complete a few simple tasks before you attempt anything complicated. Any problem will be much clearer and easier to resolve at this point.

Identify components that were developed and determine if it can be reused. Examine the data structures and mapped to existing components if necessary.

3.2.1.1Roles


Programmer

3.2.1.2Artifacts


Software Design Specification

Refine service interface of the new Web Services [3.4.2]


Programme code need to be reviewed regularly and enhance them if needed. Regular housecleaning is also need.

3.2.1.3Roles


Programmer

3.2.1.4Artifacts


Software Design Specification

Design Web Services [3.4.3]


Study the customer stories gathered in the Requirements and Analysis Phase. Write each story on a stick pad. The Programmer or Designer make sure he understands what the customers needs then draw up boxes of logical functions of Web Services. Then sticks each stories into the most appropriate function boxes.

3.2.1.5Roles


Programmer

3.2.1.6Artifacts


Software Design Specification

Refine Test Cases for Functional Test [3.4.4]


Review the test procedure prepared at section 2.1.13 is refined into detail test steps which include test data to be tested.

3.2.1.7Roles


Programmer, Tester, Manager

3.2.1.8Artifacts


Test Plan – Functional Test

Code internal workings of Web Services [3.5.1]

Coding is so much more than just sitting in front of the computer and typing. Coding is problem solving and requires a great deal of attention and creativity. There are so many obstacles to turning the design into code.

In Extreme Programming, the emphasis is on programming. We will focus on developing optimal code and modular.

Pair programming is useful at this stage; the programmer working on the Web Services Consumer Code will work with the programmer working on the Web Services Server code.

3.2.1.9Roles


Programmer

3.2.1.10Artifacts


Software source code

Write the Web Services Consumer Code [3.5.2]


This task will be relatively easy as the programmer is very familiar with the Web Services Interfaces. The programmer needs to focus on Web Services Client programming model to use.

3.2.1.11Roles


Programmer

3.2.1.12Artifacts


Software source code

Unit Test Web Services [3.5.3]

At this stage, deploy the Web Services in local test environment and perform functional unit testing. The emphasis is on the correctness of the functionality and the exceptions handling.

We can adopt the technique of “Test first by intention”. Prepare a set of test data to input to the system and check against the output to see that it is correct. We need to perform data boundaries check to see if the Web Services fail. Proceed to solve the problem when each test step failed. When the test works, move on to the next.

We are trying to test everything that could possibly break in this object. We want to make sure that every sections of the code are tested. For example, every if and case loop must be executed. The Tester and Programmer can pair up to do the test together. Programmer focuses on debugging and writing the code while the Tester writes the test scripts.

Write these test as script so that the tests can be repeated every time we need to change a section of the code.

Automated testing is done for unit tests. These are small tests that allow programmer to test the method in the objects on a pass or fail basis. Every public methods or function calls are tested. These set of tests are useful when changes is made on the object. We can see immediately when something breaks.

As Web Services systems can get larger and single changes in one place can caused havoc to the whole system. It is very difficult debug in a system level so unit tests are a reliable way to test and ensure that all the code are tested before deployment.

3.2.1.13Roles


Tester

3.2.1.14Artifacts


Test scripts

3.3Test Phase

Test Functionality of Web Services [3.6.1]


Functional tests focus on basic Web Services Functionality. As each component objects are tested in the unit test, functional tests focus on the expected operations of the Web Services using the respective components. It also test the interface of various components used to implement Web Services functions.

Some projects have a legacy system they are replacing, and they can get their test data from the legacy system. In this case, your job will be to select the legacy inputs and outputs you want tested. Some projects use spreadsheets from the customer that provide the inputs and expected outputs. Smart XP programmers will extract the information from the spreadsheet automatically and read it into the system. Some projects use manually calculated values that are typed in by someone on the team.

The format of SOAP messages are verified and should be in compliance with the specification. Test results shall be automatically logged and compare with the expected.

The test procedures prepared in the earlier phase are carried out as check list to certify that the system is functioning as specified.


3.3.1.1Roles


Tester

3.3.1.2Artifacts


Test Scripts

Integrated Test on the Web Services [3.6.2]

Some customers give input numbers to the programmers and check the output by just reading it. There is an important issue with this method. Checking the output of a computer is very error-prone. It's easy to look at the numbers and decide that they look correct. It's also easy to be wrong when you do that. It is better to have the expected answers up front, even if they have to be computed by hand.

At this stage, business partners are invited to participate in the tests. Test for conformance to Web Services Interoperability Organization (WS-I) is recommended. Test scripts are prepared and data according to the test cases based on the WS-I recommendations.

Tests are performed based on various scenarios. The tests first focus on passed or fail based and progresses to test for performance.

3.3.1.3Roles


Tester

3.3.1.4Artifacts


Test Scripts

System test on the Web Services [3.6.3]


All tests in an XP project must be automated. It gives you the ability to move very rapidly, and to change your requirements any time you need to. This means that the code will be changing rapidly. The only way to move rapidly with confidence is to have a strong network of tests that ensure that changes to the system do not break things that already work.

System test checks for overall system functionally which include all the components that made up the system. In this stage, the system response time is checked under different expected load. Data are captured to analyse to determine potential bottlenecks and if the system is scalable to meet these unexpected demand.


3.3.1.5Roles


Tester

3.3.1.6Artifacts


Test Scripts

User Acceptance Test on the Web Services [3.6.4]


Acceptance tests really need to be available in the same iteration as the story is scheduled. You want to score the development based on getting stories done, and the only way to know if they are really done is to run the tests.

3.3.1.7Roles


Customer, Manager, Programmer, Tester, Tracker

3.3.1.8Artifacts


Test Scripts, Test Procedures and Check list

3.4Deployment Phase

Prepare deployment environment [3.7.1]

One of the most important things you can do on an XP project is to release early and release often. Each independent module is released to allow customer to use. However care must be taken to make sure that each release is properly tested.

Each release provides an opportunity for the customer to try out the application and give you feedback. We would learn a lot about what customer really wanted.

3.4.1.1Roles


Manager, Programmer, Tracker, Customer

3.4.1.2Artifacts


Deployment Plan

Deploy Web Services [3.7.2]


At this stage, we are ready for deployment. The services URL is gathered from the customer and verifies that it is unique.

Prepare a deployment script. Deployment script is used to determine the steps of deployment. Deployment scripts are also used for future redeployment of systems due to hardware or operating system upgrade as well as disaster recovery. XP is light on documentation and deployment script defined the installation procedure in detail.


3.4.1.3Roles

3.4.1.4Artifacts

Test Deployment [3.7.3]


The Web Service is ready to put into operation. User accounts are setup and production data are imported into the system.

The functionality of the Web Services is properly tested and there is no need to test all the operation. This stage will focus on actual client consumption of services. The invocation of clients services from participating business partners or users are tested and the return results are checked against results obtained from current method.

If there are discrepancies, the data are checked to determine the source of error. It could be due to error data generated due to current method or there are errors in the Web Services.

3.4.1.5Roles


Programmer

3.4.1.6Artifacts


WSDL, Deployment Script, Software Object Code

Create end user support material [3.7.4]

User manual are generated to help users to understand and use the Web Services. For example, the user manual describes how to invoke the various services.

Managing the assets of the project is also important. Assets includes source codes, all test scripts, diagrams, test procedures, customer stories must be properly documented and archived

3.4.1.7Roles


Customer, Manager, Tester, Programmer

3.4.1.8Artifacts


User Guide, Installation Manual, Training Material, On-line help

Publish Web Services [3.7.5]


At this stage, depending on the requirement, the Web Services is ready to be published on the UDDI registry. The customers will decide whether a private or public UDDI registry is needed and the version of the UDDI Business Registry specification to follow.

Prepare the information needed for publishing. Information may include key words for searching, description of Web Services URL of WSDL file, etc.

Publish the Web Services to the UDDI registry. Normally this is done through the Web Browser. Verify that it is properly registered by performing a search through browser or tools provided by the vendors.

3.4.1.9Roles


Programmer

3.4.1.10Artifacts


None

4Reference


  • Web Services Implementation Methodology Public Review Draft, 6 July 2005 (doc reference: fwsi-im-1.0-guidelines-doc-wd-01b.doc)

  • Web Services Implementation Methodology – Guide for Submitting Case Example, Working draft 03, 14 August 2005 (doc reference: fwsi-im-1 0-ExampleGuide-doc-wd-03.doc)


  1. Acknowledgments


The following individuals were members of the committee during the development of this specification.

Andy TAN, Individual

Chai Hong ANG, Singapore Institute of Manufacturing Technology

Eng Wah LEE, Singapore Institute of Manufacturing Technology


Puay Siew TAN, Singapore Institute of Manufacturing Technology

Yushi CHENG, Singapore Institute of Manufacturing Technology

Xingjian XU, Singapore Institute of Manufacturing Technology



Zun Liang YIN, Singapore Institute of Manufacturing Technology



Roberto PASCUAL, The Infocomm Development Authority of Singapore

JAGDIP Talla, CrimsonLogic Pte Ltd

RAVI SHANKAR Narayanan Nair, CrimsonLogic Pte Ltd

Marc HAINES, individual

  1. Revision History


Rev

Date

By Whom

What

Draft 01

25 Nov 2004

Andy Tan

Initial Draft

Draft 02

16 Dec 2004

Andy Tan

Corrected spelling errors and completed roles and artifacts.

Draft 03

04 Feb 2005

Andy Tan

Using the Case Example Guide template

Draft 04

14 Aug 2005


Andy Tan

Modify document to fulfil section 3.1.6.1 of WSIM Guide for Submitting Case Example requirement to include cross reference to the activities defined in the generic Web Services Activities in WSIM Guideline.


  1. Notices

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

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

Copyright © OASIS Open 2002. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined 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 be revoked by OASIS or its successors or assigns.

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



14-Aug-05

Copyright © OASIS Open 2005. All Rights Reserved. Page of







The database is protected by copyright ©hestories.info 2017
send message

    Main page