Design Decisions in Service Oriented

Architectures CSC-8530: Distributed Systems

Christopher Salembier28-Oct-2009

Distributed Architectural Paradigm◦ Service Providers◦ Service Users◦ Transport Middleware

Driven by business needs Stresses interoperability A service is…

◦ A logical representation of business activity◦ Self-contained◦ Distributed◦ Has a public interface◦ Platform independent◦ Discoverable*◦ Dynamically Bound*

*By definition, but in practice often not achieved.

What is SOA?

SOA Implementation

DCOM

A method for SOA implementation Use technology & protocols of the internet

◦ HTTP / HTTPS◦ TCP / IP◦ XML◦ WSDL◦ SOAP

Most widely used strategy today Closest to achieving interoperability

What is a Web Service?

Interoperability (increase*)◦ 2 basic standards: WSDL, SOAP◦ Additional standards: UDDI, BPEL, WS-I, etc◦ Not all platforms use same version◦ In practice not as each to achieve as advertized

Modifiability (increase)◦ Loose coupling◦ Self contained services reduce usage dependencies◦ XML for contract description

Performance (decrease)◦ Distributed communication◦ Overhead for intermediaries (e.g. directory service, marshalling)◦ Standardized formats (XML) increases message size*In theory

Key Quality Attributes Addressed

SOAP◦ RPC-Encoded

XML-based remote procedure call Popular early for simplicity Bad for interoperability due to differences in SOAP encoding

◦ Document-Literal No standard encoding used XML schemas defining message contract key element Best support with WS-I standards

REST - Representational State Transfer ◦ Always stateless◦ No processing overhead by always using bare Http◦ Improves key quality attributes◦ Good for accessing static resources or limited bandwidth (e.g. mobile devices)

Messaging◦ Heavy reliance on middleware◦ Best reliability and QoS Control◦ Queues allow offline use◦ Highly scalable

Design Decision: Communication

Point-to-Point◦ Less complexity and overhead◦ Good for small projects and / or tight schedules◦ Often used even when ESB is better choice (due to cost)

Enterprise Service Bus◦ Increases interoperability◦ Easy addition of services◦ Performance overhead

Design Decision: Integration

Static◦ Interface & location known at deployment◦ Generated stub and local configuration file◦ Tighter coupling◦ Better performance◦ Very common with point-to-point integrations

Dynamic◦ Requires service registry◦ Discover at runtime◦ Location transparency

Design Decision: Binding

Synchronous◦ Simpler to develop◦ Behavioral dependencies complicate adding middleware (e.g. ESP)◦ May result in unnecessary blocking◦ More difficult to scale because of wait requirements◦ Easier error recovery

Asynchronous◦ Additional application logic for response overhead◦ More loosely coupled◦ Easier to integrate with middleware◦ Improves performance with no blocking calls◦ Better scalability for large applications◦ Error handling more complex

Really a service-by-service decision, but some middleware and legacy application may only support one or the other.

Design Decision: Timing

Scope of Functionality Course-Grained

◦ Less communication◦ Larger messages◦ More processing◦ General and/or broad use

Fine-Grained◦ Many calls to achieve final result◦ Smaller messages◦ Little processing◦ Specialized usage or meaning

Design Decision: Granularity

Security◦ HTTPS◦ Message Level

XML Parsing◦ DOM◦ SAX◦ StAX

Emerging WS-I standards◦ WS-Security◦ WS-Addressing◦ WS-Policy◦ WS-ReliableMessaging◦ Many, many more

Other Decisions

SOA Components

Resources OASIS SOA Reference Model Website IBM Developer Network - Web Services Object Management Group - SOA Home W3C - Web Service Architecture SEI - Evaluating a SOA http://www.service-architecture.com/ http://www.ws-i.org/