CSC-8530: Distributed Systems Christopher Salembier 28-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.

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

 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

 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

 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

 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

 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.

 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

 Security ◦ HTTPS ◦ Message Level  XML Parsing ◦ DOM ◦ SAX ◦ StAX  Emerging WS-I standards ◦ WS-Security ◦ WS-Addressing ◦ WS-Policy ◦ WS-ReliableMessaging ◦ Many, many more

 OASIS SOA Reference Model Website OASIS SOA Reference Model Website  IBM Developer Network - Web Services IBM Developer Network - Web Services  Object Management Group - SOA Home Object Management Group - SOA Home  W3C - Web Service Architecture W3C - Web Service Architecture  SEI - Evaluating a SOA SEI - Evaluating a SOA  