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