A Lightweight SOA Framework using Ruby, Apache Thrift and AMQP

Service-oriented architecture (SOA) is an evolution of distributed computing based upon the request/response design pattern (aka RPC) for communication between independent system components. These components modularize system functionality and encapsulate their business logic that is presented as Services to be consumed by client applications or other services.

The key to these Services is their loosely coupled nature; i.e., the service interface is independent of the implementation and developers can build applications by composing one or more services without knowing the services' underlying implementations. The use of messaging to connect distributed Service components provides a consistent communication platform to ensure a scalable, decoupled and reliable system that can grow over time with minimal impact on an existing system.

This talk will demonstrate one approach to implementing just such a system; focusing on a Ruby implementation of Service functionality and a lightweight RPC framework based on the Apache Thrift protocol specification and AMQP for messaging transport.

We’ll show just how easy it can be to build such a complex and highly distributed SOA system using Ruby and a couple of other open source projects.

Transcript

1. Stephen P. Henrie Manager, Application Development A Lightweight SOA Framework using Ruby, Apache Thrift and AMQP
2. (Insert Shameless Promotion Here) Greatness Awaits   Just who is Sony Computer Entertainment America (SCEA)?
3. Background topics... Service Oriented Architecture (SOA) Remote Procedure Calls (RPC) Messaging Advanced Message Queuing Protocol (AMQP) Apache Thrift Put it all together
4. Loosely coupled, independent system components An evolution of Distributed Computing Encapsulates business logic as Services to be consumed Typically Communicates using Remote Procedure Calls (RPC) So what is a Service Oriented Architecture (SOA) Again? “If we build our systems as components, we can build and maintain them independently. SOA is a set of design patterns that guide us in building and integrating these mini-application pieces.” - Mike Hadlow, Some Thoughts On Service Oriented Architecture
5. SOA Service Components •  Single Purpose - should have one job within the system as a whole •  Encapsulated - logically decoupled and not share its internal state •  Contract – Having a defined API and the message types that it publishes and consumes •  Context Free - should not be dependent on other components; only contracts •  Independently deployable - all services do not have to be running •  Independently testable – testable in isolation
6. SOA Component Communication •  Communication should only use well defined and logically- decoupled contracts •  Components should not have to be configured to communicate with specific endpoints – decoupled configuration •  support ‘temporal-decoupling’ - meaning that all the services do not have to be running at the same time for the system to work •  Support low latency - There should be a minimal delay between service components •  communication should be based on open standards
7. Remote Procedure Calls (RPC) between distributed Processes •  Business logic calls local procedures in generated client stub •  Client stub creates messages and marshals data to network •  Complex network operations hidden “behind the scenes” •  Server skeleton unmarshals data and delivers to business logic on server •  Service functions return results to client stub •  Client stub returns results to calling function
8. Messaging to the Rescue! •  Provides Communication between distributed and loosely-coupled components •  Developers focus on business logic and not infrastructure •  services can be moved around and messages follow •  Message formats can evolve with the business logic •  Messaging is secure and scalable •  Supports RPC pattern
9. Services communicate through a central message broker A Message Based Service Architecture
10. AMQP Message: •  The header contains properties and contextual information about the message. •  The body contains unstructured payload or data of the message. Advanced Message Queuing Protocol Why AMQP? •  Supports pub-sub, RPC and content based routing •  Secure, reliable and transactional transfer of data •  binary wire protocol enables interoperability across languages and platforms •  Centralized broker is scalable, clusterable and easier to configure. •  Low Latency •  Open Standards
11. RPC over AMQP 1.  Client sends message to exchange 2.  Service queue is bound to exchange 3.  Exchange routes message to service queue 4.  Service process is subscribed to queue 5.  Broker pushes message to service 6.  Result returned to specified callback queue in reply-to header 7.  Broker pushes rely message to client Supports blocking and non-blocking calls Multiple service processes connecting to the same queue provide load balancing!
12. What is a Wire Protocol? It is a language and platform-neutral schema for describing and transmitting data between distributed processes. a protocol specifies how data types use the underlying Transport to encode/decode themselves.
13. Along comes Apache Thrift... The THRIFT Network Stack.... Transport (raw TCP, HTTP, encrypted etc) Apache Thrift is: •  language independent •  Binary communication protocol •  interface definition language •  code generator •  service framework Server (Multi-threaded, event-driven) Processor (compiler generated) Protocol (Binary, JSON, compact etc)
14. The Power of an Interface Definition Language (IDL) Language independent specification for service contracts: •  API Specification •  Message specification •  Message V alidation •  Strongly Typed •  Used to generate stubs and skeletons
15. Apache Thrift Calculator Tutorial
16. Let’s Look at some code! https://github.com/shenrie/apache-thrift-amqp
17. Handling Versioning/Compatibility •  Protocols evolve over time •  Thrift supports message format changes but still use code created with the old format.
18. Service load balancing Starting multiple service worker processes that connect to the same rabbitmq broker queue will automatically do round robin load balancing. Requires services to be stateless. Additional workers can be started for increased message throughput.
19. References •  Some Thoughts On Service Oriented Architecture – Mike Hadlow •  Apache Thrift Documentation and Tutorial •  Thrift: The Missing Guide - Diwaker Gupta •  RabbitMQ – Tutorial •  Understanding AMQP, the protocol used by RabbitMQ
20. Questions? stephen_henrie@playstation.sony.com Thank You!