Practical Web Service Design and Development Revathi R Sonata Software.
-
Upload
john-hodges -
Category
Documents
-
view
221 -
download
5
Transcript of Practical Web Service Design and Development Revathi R Sonata Software.
Practical Web Service Design and Development
Revathi RSonata 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
2
Why Web Services
• Identified by a URI• Interfaces defined using XML• Can be DISCOVERED by other systems
3
Advantages
Stateless
Standards based
Discoverable in the run time
Drawbacks
Challenges for interactive response
Not leveraging Client Side Computing Power
Performance
Web Services – Key Perspectives
Key Component of SOA • Important role to realize the ROI for Investments in SOA
Key Business Layer Candidate• Also viewed as the comprehensible
candidate for “Service” Layer in multitier applications – though this is contestable!
Technology Bridge • Bridge between Legacy and Modern Technologies
4
Service Oriented Design vs Object Oriented Design
Object Orientation Service Orientation
Increased Business Requirements Fulfillment, Increased RobustnessIncreased Extensibility, Increased Flexibility, Increased Reusability and ProductivityOpen - Closed Principle (OCP), Don't Repeat Yourself (DRY)Single Responsibility Principle (SRP), Delegation, Association, CompositionAggregationEncapsulation, Inheritance, Generalization and Specialization, Polymorphism, Abstraction
Specialization through Granularity,Abstraction for Information hidingPolymorphism through ESB
Principles bounded by RPC Technology / Language No 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 centric Enterprise centric
Classes, Objects, Methods, Attributes…. Technical Interface, Stateless Operations, Schema Definitions…..
5
Key factors In Web Service Design and Development
• Understanding the System and the Context of Web Services
• Adhering to the well established Design Principles and Patterns for Web Services
• Selecting the right Framework for Implementation
• In Designing and Implementing
SystemService Design
Principles
Dev Frame-work
Avoiding Well
known Pitfalls
6
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 Technologies
Standards to be Complied to
7
Web Services for Process Automation
Utility Services
8
Web Services for B2B Interaction
Utility Services
9
Web Services for Application (e.g. RIA, Portals, Mobile)
Utility Services
10
Service Design Principles
Design Principles Description
Standardized Service Contract Services share Standardized Contracts
Service Loose Coupling Low consumer Coupling and Services decoupled from environment
Service Abstraction Non - 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 Statelessness Minimize Resource Consumption by deferring State Management
Service Discoverability Equipped with communicative metadata that can be discovered and interpreted
Service Composability Effective Composition participants
11
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!
12
General Practices
WS-Security – Sign and encrypt SOAP messages ( Both header and body)WS-SecurityPolicy – Retrieve what a service expectsWS-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
Service-OrientedInterfaces (SOAP)
Resource-OrientedInterfaces (REST)
Server - Side Easy to getright
Easy to getwrong
Client - Side Narrow appeal Broad appeal
13
Web Service Development - Criteria for Selection
14
Features IDE Plug-in Support
Transports and
AttachmentsData 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!
15
RPC/Encoded, Document/Literal : What to use
16
WSDL Soap Binding Style
RPC
Document
Encoding
Literal
Use
RPC/Encoded, Document/Literal : What to use
17
Advantages Disadvantages
RPC/Encoded The 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
18
Advantages DisadvantagesDocument/Encoded None. Just another
combinationNot 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
19
• 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
20
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
21
A Final Word
After all Users need a service to be - • Accessible• Documented• Robust• Reliable• Simple• Predictable
22
Thank You
24