Framework for Web Services Implementation (FWSI)

Tan Puay Siew

Framework for Web Services Implementation (FWSI) TC

Framework for Web ServicesImplementation (FWSI)

Towards an OASIS Standard

Ebsoa TC Meeting12 May2005

Tan Puay Siew

2Framework for Web Services Implementation (FWSI) TC

FWSI TC Formation• FWSI TC (Framework for Web Services Implementation)

– SIMTech (Singapore Institute of Manufacturing Technology) and IDA (Infocomm Development Authority of Singapore) are co-chairs

– Secretariat provided by ITSC (Information Technology Standards Committee, Singapore)

– Launched in Singapore on 29 September 2003 by Mr. Patrick Gannon, President & CEO, OASIS

• Local Companies Participation– CrimsonLogic, Ecquaria, eG Innovations, ESS Software, GridNode,

Readiminds and Singapore Computer Systems

• MNCs/International Organisations– Oracle, Sterling Commerce, Sun Microsystems, NEC Asia Pacific

– Amberpoint, Argonne National Laboratory, BTplc, ETRI, Korean National

Computerization Agency, University of Hong Kong, Rosettanet, etc.


The purpose of OASIS FWSI TC is to facilitate implementation of robust Web Services

by defining a practical and extensible methodology consisting ofimplementation processes & common functional elements

that practitioners can adopt to create high quality Web Services systems without re-inventing them for each implementation.

More Information at http://www.oasis-open.org/committees/fwsi/charter.php

FWSI TC - Objective

‘Defining methods and functional components (elements) for broad, multi-platform, vendor-neutral, cross-industryImplementation of web services


Status of FWSI TC

• Completed FWSI Functional Element (FE) Specifications – November 2004.

– Approved as Committee Specification – December 2004– Plan : To develop Committee Specification into OASIS Standard (March

2006)

• Work in Progress : Web Services Implementation Methodology Guidelines ( Target – mid May 2005)

– Plan – Public Review (mid-June 2005)

• Organisation adopting FE Spec. – SIMTech (WSCS)


• Monthly Teleconferencing Meeting– with skype.net Internet Telephony; for those wishing to discuss via Internet

• Face to Face Meeting in US– 1st f-2-f meeting in Philadephia (December 2003) in conjunction with XML 2003 Symposium– 2nd f-2-f meeting in New Orleans (April 2004) in conjunction with OASIS Symposium 2004– 3rd f-2-f meeting in New Orleans (April 2005) in conjunction with OASIS Symposium 2005

• To-date hosted 16 FWSI TC Meetings, 14 FWSI FE Sub-committee Meetings and 12 IM sub-Committee Meetings

FWSI TC Meetings

Tan Puay Siew


Functional Elements Specification

Towards an OASIS Standard

FWSI Forum06 April 2005

Tan Puay Siew


• Overview– Intent of Functional Element (FE) Specification– What is a Functional Element?– Positioning of FE Specification– Scope of FE Specification

• Functional Elements Specification 1.0– Approach Used– Functional Elements

• Identified FEs• Format of Specification

– Sample Usage Scenarios

• Moving Forward – Towards FE Specification 2.0– Work plan– Call to Action

Contents


Intent of FE Specs (1)

• Objective– To specify a set of common functional elements that practitioners

can adopt to create high quality Web Services systems • To accelerate implementation and adoption of Web Service-based

systems• To reduce the complexity of building such systems

– Hence, reduce the developmental and maintenance costs

• Improve understanding of web services implementations

• Why? – Promote reuse and build a common base layer

• Many common elements can be found across implementations– More so in SOA-based implementations like web services

• Web Services require special set of infrastructural elements that are common


Intent of FE Specs (2)

• Target Audience

– Solution Providers• Eg: To create building blocks that can be instantiated into the

technical architecture of their solutions

– Vendors & ISVs (Application Servers, Software Products, etc. )• Eg: Build functionalities specified into their products


What is a Functional Element?

A Functional Element is a

• building block representing common re-usable functionalities

- for web service-enabled implementations- without re-inventing them for each implementation

• expected to be implemented as re-usable components with web services capabilities where appropriate


Functional Elements As Building BlocksEach Component has a role to play (basic functionality as SERVICES)

A product is an Assembly of Components

Each Component may serve its role in many instances in a product (reusability)

Engine Block Assembly

A Software Application is an Assembly of SERVICES


IdentityManagement

ServiceManagement

Secure SOAPManagement

User Management

Log Management

NotificationEngine

To be built

Payment LogisticsParts

Catalogue

OrderProcessing

ProductsInformation

Functional Elements

Instantiated Functional Elements As Reusable Components in a

Service-Oriented Architecture (SOA)

Functional Elements Usage


WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

……

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

psWeb Service

Applications

Functional Elements Positioning

FWSI Functional ElementsFunctional ElementsFunctional ElementsFunctional Elements

Relationship of FWSI Functional Elements with• W3C’s Web Service Architecture• J2EE Web Service Specifications, Microsoft .NET Framework• Vendor Products, Open-Source Products• Web Service Enabled Application Development

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

……

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

WS

-Ap

ps

Web ServiceApplications

App Servers, Web Servers, Middleware, DatabasesApp Servers, Web Servers, Middleware, DatabasesSoftware

W3C Web Services Architecture (WSA)Web Services Architecture (WSA)Web Services Architecture (WSA)Web Services Architecture (WSA)

Web Services (J2EE, .NET, etc.)Web Services (J2EE, .NET, etc.)Platform


Scope of Functional Elements

Existing Standards

& Technologies

UDDILAP Specification

WS-Federation…WS-Security

WS-Policy

WS-Trust

WS-Privacy

SMS/SMTP

Secure SOAPManagement

IdentityManagement

ServiceManagement

FunctionalElement …Service

Tester

…Management SecurityRequirements


• What IS included ?– Specification will include details of features / capabilities in each functional

element identified

– Where appropriate, details of the interaction among the various functional elements (Sample Usage Scenarios) will be illustrated to emphasize the intentions.

• What IS NOT included ?– The specification will not include implementation details of each identified

functional element

– FE Specs Compliant Implementations of the functional elements will be done separately, outside the work of this TC

Scope – FE Specs Coverage







Contents


Approach – Use Case Approach

Requirements

req1

req3

req5

req7

req2

req4

req6

req8

Requirements

Functional Elements

Services

svc1

svc2

svc3

svc4

Features

f1

f3

f6

f8

f2

f4

f7

f9

f10

f5

Management

Process

Security

Delivery

Categories

(Version 1.0)


Identified Functional Elements1. Event Handler

2. Group Management

3. Identity Management

4. Log Utility

5. Notification

6. Phase & Lifecycle Management

7. Presentation Transformer

8. Role & Access Management

9. Search

10.Secure SOAP Management

11.Sensory

12.Service Management

13.Service Registry

14.Service Tester

15.User Management

16.Web Service Aggregator

Each FE is to be implemented into independent componentsbased on the SOA model (web services)

[Except where dependencies are explicitly specified]


Format of Specification

• Motivation• Terms Used• Key Features (Normative)• Inter-Dependencies• Related Technologies and Standards• Use Case Model • Usage Scenarios


Client Server

Service Management• Monitors server side performance metric • Generates invocation audit trail

Database

Service Tester• Monitors client side performance metric • Tests the availability of an operation

XM

L-R

ule

En

gin

e

• Send alerts to administrator via SMS, paging and emails

Any Server

Notification Engine

Client Devices

Scenario 1 –Service Monitoring Solution

SOAP RequestSOAP Response

Server Hostingthe ServicesClient

Any ServerAny Client


Circle

of Trust

Circle of Tru

st

Identity Provider

Identity Management

User Access Management

Holiday

Visa Rewards

Business Trip

Traveler

Secure SOAP Management

Scenario 2 -Identity Management Solution







Contents


Major FESC Milestones

Jan-Mar Apr-Jun Jul-Sep Oct-Dec Jan-Mar2005

FE

Im

pl-

0116

Mar

FE

Im

pl-

02 &

Imp

l-03

28 S

ep

FE

Sp

ecs,

Co

mm

. D

raft

Ver

2.0

30 N

ov

2006

FW

SI

Fo

rum

Ap

r 06

Towards FE

Standard

• This serves as a guide of working towards the major goals• At each quarter, a more detailed schedule will be mapped


Workplan for FE Specs version 2.0

Apr-Jun Jul-Sep Oct-Dec Jan-Mar

FE Impl-02 & Impl-0328 Sep

FE

Sp

ecs,

Co

mm

. S

pec

s V

er

2.0

30 N

ov

2006

Cal

l fo

r C

on

trib

uti

on

@

FW

SI

Fo

rum

06 A

pr Towards FE

Standard

Work Sequence:1. Call for contributions on Potential Area/FEs2. Requirements Consolidation3. FE Specs & Voting as Comm. Specs.

FE

Are

as/L

ist

18 M

ay

FE

Lis

t C

om

ple

ted

20 J

ul

FE

Sp

ecs,

WD

-02-

0216

No

v (F

or

Vo

tin

g)

Req

uir

em

ents

Do

c, v

er.

2.0

21 S

ep

FE

Sp

ecs,

WD

-02-

0119

Oct


Call To Action / Contributions

For FE Specifications (FES) 2.0– Potential Areas – Potential FEs– Current FE Refinements– Either as requirements or direct contributions to the FES 2.0

FE Specs compliant IMPLEMENTATIONS– WSCS from SIMTech– Need more FES compliant implementations

• Working towards OASIS Standard in 2006OASIS

STANDARD

Tan Puay Siew


FWSI Implementation Methodology


www.oasis-open.org

Approach

• Rather than defining a new methodology, the approach is to leverage on any existing agile software methodology and extend that methodology by defining only the web services-specific activities.

• Any well-defined agile software implementation methodology could potentially be a candidate (eg. XP, FDD, RUP, etc)

Deliverable: A generic web services implementation methodology that defines web services-specific activities that can be incorporated into any agile software methodology.


www.oasis-open.org

Adapting an agile methodology• Incorporate web services specific tasks, eg.

– Analysis & Design• Signature Mapping: Between APIs & Web Services Interfaces• Server Component Models: RPC or Doc-style• Interaction Modes: Synchronous / asynchronous• Client Invocation Models:

– Static stub / dynamic proxy / dynamic invocation interface• Interoperability, Performance, Security

– Testing• Message-level (SOAP) testing of services• Interoperability testing to ensure compliance to standards

• Specify web services artifacts, eg.– WSDLs– Client Stubs

Deliverables: Case examples for adapting specific software methodologies for web services-specific implementation activities.


www.oasis-open.org

Web Services-Specific Activities (An illustration)

Requirements Analysis Design Code Test Deployment

Requirement Specs

Use Case Specs

CodesTest

Procedures / Scripts

Test Data

Test Results

Deployment Scripts

Architecture Specs

Detailed Design Specs

Deliverables by IMSC(web services-specific activities)

Leverage on an agile software development methodology

• Gather system requirements and classify functionalities in terms of services

• Gather non-functional requirements like web service security, interoperability, etc.

• …

• Identify web service interfaces

• Determine if available web services are reusable

• …

• Leverage on Functional Element Specs for commonly used services

• Design new services using SOA

• …

• Consider web service implementation specifics (e.g. standards to follow, rpc/document style, sync/async invocation etc.)

• Integrate and orchestrate complex services

• …

• Perform local/remote functionality test, performance test, stress test etc.

• Perform interoperability test

• Perform integration / orchestration test

• …

• Determine service URL (private/public accessibility)

• Publish service in a UDDI registry (if discovery is required)

• …


www.oasis-open.org

Web ServicesImplementation Methodology

Web ServicesRequirements

Web ServicesAnalysis

Web ServicesDesign

Web ServicesCoding

Web ServicesTesting

Web ServicesDeployment

Leverage on Existing

Agile Software

Development MethodologyIteration 1 .. n


www.oasis-open.org

Web ServicesImplementation Methodology (1)



Web ServicesDesign

Web ServicesCoding

Web ServicesTesting



Agile Software


•Determine Need for WS

•Elicit WS Requirements

•Manage WS Requirements

•Model Usage Scenarios

•Prepare Test Cases for User Acceptance Test and System Test

•Determine Need for WS

•Elicit WS Requirements

•Manage WS Requirements

•Model Usage Scenarios



www.oasis-open.org

Model usage scenarios

• Translate functional requirements into conceptual usage models, using analysis modeling techniques.

• Specify major interaction scenarios with WS clients:– Highlight usage of WS involved, eg. message exchange scenarios should

be captured.


www.oasis-open.org




Web ServicesDesign

Web ServicesCoding

Web ServicesTesting



Agile Software


•Select Technology Platform as Implementation Framework

•Define Candidate Architecture for WS

•Decide on Granularity of WS

•Identify Reusable WS

•Identify Service Interface for New WS

•Prepare Test Cases for Performance Test

•Prepare Test Cases for Integration/Interoperability Test

•Prepare Test Cases for Functional Test

•Testbed Preparation

•Select Technology Platform as Implementation Framework

•Define Candidate Architecture for WS

•Decide on Granularity of WS

•Identify Reusable WS

•Identify Service Interface for New WS

•Prepare Test Cases for Performance Test

•Prepare Test Cases for Integration/Interoperability Test

•Prepare Test Cases for Functional Test

•Testbed Preparation


www.oasis-open.org

Identify reusable WS

• Identify architectural components realisable with existing WS (company-owned or third-party) so as to re-use existing services where feasible.

• Identify providers for the reusable WS:– Gather information about the providers.– Define major invocation scenarios of re-use.

• Identify functions to be re-used and define the invocation interface.


www.oasis-open.org

Identify service interface for new WS

• Define new WS operation signatures based on usage and analysis models.

• If message exchange is involved, define XML schema that governs the message structure.


www.oasis-open.org




Web ServicesDesign

Web ServicesCoding

Web ServicesTesting



Agile Software


•Transform Signatures of existing WS to be reused

•Refine Service Interface of New WS

•Design WS

•Refine Test Cases for Functional Test


•Transform Signatures of existing WS to be reused

•Refine Service Interface of New WS

•Design WS

•Refine Test Cases for Functional Test



www.oasis-open.org

Transform signatures of existing WS to be reused

• Identify data type mapping if parameters of the re-used WS is not directly supported by the identified platform of current implementation.

• Identify design patterns for data mapping, eg. – Adapter pattern, to expose a new interface for an existing WS.– Façade pattern, to encapsulate complexity of existing WS and provide a

coarse-grained WS.


www.oasis-open.org




Web ServicesDesign

Web ServicesCoding

Web ServicesTesting



Agile Software


•Construct WS Code

•Construct WS Client Code

•Unit Test WS

•Construct WS Code

•Construct WS Client Code

•Unit Test WS


www.oasis-open.org

Construct WS code

• Consider constraints imposed by programming language, eg. language-dependent data types.

• Expose public APIs as WS interface, eg.– In Java, create interface class to expose the class method as a WS

operation.– In .NET, annotate class API as a [WebMethod].

• Generate WSDL for client to consume.– Most IDEs do this automatically, given the interface code.


www.oasis-open.org

Construct WS client code

• Choose WS client programming model:– Static stub– Dynamic proxy– Dynamic invocation interface (DII)

• Write client code.


www.oasis-open.org




Web ServicesDesign

Web ServicesCoding

Web ServicesTesting



Agile Software


•Functionality Test on WS

•Integration Test on WS

•System Test on WS

•User Acceptance Test on WS

•Functionality Test on WS

•Integration Test on WS

•System Test on WS

•User Acceptance Test on WS


www.oasis-open.org

Functionality test on WS

• Test basic WS functionality, eg. compliance with SOAP, WSDL specs; exception handling, etc.

• Test security requirements, eg. level of privacy, authentication methods, etc.

• Test UDDI publishing, look-up and binding (if required).

• Others…


www.oasis-open.org

Integration test on WS

• Test for conformance to WS-I Basic Profile recommendations.

• Platform-level interoperability testing.

• Others…


www.oasis-open.org




Web ServicesDesign

Web ServicesCoding

Web ServicesTesting



Agile Software


•Prepare Deployment Environment

•Deploy WS

•Test Deployment

•Create End User Support Material

•Publish WS

•Prepare Deployment Environment

•Deploy WS

•Test Deployment

•Create End User Support Material

•Publish WS


www.oasis-open.org

Prepare deployment environment

• Set up and configure hardware environment.

• Set up and configure software environment, eg. DBMS, application/web server with SOAP listener, etc.


www.oasis-open.org

Deploy WS

• Determine and set up service URL.

• Prepare and execute deployment script (container-dependent).

• Publish WS, ie. UDDI-related interactions.


www.oasis-open.org

Why should I adopt this?

• Having a practical and extensible Web Services Implementation Methodology as a reference for development and deployment

– Improves understanding of web services implementations– Reduces the risk of implementations (avoiding common pitfalls)– Improves the robustness of web services-enabled systems– Provides a comprehensive testing framework

• Extends the benefits of a formal software implementation methodology to web services projects.


Thank You

http://www.oasis-open.org/Click on Web Services -> FWSI

Documents

Framework for Web Services Implementation (FWSI)