Framework for Web Services Implementation (FWSI)

1
Framework for Web ServicesImplementation (FWSI)

• Towards an OASIS Standard

Ebsoa TC Meeting 12 May2005
Tan Puay Siew
2
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.

3
FWSI TC - Objective
The purpose of OASIS FWSI TC is to facilitate
implementation of robust Web Services by
defining a practical and extensible methodology
consisting of implementation 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/comm
ittees/fwsi/charter.php
Defining methods and functional components
(elements) for broad, multi-platform,
vendor-neutral, cross-industry Implementation of
web services
4
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)

5
FWSI TC Meetings

• 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

6
Functional Elements Specification

• Towards an OASIS Standard

FWSI Forum 06 April 2005
Tan Puay Siew
7
Contents

• 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

8
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

9
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

10
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

11
Functional Elements As Building Blocks
Engine Block Assembly
A Software Application is an Assembly of SERVICES
A product is an Assembly of Components
12
Functional Elements Usage
Identity Management
Service Management
Secure SOAP Management
Functional Elements
User Management
Log Management
Notification Engine
Instantiated Functional Elements As Reusable
Components in a Service-Oriented Architecture
(SOA)
13
Functional Elements Positioning

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

14
Scope of Functional Elements
15
Scope FE Specs Coverage

• 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

16
Contents

• 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

17
Approach Use Case Approach
Requirements
18
Identified Functional Elements

1. Event Handler
2. Group Management
3. Identity Management
4. Log Utility
5. Notification
6. Phase Lifecycle Management
7. Presentation Transformer
8. Role Access Management

1. Search
2. Secure SOAP Management
3. Sensory
4. Service Management
5. Service Registry
6. Service Tester
7. User Management
8. Web Service Aggregator

Each FE is to be implemented into independent
components based on the SOA model (web
services) Except where dependencies are
explicitly specified
19
Format of Specification

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

20
Scenario 1 Service Monitoring Solution
Client
21
Scenario 2 -Identity Management Solution
22
Contents

• 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

23
Major FESC Milestones
FE Specs, Comm. Draft Ver 2.0 30 Nov
FE Impl-02 Impl-03 28 Sep
FWSI Forum Apr 06
Towards FE Standard
FE Impl-01 16 Mar
Jan-Mar
Apr-Jun
Jul-Sep
Oct-Dec
Jan-Mar
2005
2006

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

24
Workplan for FE Specs version 2.0
FE Specs, Comm. Specs Ver 2.0 30 Nov
Requirements Doc, ver. 2.0 21 Sep
Call for Contribution _at_FWSI Forum 06 Apr
FE Specs, WD-02-01 19 Oct
FE Specs, WD-02-02 16 Nov (For Voting)
FE List Completed 20 Jul
FE Areas/List 18 May
Towards FE Standard
Apr-Jun
Jul-Sep
Oct-Dec
Jan-Mar
2006
FE Impl-02 Impl-03 28 Sep

• Work Sequence
• Call for contributions on Potential Area/FEs
• Requirements Consolidation
• FE Specs Voting as Comm. Specs.

25
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 2006

26
FWSI Implementation Methodology
27
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.
28
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.
29
www.oasis-open.org
Web Services-Specific Activities (An illustration)

• 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)

Deliverables by IMSC (web services-specific
activities)
Requirements
Analysis
Design
Code
Test
Deployment
Leverage on an agile software development
methodology
Requirement Specs
Codes
Test Procedures / Scripts
Deployment Scripts
Use Case Specs
Detailed Design Specs
Architecture Specs
Test Data
Test Results
30
www.oasis-open.org
Web ServicesImplementation Methodology
Web Services Analysis
Web Services Design
Web Services Requirements
Leverage on Existing Agile Software
Development Methodology
Iteration 1 .. n
Web Services Coding
Web Services Deployment
Web Services Testing
31
www.oasis-open.org
Web ServicesImplementation Methodology (1)

• Determine Need for WS
• Elicit WS Requirements
• Manage WS Requirements
• Model Usage Scenarios
• Prepare Test Cases for User Acceptance Test and
  System Test

Web Services Analysis
Web Services Design
Web Services Requirements
Leverage on Existing Agile Software
Development Methodology
Iteration 1 .. n
Web Services Coding
Web Services Deployment
Web Services Testing
32
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.

33
www.oasis-open.org
Web ServicesImplementation Methodology (2)

• 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/Interoperabilit
  y Test
• Prepare Test Cases for Functional Test
• Testbed Preparation

Web Services Analysis
Web Services Design
Web Services Requirements
Leverage on Existing Agile Software
Development Methodology
Iteration 1 .. n
Web Services Coding
Web Services Deployment
Web Services Testing
34
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.

35
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.

36
www.oasis-open.org
Web ServicesImplementation Methodology (3)

• Transform Signatures of existing WS to be reused
• Refine Service Interface of New WS
• Design WS
• Refine Test Cases for Functional Test
• Prepare Test Cases for User Acceptance Test and
  System Test

Web Services Analysis
Web Services Design
Web Services Requirements
Leverage on Existing Agile Software
Development Methodology
Iteration 1 .. n
Web Services Coding
Web Services Deployment
Web Services Testing
37
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.

38
www.oasis-open.org
Web ServicesImplementation Methodology (4)
Web Services Analysis
Web Services Design
Web Services Requirements
Leverage on Existing Agile Software
Development Methodology

• Construct WS Code
• Construct WS Client Code
• Unit Test WS

Iteration 1 .. n
Web Services Coding
Web Services Deployment
Web Services Testing
39
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.

40
www.oasis-open.org
Construct WS client code

• Choose WS client programming model
• Static stub
• Dynamic proxy
• Dynamic invocation interface (DII)
• Write client code.

41
www.oasis-open.org
Web ServicesImplementation Methodology (5)
Web Services Analysis
Web Services Design
Web Services Requirements
Leverage on Existing Agile Software
Development Methodology
Iteration 1 .. n
Web Services Coding
Web Services Deployment

• Functionality Test on WS
• Integration Test on WS
• System Test on WS
• User Acceptance Test on WS

Web Services Testing
42
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

43
www.oasis-open.org
Integration test on WS

• Test for conformance to WS-I Basic Profile
  recommendations.
• Platform-level interoperability testing.
• Others

44
www.oasis-open.org
Web ServicesImplementation Methodology (6)
Web Services Analysis
Web Services Design
Web Services Requirements
Leverage on Existing Agile Software
Development Methodology

• Prepare Deployment Environment
• Deploy WS
• Test Deployment
• Create End User Support Material
• Publish WS

Iteration 1 .. n
Web Services Coding
Web Services Deployment
Web Services Testing
45
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.

46
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.

47
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.

48
Thank You
http//www.oasis-open.org/ Click on Web Services
-gt FWSI