130 likes | 235 Views
Asynchronous Linking in a Service—Oriented Architecture (“Stuff Happens”). Sanjay Vivek, Kenneth K. Tso, Mark K. Thompson, David C. De Roure Department of Electronics and Computer Science, University of Southampton UK. Position.
E N D
Asynchronous Linking in a Service—Oriented Architecture(“Stuff Happens”) Sanjay Vivek, Kenneth K. Tso, Mark K. Thompson, David C. De Roure Department of Electronics and Computer Science, University of Southampton UK
Position • Service—Oriented Architectures (SOA) decouple components in space • Message—Oriented Middlewares (MOM) decouple components in time • This double decoupling is useful…
Motivation • Threefold motivation for asynchronicity • The ad hoc world where you walk into the room and stuff happens • The poor-performing-proxy world where the time-boundedness of link processing intrudes • The live-action, live-media worlds where the comms model is notification-based
Position • Service—Oriented Architectures (SOA) decouple components in space • Message—Oriented Middlewares (MOM) decouple components in time • This double decoupling is useful for: - mobile; lightweight; pervasive OHSes - existing systems where synchronicity hurts - linking from streamed media
Overview • Service–Oriented Architectures • Asynchronous Interaction • Example with MQe™ and Auld Linky • Thoughts
Service—Oriented Architectures • SOA enable service components residing on a network to be published, discovered, and invoked by each other • Enables seamless interop between distributed components • Typically 3 components: • Service Provider • Service Broker • Service Requester • With 3 functions: • Find • Bind • Interact
Web Services Example Stack • Define interface to service components (e.g. Link service interface) • Publish service description in repository • Interact with other services to form complex applications Workflow (WSFL) Discovery (UDDI) Description (WSDL) Packaging (SOAP,XML) Transport (HTTP, Jabber) Network (TCP/IP)
Asynchronous Interaction • Transaction-based fire-and-forget messaging • Queues of messages (function calls) directed towards services • Example: IBM’s MQSeries Everyplace (MQe) • Assured once-only delivery • Messages queued and routed toward end-points • Contextual triggers for additional functionality • Lightweight in speed and size
N Auld Linky linkbases Example using MQe™ and Auld Linky before HTTP DLS HTTP HTTP
Example using MQe™ and Auld Linky • Ported Auld Linky’s HTTP interface for Linkbase query/update to a Web Service • Wrapped service with an MQe Custom Queue • HTTP Proxy-based DLS interacted with Linky using HTTP; now issues SOAP calls which are transported through MQe queues
N Auld Linky’ queues queues linkbases Example using MQe™ and Auld Linky after HTTP DLS’ SOAP HTTP MQe QM MQe QM SOAP/MQe SOAP/HTTP
Issues with the DLS-MQe-Linky Example • Latency and QoP control • Additional overhead in the path from query source to query target • Application context can determine prioritisation of link resolution events • Modality of link resolution has shifted • Non-availability of clients results in requests/responses being “buffered”, but for how long? • Concurrency; Resilience; Query-routing…
Thoughts • Is such decoupling good for the soul? • Asynchronicity; Dislocation • Different Link service interaction • Notifications and the “Null Query” • Other OHS layers and functions, beyond Links • Linking is fun, but executable structures (with continuations) could be more-so(!)