JDC2008 - Enterprise Integration and Service Oriented Design


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

JDC2008 - Enterprise Integration and Service Oriented Design

  1. 1. Enterprise Integration and Service-Oriented Design<br />Hossam Karim<br />
  2. 2. Agenda<br />The Enterprise Integration Problem<br />Enterprise Integration Principles, Styles and Messaging Concepts<br />Service-Oriented Design Approach<br />Frameworks and Implementations<br />References<br />Conclusion<br />
  3. 3. The Enterprise Integration Problem<br />Enterprise integration requires a significant shift in corporate politics<br />Integration efforts typically have far-reaching implications on the business<br />The lack of widely implemented standards addressing core integration problems<br /> The concept and technology learning curve<br />
  4. 4. Enterprise Integration Principles<br />Integration is connecting computer systems, companies or people<br />Enterprise integration is the task of making disparate applications work together to produce a unified set of functionality<br />
  5. 5. Integration Types<br />Information Portals<br />Data Replication<br />Shared Business Function<br />Service-Oriented Architecture<br />Distributed Business Process<br />Business to Business Integration<br />
  6. 6. Enterprise Integration TypesInformation Portals<br />Portal<br />Resource A<br />Resource B<br />Resource C<br />Basic data aggregation<br />Single source of information<br />
  7. 7. Enterprise Integration TypesData Replication<br />Application B<br />Application A<br />Data Access<br />Data Access<br />Data Store A<br />Data Store B<br />Data moves on the database tier<br />Consistency is dependent on the DBMS implementation<br />
  8. 8. Enterprise Integration TypesShared Business Function<br />Application A<br />Application B<br />Logic A<br />Logic B<br />Shared Function<br />Moves the control to the shared function logic<br />Tightly couples all clients to the application interfaces<br />
  9. 9. Enterprise Integration TypesService-Oriented Architecture<br />Application<br />Application Service<br />Service A<br />Service B<br />Service C<br />Service D<br />Connects distributed applications and exposes services through a standard contract<br />Complex to design and implement<br />
  10. 10. Enterprise Integration TypesDistributed Business Process<br />Business Process<br />Function A<br />Function B<br />Function C<br />Single point of invocation<br />Requires other integration solutions to function<br />
  11. 11. Enterprise Integration TypesBusiness-To-Business Integration<br />Function A<br />Function B<br />Higher level of integration<br />Still requires an integration solution<br />
  12. 12. Enterprise Integration Styles<br />File Transfer<br />Shared Database<br />Remote Procedure Invocation<br />Messaging<br />
  13. 13. Enterprise Integration StylesFile Transfer<br />Application A<br />Application B<br />Shared Data<br />Export<br />Import<br />Simplest form of integration<br />Lacks timeliness and scalability<br />
  14. 14. Enterprise Integration StylesShared Database<br />Application A<br />Application B<br />Application C<br />Data Access<br />Data Access<br />Data Access<br />Data Store<br />Promotes consistency<br />Lacks portability and scalability<br />
  15. 15. Enterprise Integration StylesRemote Procedure Invocation<br />Function Call<br />Application A<br />Application B<br />Stub<br />Skeleton<br />Reply<br />Provides more than data sharing<br />Tightly couples integrated parties<br />
  16. 16. Enterprise Integration StylesMessaging<br />Application A<br />Application A<br />Application A<br />Event Layer<br />Message Bus<br />Transfer packets of data immediately, reliably, and asynchronously, using customizable formats. <br />
  17. 17. Tightly Coupled Interfaces<br />Requires minimum n(n-1)/2 interfaces, where n is the number of integrated applications<br />
  18. 18. Loosely Coupled Interfaces<br />Requires exactly n interfaces, where n is the number of integrated applications<br />
  19. 19. Enterprise Integration Using Messaging<br />Construction<br />Channels<br />Endpoints<br />Routing<br />Transformation<br />Management<br />Messaging Models<br />Transactions<br />
  20. 20. Message Construction<br />Message<br />Receiver<br />Sender<br />A message is a formatted unit of data<br />A message consists of a header, properties and a body<br />A sender marshals the data to construct the message<br />A receiver un-marshals the data into its own data model<br />
  21. 21. Message ConstructionExample: Spring Integration<br />Generic message body type<br />Correlation ID<br />Header support<br />Pure Java object as a message body<br />Simplest form of a modeled message<br />Uses generics to specialize message body type<br />No marshaling or un-marshaling needed<br />
  22. 22. Message ConstructionExample: Java Business Integration<br />Attachments support<br />XML body<br />Merged Properties and<br />Header support<br />Security support<br />Body is XML based<br />Supports attachments and security subject<br />
  23. 23. Message ConstructionExample: Apache Camel<br />Correlation ID<br />What is this?<br />Header support<br />Pure POJO body<br />
  24. 24. Message ConstructionMessage Exchange Patterns<br />Exchange Patterns<br />WSDL 2.0 based message exchange patterns<br />
  25. 25. Message ConstructionMessage Exchange<br />This exchange pattern<br />Actual Message<br />Messages are encapsulated into a message exchange<br />The pattern identifies what is encapsulated<br />
  26. 26. Message ConstructionMessage Exchange, JBI Example<br />
  27. 27. Messaging Channels<br />Message<br />Channel<br />Sender<br />Application<br />Receiver<br />Application<br />A channel is a gateway for transmitting messages from a sender to a receiver<br />Sender and receiver do not know about each other<br />Can be referred to as a pipe<br />
  28. 28. Message ChannelExample: Spring Integration<br />Pure POJO model<br />
  29. 29. Message ChannelExample: Java Business Integration<br />Factory method pattern, creates message exchange factories<br />Supports synchronous and asynchronous exchanges<br />
  30. 30. Messaging Endpoints<br />Data<br />Data<br />Endpoint<br />Endpoint<br />Channel<br />Message<br />Sender<br />Application<br />Receiver<br />Application<br />An endpoint is a client of a messaging application that is capable of sending and receiving messages<br />The Message Endpoint encapsulates the messaging system from the rest of the application and customizes a general messaging API for a specific application and task<br />
  31. 31. Message EndpointExample: Spring Integration<br />
  32. 32. Message EndpointExample: Spring Integration<br />
  33. 33. Message Processing Problem<br />Exhausted at (n - y) messages<br />Exhausted at (n - x)<br /> messages<br />(n) messages<br />Data<br />Endpoint<br />Channel<br />Receiver<br />Application<br />Client sends (n) messages<br />Channel’s capacity is (n-x) messages<br />Receiver application exhausted at (n-y) messages<br />
  34. 34. Message Processing ProblemSEDA: Staged Event-Driven Architecture<br />The Event Queue accepts incoming events<br />The Event Handler handles incoming events<br />The Thread Pool provides threading capabilities to the event handler<br />The Controller adjusts resources allocation and scheduling dynamically<br />Event Handler<br />Event Queue<br />Thread Pool<br />Controller<br />SEDA Stage<br />
  35. 35. Message Processing ProblemSEDA: Staged Event-Driven Architecture<br />Outgoing<br />Messages<br />Stage A<br />Incoming<br />Messages<br />Outgoing<br />Messages<br />Stage B<br />Receiver<br />Stage<br />Outgoing<br />Messages<br />Stage C<br />
  36. 36. Message Routing<br />Receiver<br />A<br />Output<br />Channel<br />A<br />Receiver<br />B<br />Input<br />Channel<br />Message<br />Message<br />Router<br />Output<br />Channel<br />B<br />A Message Router consumes a Message from one Message Channel and republishes it to a different Message Channel, depending on a set of conditions<br />
  37. 37. Message RouterExample: Spring Integration<br />
  38. 38. Message Transformation<br />Incoming<br />Message<br />Translated<br />Message<br />Translator<br />A Message Translator is a filter that translates one data format to another<br />
  39. 39. Message FlowExample: The VETRO Pattern<br />All numbers and kinds of filters can be applied to a message before processing<br />
  40. 40. System Management<br />Message Flow<br />Processor A<br />Processor B<br />Processor C<br />Message X<br />Message X’<br />Configuration<br />Heartbeat<br />Test Messages<br />Control Bus<br />Exceptions<br />Statistics<br />Live Console<br />The Control Bus uses the same messaging mechanism used by the application data but uses separate channels to transmit data that is relevant to the management of components involved in the message flow<br />
  41. 41. Messaging Models<br />Publish/Subscribe Model<br />Point-to-Point Model<br />
  42. 42. Store and Forward Messaging<br /><ul><li>Guaranteed once and only once message delivery
  43. 43. Transparent to the messaging clients</li></li></ul><li>Transactional MessagingLocal Transactions<br />Producer sends one or more messages in a transactional context<br />Producer commits the transaction<br />Consumer receives all messages<br />Consumer commits the transaction<br />
  44. 44. Transactional MessagingDistributed Transactions<br />Producer sends one or more messages in the transaction manager context<br />Producer updates another resource<br />Producer commits the transaction<br />
  45. 45. Messaging Protocol Stack<br />Payload<br />Protocol<br />Messaging<br />Protocol<br />Transport<br />Protocol<br />Networking<br />Protocol<br />Clients expect simple and widely used protocols<br />Legacy applications communicate in proprietary protocols<br />Firewalls require tunneling through opened ports<br />
  46. 46. Service Meta-Model<br />
  47. 47. Service Component Model<br />Exposed Interface<br />Protocol Specific<br />Endpoint<br />Encapsulating<br />Component<br />Service<br />Implementation<br />
  48. 48. Service Component Clients<br />Protocol <br />Dependent<br />Client<br />Interface Binding<br />
  49. 49. Service-Oriented Design Approach<br />
  50. 50. Service-Oriented Design ApproachExample: Java Business Integration<br />Common<br />Logic<br />Expose<br />Services<br />Message Bus<br />Activate<br />Endpoints<br />
  51. 51. Service-Oriented Design Approach Example: Java Business Integration<br />JBI runtime is based on the router messaging pattern<br />All messages moving through the router are in XML format<br />Components are installable artifacts<br />Binding components make services available to JBI runtime clients using a service contract and through a protocol<br />Service engines perform the actual service logic<br />Service units activate service endpoints<br />
  52. 52. Service-Oriented Design Approach Example: Java Business Integration<br />Services are exposed on arbitrary supported protocols<br />Messages are normalized and delivered to their channels<br />Messages are routed through the normalized message router to the target service engine<br />The service engine performs its task and replies to the component if appropriate<br />
  53. 53. Frameworks and Implementations<br />Spring Integrationhttp://www.springframework.org/spring-integration/<br />Apache ServiceMixhttp://servicemix.apache.org/<br />Apache Camelhttp://activemq.apache.org/camel/<br />Sun OpenESBhttps://open-esb.dev.java.net/<br />Mulehttp://mule.mulesource.org/<br />
  54. 54. References<br />Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions - Gregor Hohpe, Bobby Woolf<br />Enterprise Service Bus – Dave Chappell<br />SOA: Principles of Service Design - Thomas Erl<br />SEDA: An Architecture for Well Conditioned, Scalable Internet Services - Matt Welsh, David Culler, and Eric Brewer<br />Java™ Business Integration (JBI) 1.0 – JSR 208 Specification - Ron Ten-Hove, Peter Walker<br />Thanks to Dave Chappell for granting permission to use hisdiagramming notation in this presentation<br />
  55. 55. Conclusion<br />Don’t reinvent the wheel<br />Keep close to the standards<br />Spend time understanding and evaluating your infrastructure<br />Not all frameworks and design solutions are suitable for each environment<br />Design to scale, but don’t over design<br />Explore integration solutions and frameworks<br />Practice service-oriented design and implementation<br />