1 / 48

Framework for Web Services Implementation (FWSI)

Framework for Web Services Implementation (FWSI). Towards an OASIS Standard. Ebsoa TC Meeting 12 May2005. Tan Puay Siew. FWSI TC Formation. FWSI TC (Framework for Web Services Implementation)

fawzia
Download Presentation

Framework for Web Services Implementation (FWSI)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 HongKong, 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/committees/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. Each Component has a role to play (basic functionality as SERVICES) Each Component may serve its role in many instances in a product (reusability) Functional Elements As Building Blocks Engine Block Assembly A Software Application is an Assembly of SERVICES A product is anAssembly of Components

  12. To be built Order Processing Products Information Payment Logistics Parts Catalogue 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. … Web Service Applications Web Service Applications WS-Apps WS-Apps WS-Apps WS-Apps WS-Apps WS-Apps WS-Apps WS-Apps … WS-Apps WS-Apps WS-Apps WS-Apps WS-Apps WS-Apps Functional Elements FWSI Web Services Architecture (WSA) W3C App Servers, Web Servers, Middleware, Databases Software Web Services (J2EE, .NET, etc.) Platform Functional Elements Positioning • 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

  14. … Requirements Management Security … Functional Element Secure SOAP Management Identity Management Service Management Service Tester … Existing Standards & Technologies WS- Privacy WS- Trust WS- Policy UDDI SMS/ SMTP LAP Specification WS-Federation WS-Security 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 ISNOT 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. Functional Elements Features Requirements Services Categories req1 Management f1 svc1 req2 f2 req3 Process f3 svc2 f4 req4 f5 req5 Security f6 svc3 req6 f7 req7 Delivery f8 svc4 f9 req8 (Version 1.0) f10 Approach – Use Case Approach Requirements

  18. Event Handler Group Management Identity Management Log Utility Notification Phase & Lifecycle Management Presentation Transformer Role & Access Management Search Secure SOAP Management Sensory Service Management Service Registry Service Tester User Management Web Service Aggregator Identified Functional Elements 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. SOAP Response SOAP Request Service Management • Monitors server side performance metric • Generates invocation audit trail Client Devices Database XML-Rule Engine Service Tester • Monitors client side performance metric • Tests the availability of an operation Notification Engine • Send alerts to administrator via SMS, paging and emails Any Client Scenario 1 –Service Monitoring Solution Client

  21. Traveler of Trust Circle Holiday Identity Provider Business Trip of Trust Circle Secure SOAP Management Identity Management User Access Management Visa Rewards 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 @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. OASIS STANDARD 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/Interoperability 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 -> FWSI

More Related