Practical Web Service Design and Development Revathi R Sonata Software

Topics Covered Why Web Services? Web Services – Key perspectives Difference between Service Design and OO Design Different scenario Service Design Principles Web Service Development Framework Web Service Design and Development Best Practices 1

Why Web Services Identified by a URI Interfaces defined using XML Can be DISCOVERED by other systems 2 Advantages StatelessStandards basedDiscoverable in the run time Drawbacks Challenges for interactive response Not leveraging Client Side Computing Power Performance

Web Services – Key Perspectives Important role to realize the ROI for Investments in SOA Key Component of SOA Also viewed as the comprehensible candidate for “Service” Layer in multitier applications – though this is contestable! Key Business Layer Candidate Bridge between Legacy and Modern Technologies Technology Bridge 3

Service Oriented Design vs Object Oriented Design Object OrientationService Orientation Increased Business Requirements Fulfillment, Increased Robustness Increased Extensibility, Increased Flexibility, Increased Reusability and Productivity Open - Closed Principle (OCP), Don't Repeat Yourself (DRY) Single Responsibility Principle (SRP), Delegation, Association, Composition Aggregation Encapsulation, Inheritance, Generalization and Specialization, Polymorphism, Abstraction Specialization through Granularity, Abstraction for Information hiding Polymorphism through ESB Principles bounded by RPC Technology / LanguageNo such boundary Object - orientation evolved out of approaches that include procedural programming Service - orientation builds upon the object - oriented design paradigm with certain Influences (EAI,BPM etc) Application centricEnterprise centric Classes, Objects, Methods, Attributes….Technical Interface, Stateless Operations, Schema Definitions….. 4

Key factors In Web Service Design and Development Selecting the right Framework for Implementation In Designing and Implementing Adhering to the well established Design Principles and Patterns for Web Services Understanding the System and the Context of Web Services System Service Design Principles Dev Frame- work Avoiding Well known Pitfalls 5

System Considerations Are Web Services proposed for Process Automation? Are Web Services proposed for providing Integration with external Systems? Are Web Services proposed as part of individual Applications? Non - Functional Requirements (Performance, Reliability and Availability, Authentication and Authorization) Support of the Vendors in terms of Tools and TechnologiesStandards to be Complied to 6

Web Services for Process Automation Design Services Entity ServicesTask / Business Services Design Message Input MessageOutput Message Design Inputs Process Design Participating systems Authentication and Authorization Requirements Performance Requirements Error/Fault Handling Requirements Utility Services 7

Web Services for B2B Interaction Design Services Internal ServicesTask / Business Services and Routing Design Message Input MessageOutput Message Design Inputs Confidentiality and Integrity of Data Transmitted via Web protocols Target Consumers and Normalized Specifications Availability Utility Services 8

Web Services for Application (e.g. RIA, Portals, Mobile) Design Services Application Services Design Message RequestResponse Design Inputs Breadth and Depth of Data Target Consumers and Normalized Specifications Performance Utility Services 9

Service Design Principles Design PrinciplesDescription Standardized Service ContractServices share Standardized Contracts Service Loose Coupling Low consumer Coupling and Services decoupled from environment Service AbstractionNon - essential Service Information is Abstracted Service Reusability Services contain and express agnostic logic and hence enterprise wide Reusability is exhibited Service Autonomy Services exhibit High Level of Control over underlying execution environment Service StatelessnessMinimize Resource Consumption by deferring State Management Service Discoverability Equipped with communicative metadata that can be discovered and interpreted Service Composability Effective Composition participants 10

Designing Web Service – Security No Practices Require authentication on every request Authenticate once and use a token Restrict token validity Security is very expensive – One size fit all will not work! 11 General Practices WS-Security – Sign and encrypt SOAP messages ( Both header and body) WS-SecurityPolicy – Retrieve what a service expects WS-SecureConversation ((“SSL for SOAP”) - Negotiate and manage a session key WS-Security Tokens X.509 certificates Username / password Kerberos (for Intranet) SAML (cross-organizationally) SecPAL authorization WS-Trust A security token service (STS) issues

SOAP vs REST SOAP Advantages Interoperability Extensions Design Flexibility Rapid Client - Server Development SOAP Issues Dealing with many customers Needing different media types Developing an AJAX client REST Advantages Self - describing Simplicity Scalability Decoupled Client - Server REST Issues Designing a transactional flow Developing the client - side library Handling batch processing Working with binary data REST Advantages Self - describing Simplicity Scalability Decoupled Client - Server REST Issues Designing a transactional flow Developing the client - side library Handling batch processing Working with binary data Service-Oriented Interfaces (SOAP) Resource-Oriented Interfaces (REST) Server - SideEasy to get right Easy to get wrong Client - SideNarrow appealBroad appeal 12

Web Service Development - Criteria for Selection 13 Features IDE Plug-in Support Transports and Attachments Data Binding

Web Service Development – Widely used Frameworks Apache Axis 2 Metro Glassfish (Earlier Java Web Services Developer Pack) APIs in Java EE and Java SE Technologies JAX-RS Alternates: JSON-RPC for light transfer across the network! And there is POX! 14

RPC/Encoded, Document/Literal : What to use 15 WSDL Soap Binding Style RPCDocument Encoding Literal Use

RPC/Encoded, Document/Literal : What to use 16 AdvantagesDisadvantages RPC/EncodedThe operation name appears in the message, so the receiver has an easy time dispatching this message to the implementation of the operation. The type encoding info (such as xsi:type="xsd:int") is usually just overhead which degrades throughput performance Validation is difficult Not WS-I Compliant RPC/Literal The operation name still appears in the message. The type encoding info is eliminated. RPC/literal is WS-I compliant. Validation is difficult since the way the schema is defined for message part is different.

RPC/Encoded, Document/Literal : What to use 17 AdvantagesDisadvantages Document/EncodedNone. Just another combination Not WSI compliant Document /Literal There is no type encoding info. You can finally validate this message with any XML validator. Everything within the soap:body is defined in a schema. Document/literal is WS-I compliant, but with restrictions The WSDL is getting a bit more complicated Operation name is lost in the Request message.

Web Service Versioning 18 Multiple Versions of the same Service/Operations Why? Least Impact to existing Applications Enables Multiple Consumer to decide / plan the adoption of enhancements Cons: Governance Implementation Tracking Tracking of issues in different Versions Complicated Run time Binding Best Practice Control Minimum Active versions Have a good Governance and Stake Holder Mechanisms with clear ownership and change control procedures for Services

Web Service Design and Dev – Best Practices Check the Business and Technology Goals and Convince yourself if Web Service is the only way to go! Keep it Simple ! Prioritize the Design Principles. Use Appropriate Messaging and Protocol Standards Ensure WS-I Basic Profile Conformance Follow Pre defined, understandable, Intuitive Naming Conventions Always include a version parameter 19

Web Service Design and Dev – Best Practices Design Fault Messages for Possible Error Conditions Improve Productivity by Using Tools Reuse the Legacy! Go for Late Binding only if absolutely necessary Design your SOA with a foreknowledge of emerging specifications 20

A Final Word After all Users need a service to be - Accessible Documented Robust Reliable Simple Predictable 21

Thank You

23