Java Business Integration (JBI)

2,116 views

Published on

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,116
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
78
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • • Pattern – every message exchange is described by a pattern, which describes the direction, sequence, cardinality, and names of messages (normal or fault) which constitute in the exchange.• Initiator – component which creates the message exchange. Service consumers act as initiators in all standard JBI-defined message exchange patterns are consumer initiated.• Servicer – component which services the message exchange. Service providers act as servicers.• Role – the role a component plays when it “owns” a message exchange instance:• Provider – the component that provides the service requested by a message exchange.• Consumer – the component that requests a service from a provider.• Address – a service reference, endpoint reference, and operation name for the logical address which the NMR uses to route message exchanges.• Message – a message exchange carries one or more messages.• Fault – a message exchange may carry at most one fault. A fault is a special kind of message.• Status – describes the status of the message exchange: error, done, or active.• Error – A Java Exception object used to describe the nature/source of an error status.• Properties – initiators and servicers of a message exchange may associate arbitrary properties with a message exchange. The NMR may choose to reserve certain property names to declare QoS, security, transaction, or other operational metadata.
  • Binding components must convert “bound” messages (messages in protocol- and transport-specific formats) to normalized form, BCs and SEs interact with the NMR via a DeliveryChannel,
  • • BC1. A binding component that “speaks” Client1's protocol, which happens to be WS-I BP 1.1 compliant SOAP. • SE1. A service engine used to provide light-weight sequencing of services. This can be configured to perform the desired message adaptation and forwarding. • SE2. A service engine used to transform messages using XSLT 1.0. • BC2. A binding component that “speaks” Service1's protocol, which is (in this example) AS2 over HTTP. The message exchanges in the message sequence chart, above, are described in detail below. • Client1 to BC1. The client is configured to send its request of Service1, the payload of which we term REQ1, to BC1. As far as Client1 is concerned, BC1 is the end point for accessing Service1, using the client's own messaging protocol. • BC1 normalizes and forwards the inbound request for Service1, using the NMR to route the message. The JBI instance is configured to send requests for Service1 to SE1. (SE1 is a light-weight engine that can sequence the conversion and forwarding of messages.) • SE1 selects the type of conversion to be performed, and sends a request to the conversion service to have REQ1 converted to what we will label REQ1A. The NMR will route this message to the SE2, which provides the desired service.SE2 will perform the transformation and synchronously return the result SE1. • SE1 completes the sequencing the conversion-and-forward process by sending the result of the transformation, REQ1A to Service1. (The NMR will route this to BC2). • BC2 denormalizes the message, and sends it (one-way) to Service1.
  • Java Business Integration (JBI)

    1. 1. Java Business Integration JSR 208 Chin-Yi Tsai [email_address] http://140.134.26.25/~cyt
    2. 2. Integration Difficulties
    3. 3. Integration Solution Services (WS- I ) (interoperability) Components (pluggable) (interoperability) Enterprise Service Bus
    4. 4. Specification ( 非 Java EE 5 的一部分 ) Java Business Integration JSR 208 JBI-Compliant Component1 JBI-Compliant Component2 JBI Environment / JBI Container
    5. 5. ESB, SOA, JBI <ul><li>ESB </li></ul><ul><ul><li>Architecture technique to integrate incompatible business applications over a common messaging bus . </li></ul></ul><ul><ul><li>Unlock and extend your existing systems and technology investments on a modern Service Oriented and Event Driven Architecture </li></ul></ul><ul><li>SOA </li></ul><ul><ul><li>An architectural principle for structuring systems that SOA emphasizes the de-coupling of system components </li></ul></ul><ul><li>ESB & SOA </li></ul><ul><ul><li>ESB is one architecture style that abides by the rules of a Service Orientated Architecture. </li></ul></ul><ul><li>JBI </li></ul><ul><ul><li>Defines common interfaces (SPI) for components and message exchanges and service deployment. </li></ul></ul>
    6. 6. What Does a Service Do <ul><li>Transform data </li></ul><ul><li>Route messages </li></ul><ul><li>Query databases </li></ul><ul><li>Orchestrate conversations </li></ul><ul><li>Apply business logic </li></ul><ul><li>Apply business policy </li></ul><ul><li>Handle business exceptions </li></ul><ul><li>Solicit approvals </li></ul>How Is a Service Implemented? <ul><li>XSLT </li></ul><ul><li>Enterprise JavaBeans. (EJB.) technology </li></ul><ul><li>BPEL </li></ul><ul><li>SQL </li></ul><ul><li>XQuery </li></ul><ul><li>Routing Table </li></ul><ul><li>Business Rules </li></ul><ul><li>EDI Transform </li></ul>
    7. 7. Outline <ul><li>Overview of JBI </li></ul><ul><ul><li>integration </li></ul></ul><ul><li>JBI Architecture </li></ul><ul><ul><li>SE </li></ul></ul><ul><ul><li>BC </li></ul></ul><ul><ul><li>NMR </li></ul></ul><ul><ul><li>JMX (Management) </li></ul></ul><ul><li>Conclusion (Keywords) </li></ul><ul><li>Reference </li></ul><ul><li>Appendix </li></ul>
    8. 8. Overview of JBI <ul><li>Standard “ meta-container ” for services </li></ul><ul><li>Standard SPI for plug-in </li></ul><ul><ul><li>Service Engines — provide and aggregate services </li></ul></ul><ul><ul><li>Binding Components — provide protocols and transports </li></ul></ul><ul><li>Loose coupling via WSDL message exchanges </li></ul><ul><li>JBI defines an environment for plug-in components that interact using a services model based directly on WSDL 2.0 </li></ul>容器放元件進去 (plug-in) 元件也是一個容器
    9. 9. Component as Container <ul><li>JBI directly supports the deployment of artifacts to plug-in components, using an archive (ZIP file) package called a service unit . </li></ul>
    10. 10. Component as Container (Cont’d) <ul><li>Groups of service units are often developed or collected together, to form parts of a larger application or new service that are tested and deployed together. </li></ul><ul><li>A group of JBI service units, along with a description of their relationships and target components, is called a service assembly . </li></ul>
    11. 11. Overview of JBI <ul><li>Java Business Integration (JBI) is a specification developed under the Java Community Process ( JCP ) for an approach to implementing a service-oriented architecture (SOA). </li></ul><ul><ul><li>Creating a standards-based architecture for integration solutions </li></ul></ul><ul><ul><li>A suitable standard technology instead of proprietary vendor solution </li></ul></ul><ul><li>JBI defines an architecture that allows the construction of integration systems from plug-in components, that interoperate through the method of mediated message exchange . </li></ul>
    12. 12. Overview of JBI (Cont’d) <ul><li>JBI plug-in components are responsible for providing and consuming services. </li></ul>
    13. 13. JBI Architecture <ul><li>JBI provides an environment in which plug-in components reside. </li></ul><ul><ul><li>The environment provides a set of services to facilitate execution of provided services, interaction between components, as well as management of the overall system created by a JBI installation and all installed components. </li></ul></ul><ul><li>JBI provides for interoperation between plug-in components by means of message-based service invocation, described using a standard service description language. </li></ul><ul><li>JBI provides a set of services to facilitate management of the JBI environment, including the installed components. This includes component installation and life cycle management services. </li></ul>Plug-in component Message exchange Management
    14. 14. High-level View of JBI Architecture Single JVM Other JVM <ul><ul><li>SE </li></ul></ul><ul><ul><li>BC </li></ul></ul><ul><ul><li>NMR </li></ul></ul><ul><ul><li>JMX (Management) </li></ul></ul>
    15. 15. Component Framework <ul><li>JBI components ( service engines and binding components ) provide interfaces for the use of JBI, and use interfaces provided by JBI. </li></ul><ul><li>The JBI framework provides the following for the use of components </li></ul><ul><ul><li>Component installation context </li></ul></ul><ul><ul><li>Component context </li></ul></ul><ul><ul><li>Class loading </li></ul></ul><ul><ul><li>Error indication </li></ul></ul>
    16. 16. Standardized Integration <ul><li>SPI (Service Provider Interface) not API </li></ul><ul><ul><li>Allow for proprietary “ black boxes ” as integration services </li></ul></ul>DBMS2 DBMS1 JDBC Application Program Use JDBC API SPI
    17. 17. Service Engine <ul><li>Hosts business logic implementing services </li></ul><ul><li>Exposes service endpoints </li></ul><ul><li>Is a target for deployment — a container </li></ul>
    18. 18. Binding Component <ul><li>Handles protocol-specific message re-formatting </li></ul><ul><li>Should contain no business logic </li></ul><ul><li>與 外部 服務的 溝通 </li></ul>
    19. 19. N ormalized M essage R outer <ul><li>The normalized message router, or NMR , receives message exchanges from JBI components (engines or bindings), and routes them to the appropriate component for processing. </li></ul><ul><ul><li>decoupling </li></ul></ul><ul><li>The JBI environment's primary function is to route normalized message exchanges from one component to another. </li></ul><ul><ul><li>Messages are delivered in a normalized form . </li></ul></ul>NMR normalize De-normalize component normalize De-normalize component
    20. 20. N ormalized M essage R outer (Cont’d)
    21. 21. Message Exchange <ul><li>A Message Exchange (ME) serves as a “ container ” for the normalized messages that are part of a service invocation. </li></ul><ul><li>JBI supports a fixed set of message exchange patterns </li></ul><ul><ul><li>a well-defined sequence of message exchanges between the consumer and the provider. </li></ul></ul><ul><li>A message exchange pattern (or MEP) no matter what contents (or type) of the messages themselves. By supporting a limited set of MEPs, the JBI standard ensures that components have a simple, well known interaction model to implement, ensuring interoperability . </li></ul>
    22. 22. JBI Messaging Architecture
    23. 23. Normalized Message Exchange (1) <ul><li>External Service Consumer Message Processing </li></ul>
    24. 24. Normalized Message Exchange (2) <ul><li>External Service Provider Message Processing </li></ul>
    25. 25. Example <ul><li>One-way Message Adapter </li></ul><ul><ul><li>A message is sent to the JBI environment, transformed, then sent to a destination outside of the environment. </li></ul></ul>
    26. 26. Service Invocation to MEP Mapping
    27. 27. Message Exchange Patterns (MEPs) <ul><li>An MEP defines the sequence, direction, and cardinality of all messages that occur in the course of invoking and performing the operation. </li></ul><ul><li>All message exchanges between consumer and provider are mediated by the NMR. </li></ul><ul><li>The components interact with the NMR, using their individual DeliveryChannels </li></ul><ul><ul><li>Sending MessageExchange instance </li></ul></ul><ul><ul><li>Accepting MessageExchange instance </li></ul></ul><ul><li>MEPs </li></ul><ul><ul><li>In-only Message Exchange Pattern </li></ul></ul><ul><ul><li>Robust In-Only Message Exchange Pattern </li></ul></ul><ul><ul><li>In-Out Message Exchange Pattern </li></ul></ul><ul><ul><li>In-Optional-Out Message Exchange Pattern </li></ul></ul>
    28. 28. In-only Message Exchange Pattern <ul><li>Describing a one-way messaging pattern </li></ul>
    29. 29. Robust In-Only Message Exchange Pattern (fault scenario) <ul><li>Allowing the provider to easily return error responses to in-only message exchange </li></ul>
    30. 30. In-Out Message Exchange Pattern <ul><li>Normal response </li></ul>
    31. 31. In-Out Message Exchange Pattern (Cont’d) <ul><li>Fault response </li></ul>
    32. 32. In-Optional-Out Message Exchange Pattern <ul><li>Normal response 1 </li></ul>
    33. 33. In-Optional-Out Message Exchange Pattern (Cont’d) <ul><li>Normal response 2 </li></ul>
    34. 34. In-Optional-Out Message Exchange Pattern (Cont’d) <ul><li>Provider fault response </li></ul>
    35. 35. In-Optional-Out Message Exchange Pattern (Cont’d) <ul><li>Provider “done” response </li></ul>
    36. 36. One-way Service Invocation Between two Service Engines
    37. 37. SE Invokes Service Provided by Remote JBI Instance: Robust In with Fault
    38. 38. SE Invokes Remote Service
    39. 39. Management (JMX) <ul><li>The JBI environment, including bindings and engines, is administered through JMX. (MBean) </li></ul><ul><ul><li>Installation of engines and bindings (components) </li></ul></ul><ul><ul><li>Life cycle management of components (start/stop controls) </li></ul></ul><ul><ul><li>Deployment of component artifacts to engines and bindings that support dynamic additions to their internal execution environments. </li></ul></ul><ul><ul><li>Monitoring and control. </li></ul></ul>
    40. 40. Conclusion (Keywords) <ul><li>JSR 208 (SOA infrastructure/enabler) </li></ul><ul><li>Meta-container (JBI Environment / JBI Container) </li></ul><ul><li>Plug-in </li></ul><ul><li>WSDL 2.0 </li></ul><ul><li>JMX (Management) </li></ul><ul><li>Messaging (NMR) </li></ul><ul><li>SE & BC </li></ul><ul><li>ESB enabler </li></ul><ul><li>Assembling JBI-compliant component </li></ul><ul><li>Installation (AP server, EJB Container, BPEL engine) </li></ul><ul><ul><li>Installing it into the JBI environment thanks to JMX based administrative tools </li></ul></ul><ul><li>Deployment (BPEL process definition) </li></ul><ul><ul><li>JBI component can be seen as a container (ex: BPEL engine) </li></ul></ul><ul><ul><li>Services (ex: BPEL) must be deployed into the component thanks to JBI administrative tools </li></ul></ul><ul><li>Activation </li></ul><ul><ul><li>After deployment, services are accessible through the JBI environment as Endpoints </li></ul></ul>
    41. 41. Reference
    42. 42. Reference <ul><li>Sun SOA Home </li></ul><ul><ul><li>http://www.sun.com/products/soa/index.jsp </li></ul></ul><ul><li>The Java EE 5 Tutorial </li></ul><ul><ul><li>http://java.sun.com/javaee/5/docs/tutorial/doc/ </li></ul></ul><ul><li>Java EE At a Glance </li></ul><ul><ul><li>http://java.sun.com/javaee/ </li></ul></ul><ul><li>Project Open ESB </li></ul><ul><ul><li>https://open-esb.dev.java.net/ </li></ul></ul><ul><li>LogicBlaze FUSE: Open source SOA platform </li></ul><ul><ul><li>http://www.logicblaze.com/index.jsp </li></ul></ul><ul><li>ServiceMix Home </li></ul><ul><ul><li>http://servicemix.org/site/home.html </li></ul></ul><ul><li>ActiveMQ Home </li></ul><ul><ul><li>http://www.activemq.org/site/home.html </li></ul></ul><ul><li>PETALS Services Platform </li></ul><ul><ul><li>http://petals.objectweb.org/ </li></ul></ul><ul><li>Mule Home </li></ul><ul><ul><li>http://mule.codehaus.org/ </li></ul></ul><ul><li>Celtix </li></ul><ul><ul><li>http://celtix.objectweb.org/ </li></ul></ul><ul><li>JBoss JEMS - The Open Source Platform for SOA </li></ul><ul><ul><li>http://www.jboss.com/products/soa </li></ul></ul><ul><li>Oracle Service-Oriented Architecture Technology Center </li></ul><ul><ul><li>http://www.oracle.com/technology/tech/webservices/index.html </li></ul></ul>
    43. 43. Reference (Cont’d) <ul><li>Sun SOA Home </li></ul><ul><ul><li>http://www.sun.com/products/soa/index.jsp </li></ul></ul><ul><li>JCP (Java Community Process) </li></ul><ul><ul><li>http://jcp.org/en/home/index </li></ul></ul><ul><li>JSR 208 (JBI) </li></ul><ul><ul><li>http://jcp.org/en/jsr/detail?id=208 </li></ul></ul>
    44. 44. Appendix
    45. 45. ESB <ul><ul><li>ServiceMix </li></ul></ul><ul><ul><li>Apache Synapsele </li></ul></ul><ul><ul><li>Mule </li></ul></ul><ul><ul><li>Celtix </li></ul></ul><ul><ul><li>Sun’s Java Open Enterprise Service Bus </li></ul></ul>
    46. 46. ServiceMiX <ul><li>Open Source JBI Container based on JBI Specification (JSR208) </li></ul><ul><li>Supports Transaction Management through Jencks and Java Transaction API (JTA) </li></ul><ul><li>Supports Java Message Service (JMS) through ActiveMQ </li></ul><ul><li>Can extend any J2EE compliant Server with JBI by simply deploying Servicemix (e.g. Geronimo) </li></ul>
    47. 47. ServiceMix
    48. 48. (ServiceMix) Standard Component-Binding Component <ul><li>HTTP </li></ul><ul><li>FTP </li></ul><ul><li>File </li></ul><ul><li>RSS </li></ul><ul><li>Email </li></ul><ul><li>SOAP </li></ul><ul><li>WSIF (Web Service Invocation Framework) </li></ul><ul><li>SAAJ (Soap With Attachments and Apache Axis) </li></ul><ul><li>JAX WS (Java API for XML Web Services) </li></ul><ul><li>XSQL (XML Query Language) </li></ul><ul><li>JMS (Java Message Service) </li></ul>
    49. 49. (ServiceMix) Standard Component-Service Engine <ul><li>BPE (Container for BPEL) </li></ul><ul><li>EIP (Enterprise Integration Patterns) </li></ul><ul><li>Groovy (Container for Scripting) </li></ul><ul><li>JCA (Java Connector Architecture) </li></ul><ul><li>JSR181 (Container for annotated POJOs) </li></ul><ul><li>Quartz (Timer) </li></ul><ul><li>XPath (Message Transformation with XPath) </li></ul><ul><li>XSLT (Message Transformation with XSLT) </li></ul>
    50. 50. ServiceMix
    51. 51. (ServiceMix) Straight-throw flow
    52. 52. (ServiceMix) Seda Flow
    53. 53. (ServiceMix) JMS Flow
    54. 54. Basic Example Message Flow Diagram
    55. 55. Basic Example Message Flow Diagram <ul><li>Messages flow through the components as follows: </li></ul><ul><ul><li>The timer component sends a message to inputSender through the Normalized Message Router (NMR). </li></ul></ul><ul><ul><li>inputSender converts the message (marshals it) into a JMS message, then uses the jmsTemplate bean to publish the message. </li></ul></ul><ul><ul><li>jmsTemplate uses the jmsFactory bean to get a connection to the port associated with the JMS topic called &quot;demo.org.servicemix.source.&quot; The message is published on the &quot;demo.org.servicemix.source&quot; topic. </li></ul></ul><ul><ul><li>jencks (the JCA resource adapter) listens on port 61616 for messages. </li></ul></ul><ul><ul><li>inputReceiver subscribes to the &quot;demo.org.servicemix.source&quot; topic via jencks and receives the JMS message. </li></ul></ul><ul><ul><li>inputReceiver normalizes the JMS message and sends it to outputSender via the NMR. </li></ul></ul><ul><ul><li>outputSender marshals the normalized message to a JMS message and uses jmsTemplate to publish the message on the &quot;demo.org.servicemix.result&quot; topic. </li></ul></ul><ul><ul><li>jmsTemplate publishes it on the &quot;demo.org.servicemix.result&quot; topic using jmsFactory to get a connection to the result topic. </li></ul></ul><ul><ul><li>jencks listens on port 61616 for messages. </li></ul></ul><ul><ul><li>jmsTrace subscribes to the &quot;demo.org.servicemix.result&quot; topic and receives the JMS message via jencks . </li></ul></ul><ul><ul><li>jmsTrace converts the JMS message into a normalized message and sends it to trace via the NMR. </li></ul></ul><ul><ul><li>trace transforms the normalized message into a string and logs it to the console. </li></ul></ul>
    56. 56. Basic Example Message Flow Diagram <ul><li>Using the distributor&apos;s web interface, a department store customer submits an order for multiple products. An HTTP request is sent to the OrderReceiver , an HTTP binding component (BC). 3 </li></ul><ul><li>The OrderReceiver sends the message to an OrderRouter service engine (SE) 4 component. This SE is responsible for parsing the order and deciding, based on the message content, which OrderTransformer should receive which part of the message (i.e., an order for a product). </li></ul><ul><li>The OrderRouter publishes the orders to the appropriate message topics based on the message content. Specifically, the OrderRouter publishes the messages based on which wholesaler sells the item. </li></ul><ul><li>The OrderTransformer is a service engine component, which modifies the message and puts it in a format which is readable by the wholesaler interface that will fulfill the order. </li></ul><ul><li>Each OrderTransformer sends the modified message to the OrderProcessor . </li></ul><ul><li>The OrderProcessor is a binding component that has two functions: a. It places an order to the appropriate wholesaler through the wholesaler&apos;s Webservice or proprietary interface. b. It also publishes a message about the order on a topic. </li></ul><ul><li>The message on the topic is subsequently picked up by the BusinessMonitor component via the jmsTrace component. </li></ul><ul><li>The BusinessMonitor component monitors the orders for quality assurance and business analytics, such as data mining. </li></ul>
    57. 57. Basic Example Message Flow Diagram
    58. 58. BPEL Logical Flow Diagram
    59. 59. File Binding Logical Flow Diagram
    60. 60. HTTP Binding Example Message Flow Diagram
    61. 61. JMS Binding Example Message Flow Diagram
    62. 62. Quartz Example Message Flow Diagram
    63. 63. RSS Binding Example Message Flow Diagram
    64. 64. Department Store Distributor Order Processing System
    65. 66. Online Ticket Reservation System
    66. 67. Online Application for Tax ID No. System
    67. 68. Department of Public Works Project Monitoring System
    68. 69. Network Status Indicator
    69. 70. News Feed Monitoring System
    70. 72. Mule <ul><li>Implementing ESB </li></ul>
    71. 73. Reliable One-way MEP with Fault Message Sequence Chart
    72. 74. Reliable Two-way Exchange Message Sequence Chart
    73. 75. One-way Transactional Message Exchange
    74. 76. A simple integration problem using JBI <ul><li>Example: Adapter Pattern </li></ul>
    75. 77. JBI Components for Adapter Application
    76. 78. <ul><li>SU </li></ul><ul><li>SE-Tx: Transformation Service </li></ul><ul><li>BC-Y: Provider Service Proxy </li></ul><ul><li>SE-Seq: Adapter Logic </li></ul><ul><li>BC-X: Client Service Proxy </li></ul>
    77. 79. Graphic View of Adapter Service Assembly <ul><li>SA </li></ul>
    78. 80. Adapter Pattern Message Sequence Diagram
    79. 81. JBI Component Installation Time
    80. 83. JBI Component Execution Time
    81. 84. Component Interaction -- Service Consumer <ul><li>Find a service endpoint </li></ul><ul><li>Create a message exchange </li></ul><ul><li>Send the message </li></ul>
    82. 85. Component Interaction -- Service Provider <ul><li>Activate an endpoint </li></ul><ul><li>Receive a message </li></ul><ul><li>Send the response </li></ul><ul><li>Close the exchange </li></ul>
    83. 87. SOA Architecture Principles <ul><li>Well-defined service interfaces </li></ul><ul><li>Loose coupling </li></ul><ul><li>Document-based, mostly asynchronous, conversational interactions </li></ul><ul><li>Service registration and discovery </li></ul>
    84. 88. To Form Ideal SOA Infrastructure <ul><li>Combine the best of previous technologies </li></ul>
    85. 89. JBI Architecture
    86. 90. Bring it Together
    87. 91. Assembling Services into Processes
    88. 92. Events-Driven Application Models <ul><li>Asynchronous One-way Communication </li></ul><ul><ul><li>Simple Events </li></ul></ul><ul><ul><li>Brokered Events </li></ul></ul><ul><ul><li>Enterprise Service Busses </li></ul></ul><ul><ul><li>Event Stream Processing Engines </li></ul></ul>
    89. 93. Simple Events <ul><li>Simple Events </li></ul><ul><ul><li>Simulating Request/Reply </li></ul></ul>
    90. 94. Brokered Event <ul><li>Brokered Event </li></ul><ul><ul><li>Point to point (Send to One Interested Party ) </li></ul></ul>
    91. 95. <ul><li>Enterprise Service Bus - Orchestration Service </li></ul><ul><li>Event Stream Processing (ESP) </li></ul>
    92. 96. SOA and Events Service Consumer Service Provider Event Sink Event Source Service Consumer Notification One-way Event Sink Event Source Service Provider
    93. 97. ESB enables SOA and EDA <ul><li>SOA – Service Oriented Architecture </li></ul><ul><ul><li>Distributed, Web Services </li></ul></ul><ul><ul><li>WSDL, SOAP, XML, XSD </li></ul></ul><ul><ul><li>Registry Lookup, UDDI </li></ul></ul><ul><ul><li>Request / Reply </li></ul></ul><ul><li>EDA – Event Driven Enterprise </li></ul><ul><ul><li>Message Oriented </li></ul></ul><ul><ul><li>Qualities of Service </li></ul></ul><ul><ul><li>Asynchronous Publish / Subscribe </li></ul></ul>
    94. 98. JBI Messaging <ul><li>JBI defines a model and the APIs for messaging between JBI components </li></ul><ul><li>All types of interaction </li></ul><ul><ul><li>One-Way </li></ul></ul><ul><ul><li>Reliable One-Way </li></ul></ul><ul><ul><li>Request Response </li></ul></ul><ul><ul><li>Request Optional-Response </li></ul></ul><ul><li>Messaging API </li></ul><ul><ul><li>Components send messages to the JBI container </li></ul></ul><ul><ul><li>Components read messages from the JBI container </li></ul></ul><ul><li>JBI vs JMS </li></ul>
    95. 99. JBI Addressing <ul><li>An interface is a group of operations </li></ul><ul><li>A service implements an interface represented by qualified name and its WSDL definition </li></ul><ul><li>A service has one or more endpoints accessible by different bindings </li></ul><ul><li>Endpoints can be </li></ul><ul><ul><li>external for services accessible via a binding component </li></ul></ul><ul><ul><li>internal for services provided by a service engine </li></ul></ul>
    96. 100. JBI Component Packaging (installation) <ul><li>Write an XML descriptor for the component </li></ul><ul><ul><li>the deployment descriptor </li></ul></ul><ul><li>Package the descriptor with component logic in a JAR archive </li></ul><ul><li>Install the component in JBI environment </li></ul><ul><li>Component deployment descriptor </li></ul>
    97. 101. Deployment <ul><li>Provide services to JBI environment through the JBI component </li></ul><ul><li>Service (component artifact) is described by XML descriptor and packaged as “Service Unit” ( SU ) </li></ul><ul><li>Services that have to be deployed into different components to produce a new application can be grouped into a “Service Assembly” ( SA ). </li></ul><ul><li>The SA contains an XML descriptor to describe how each SU is deployed on its target component </li></ul><ul><li>Service assembly deployment descriptor </li></ul>
    98. 102. Components and Artifacts Lifecycle <ul><li>Components and artifacts are managed with the same unified lifecycle </li></ul><ul><li>Lifecycle management is accessible by admin tools via standard JMX MBean defined by the specification </li></ul>
    99. 103. Applying JBI With ESB <ul><li>Open ESB </li></ul><ul><ul><li>Sun's Open Source Enterprise Service Bus </li></ul></ul><ul><ul><li>A standard, distributed integration infrastructure </li></ul></ul><ul><ul><li>Highly distributed scalable JBI services </li></ul></ul><ul><ul><li>Uses JBI Reference Implementation code </li></ul></ul><ul><ul><li>Based on MOM—async XML message exchanges </li></ul></ul><ul><ul><li>Centralized management </li></ul></ul><ul><ul><li>Standard deployment of composite services </li></ul></ul><ul><ul><li>QOS characteristics </li></ul></ul><ul><li>Open ESB Architecture </li></ul>
    100. 104. Integration Solution: Proxy Service
    101. 105. Integration Solution: Proxy Service <ul><li>Composite App: Service Assembly </li></ul><ul><ul><li>A collection of service unit </li></ul></ul><ul><li>Proxy service deployment </li></ul>
    102. 106. Composite Application Using JBI
    103. 108. BPEL
    104. 109. JBI <ul><li>Service based </li></ul><ul><ul><li>Plug-in components serve roles </li></ul></ul><ul><ul><ul><li>Service provider, consumer, both </li></ul></ul></ul><ul><ul><li>Providers supply self-description </li></ul></ul><ul><ul><ul><li>Messages </li></ul></ul></ul><ul><ul><ul><li>Operations and message exchange patterns </li></ul></ul></ul><ul><ul><ul><li>Services </li></ul></ul></ul><ul><ul><ul><li>Endpoints </li></ul></ul></ul><ul><ul><ul><li>… All using WSDL </li></ul></ul></ul><ul><li>Service Engines </li></ul><ul><ul><li>Provide local services </li></ul></ul><ul><ul><ul><li>Business Processes (orchestration: BPEL4WS) </li></ul></ul></ul><ul><ul><ul><li>Transformation (XSLT, EDI) </li></ul></ul></ul><ul><ul><ul><li>Business Logic (EJBs) </li></ul></ul></ul><ul><ul><ul><li>Integrated Java technology-based apps </li></ul></ul></ul><ul><ul><li>Consume services </li></ul></ul><ul><ul><ul><li>Orchestration </li></ul></ul></ul><ul><ul><li>No Restrictions </li></ul></ul><ul><li>Binding Components </li></ul><ul><ul><li>Proxy for remote service providers </li></ul></ul><ul><ul><ul><li>Protocol: SOAP, AS2, ebXML MSH, XML-over-HTTP, EDI, etc. </li></ul></ul></ul><ul><ul><li>Access for remote service consumers </li></ul></ul><ul><ul><ul><li>Protocol access to </li></ul></ul></ul><ul><ul><ul><ul><li>SE-provided services </li></ul></ul></ul></ul><ul><ul><ul><ul><li>BC-proxied services </li></ul></ul></ul></ul><ul><ul><li>Contain no business logic </li></ul></ul><ul><ul><ul><li>Convention: break at your peril </li></ul></ul></ul><ul><ul><li>No Restrictions </li></ul></ul>
    105. 110. Normalized Message Router <ul><li>Key to interoperation between components </li></ul><ul><li>Mediated Message Exchange </li></ul><ul><li>Normalized Message </li></ul><ul><ul><li>Abstract Message (payload) + Message Properties (metadata) </li></ul></ul><ul><ul><li>WSDL Abstract Message </li></ul></ul><ul><ul><ul><li>WSDL interface operation message definition </li></ul></ul></ul><ul><ul><li>Properties (metadata) </li></ul></ul><ul><ul><ul><li>Protocol-supplied context information </li></ul></ul></ul><ul><ul><ul><li>Security tokens </li></ul></ul></ul><ul><ul><ul><li>Transaction information </li></ul></ul></ul><ul><ul><ul><li>Data other components may recognize </li></ul></ul></ul><ul><li>Message Exchange Pattern </li></ul><ul><ul><li>Support for simple communications primitives </li></ul></ul><ul><ul><li>Message exchange patterns are defined from the provider’s perspective </li></ul></ul>
    106. 111. Inside Message Exchange Handling
    107. 112. JBI <ul><li>JBI is a messaging-based plug-in architecture </li></ul><ul><li>JBI does not define the pluggable component themselves, but </li></ul><ul><ul><li>Defines the framework, container interface, behavior, and common services </li></ul></ul><ul><li>JBI allows anyone to create JBI compliant integration plug-in component and integrate them dynamically into the JBI infrastructure </li></ul><ul><li>Key pieces of the JBI environment </li></ul><ul><ul><li>SE </li></ul></ul><ul><ul><li>BC </li></ul></ul><ul><ul><li>NMR </li></ul></ul><ul><ul><li>JBI runtime environment (JBI meta container) </li></ul></ul>
    108. 113. JBI <ul><li>JBI is an architecture for integration systems specifying plug-in components that interoperate by exchanging messages, rather than by interacting directly. This decoupling increases flexibility because each component needs to know how to interact with the JBI bus only and not with n number of other components. JBI components provide services, consume services, or sometimes both. There are two types of components: Service Engines (SE) and Binding Components (BC). The SEs provide business logic and transformation services. The BCs provide connectivity for applications that are external to the JBI. The separation of business and processing logic from communication logic makes the implementation of components much less complex. </li></ul><ul><li>The mediated message exchange between components is provided by the Normalized Message Router (NMR). The NMR routes normalized messages between service providers and consumers. A normalized message consists of two parts: the message content (payload) and the message metadata. The message metadata contains information such as security information, that can affect the processing of the message as it routes through the JBI. Messages flowing into the JBI, via binding components, are translated into a normalized (neutral) format, then routed to their destination. Prior to final delivery the normalized message is translated into the appropriate format for the recipient. A message can be routed through several JBI components depending on what processing is needed. </li></ul><ul><li>The JBI environment also supplies a set of services for self management, including services for component installation and life cycle management of components. </li></ul><ul><li>In summary, the JBI specification creates a standards-based technology for enterprise application integration. </li></ul>
    109. 114. JBI <ul><li>LogicBlaze has implemented the ServiceMix ESB based on the JBI (JSR 208) specification in order to create a standards based ESB and the ServiceMix ESB combines the functionality of both a Service Oriented Architecture (S0A) and Event Driven Architecture (EDA) to achieve an agile, enterprise ESB. </li></ul><ul><li>ServiceMix supports event driven architecture for events occurring both internal and external to the bus. In other words, JMS binding components can listen for the arrival of messages, i.e., the &quot;event&quot; on topics or queues which are external to the bus, while other components can listen for messages on the normalized message bus. </li></ul><ul><li>JSR 208 describes a set of Java APIs to interact with an implementation of a Java-based Enterprise Service Bus (ESB). This ESB must provide for the integration of disparate service components, enabling them to communicate with their consumers or clients through a myriad of communications modules. </li></ul><ul><li>It is specified as a set of Java based APIs and component packaging conventions that all JBI compliant ESB implementations must follow. The JBI 1.0 APIs attempt to ensure that Java components developed can be deployed and executed across different vendors’ ESB implementations. </li></ul><ul><li>All plug-in components on the ESB, regardless of type (SE or BC), and regardless of role (consumer or provider), all communicate in the same way. </li></ul><ul><li>All components on the ESB communicate with one another by passing messages. </li></ul>
    110. 115. <ul><li>The ESB will only work with normalized messages, i.e. ones with protocol specificity removed. This means that you cannot tell, from examining the message, the connection or protocol over which it was sent. </li></ul><ul><li>A component must normalize any message before sending it to the ESB. Similarly, if a BC needs to send a message to an external system (outside of the ESB), the message must be denormalized before further routing or use. Denormalization puts back communications protocol-dependent frames, headers, and other information. This is the reason why an ESB is often also called a NMR or Normalized Message Router. </li></ul>
    111. 116. <ul><li>Services that need to be accessed by the ESB are accessed as endpoints. </li></ul><ul><li>Endpoint is how a service is addressed by the ESB. </li></ul><ul><li>Service is the actual business entity the performs the desired function </li></ul><ul><li>Service units provide information about the services and their endpoints to the component </li></ul><ul><li>Service assembly is how several service units are packaged and deployed on to target components </li></ul><ul><li>Integrating old and new components and services using a service-oriented architecture requires an infrastructure that can connect any component or service, regardless of location, messaging protocol, and message format. To orchestrate existing services and components to meet the needs of today's dynamic business climate, this infrastructure must be highly customizable. The enterprise service bus (ESB) infrastructure fulfills these requirements. </li></ul>
    112. 117. <ul><li>Enterprise service bus (ESB) is a centralized, logical, architectural component that operates in a distributed, heterogeneous environment to facilitate the requirements of a highly scalable, fault-tolerant, service-messaging framework. </li></ul><ul><li>JBI embodies a messaging model based on Web Services Description Language (WSDL) for easy mapping to Web services, HTTP, email, and JMS. JBI integrates with legacy systems, binary transports, document-oriented transports, and RPC (remote procedure call) systems. </li></ul><ul><li>Message normalization is the process of mapping context-specific data to a context-neutral abstraction to transport data in a standard format. All messages handled by the NMR are normalized. </li></ul><ul><li>An NMR is not embodied by any concrete object. It is abstracted as a set of APIs, SPIs (service provider interfaces), and components. The NMR APIs include: </li></ul><ul><ul><li>JBI Message API </li></ul></ul><ul><ul><li>JBI Service API </li></ul></ul><ul><ul><li>JBI Message Exchange Factory API </li></ul></ul><ul><ul><li>Service Description SPI </li></ul></ul><ul><ul><li>Message Exchange Patterns API </li></ul></ul><ul><ul><li>Endpoint Reference API </li></ul></ul>
    113. 118. <ul><li>JBI supports two kinds of components, service engines and binding components. Components interact with JBI in two ways: </li></ul><ul><ul><li>SPIs: Interfaces implemented by a binding or engine </li></ul></ul><ul><ul><li>APIs: Interfaces exposed to bindings or engines by the framework </li></ul></ul><ul><li>An external service consumer sends a service request across a specific protocol and transport to a binding component. The binding component converts the request to a normalized message. The binding component then creates a message packet called a message exchange (ME) and sends it across the binding component's delivery channel to the NMR for delivery to a service provider. </li></ul>

    ×