java business integration (jbi)

Click here to load reader

Post on 16-Dec-2014




0 download

Embed Size (px)




  • 1. Java Business Integration JSR 208 Chin-Yi Tsai [email_address]

2. Integration Difficulties 3. IntegrationSolution Services(WS- I ) (interoperability) Components (pluggable) (interoperability) EnterpriseServiceBus 4. Specification ( Java EE 5 ) Java Business Integration JSR 208 JBI-Compliant Component1 JBI-Compliant Component2 JBI Environment / JBI Container 5. ESB, SOA, JBI

  • ESB
    • Architecture technique to integrate incompatible business applications over acommon messaging bus .
    • Unlock and extend your existing systems and technology investments on a modernService Oriented and Event Driven Architecture
  • SOA
    • Anarchitectural principleforstructuring systemsthat SOA emphasizes thede-couplingof system components
  • ESB & SOA
    • ESB is one architecture style that abides by the rules of a Service Orientated Architecture.
  • JBI
    • Defines commoninterfaces (SPI)for components and message exchanges and service deployment.

6. What Does a Service Do

  • Transform data
  • Route messages
  • Query databases
  • Orchestrate conversations
  • Apply business logic
  • Apply business policy
  • Handle business exceptions
  • Solicit approvals

How Is a Service Implemented?

  • XSLT
  • Enterprise JavaBeans. (EJB.) technology
  • BPEL
  • SQL
  • XQuery
  • Routing Table
  • Business Rules
  • EDI Transform

7. Outline

  • Overview of JBI
    • integration
  • JBI Architecture
    • SE
    • BC
    • NMR
    • JMX (Management)
  • Conclusion (Keywords)
  • Reference
  • Appendix

8. Overview of JBI

  • Standard meta-container for services
  • Standard SPI for plug-in
    • Service Engines provide and aggregate services
    • Binding Components provide protocols and transports
  • Loose coupling via WSDL message exchanges
  • JBI defines an environment forplug-in componentsthat interact using a services model based directly onWSDL 2.0

(plug-in) 9. Component as Container

  • JBI directly supports the deployment of artifacts to plug-in components, using an archive (ZIP file) package called aservice unit .

10. Component as Container (Contd)

  • Groups of service unitsare often developed or collected together, to form parts of a larger application or new service that are tested and deployed together.
  • A group of JBI service units, along with a description of their relationships and target components, is called aservice assembly .

11. Overview of JBI

  • Java Business Integration (JBI)is aspecificationdeveloped under the Java Community Process ( JCP ) for an approach to implementing a service-oriented architecture (SOA).
    • Creating astandards-basedarchitecture for integration solutions
    • A suitable standard technology instead of proprietary vendor solution
  • JBI defines an architecture that allows the construction of integration systems from plug-in components, that interoperate through the method of mediatedmessage exchange .

12. Overview of JBI (Contd)

  • JBI plug-incomponentsare responsible forprovidingandconsumingservices.

13. JBI Architecture

  • JBIprovides anenvironmentin which plug-in components reside.
    • 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.
  • JBIprovides forinteroperationbetween plug-in components by means ofmessage-basedservice invocation, described using a standard service description language.
  • JBIprovides a set of services to facilitatemanagementof the JBI environment, including the installed components. This includes component installation and life cycle management services.

Plug-in component Message exchange Management 14. High-level View of JBI Architecture Single JVM Other JVM

    • SE
    • BC
    • NMR
    • JMX (Management)

15. Component Framework

  • JBI components ( service engines and binding components ) provide interfaces for the use of JBI, and use interfaces provided by JBI.
  • The JBI framework provides the following for the use of components
    • Component installationcontext
    • Componentcontext
    • Class loading
    • Error indication

16. Standardized Integration

  • SPI (Service Provider Interface) not API
    • Allow for proprietary black boxes as integration services

DBMS2 DBMS1 JDBC Application Program Use JDBC API SPI 17. Service Engine

  • Hostsbusiness logic implementing services
  • Exposesservice endpoints
  • Is a target for deployment acontainer

18. Binding Component

  • Handlesprotocol-specificmessage re-formatting
  • Should contain no business logic

19. N ormalizedM essageR outer

  • The normalized message router, orNMR , receives message exchanges from JBI components (engines or bindings), and routes them to the appropriate component for processing.
    • decoupling
  • The JBI environment's primary function isto route normalized message exchangesfrom one component to another.
    • Messages are delivered in anormalized form .

NMR normalize De-normalize component normalize De-normalize component 20. N ormalizedM essageR outer (Contd) 21. Message Exchange

  • A Message Exchange (ME) serves as a container for the normalized messages that are part of a service invocation.
  • JBI supports a fixed set of message exchangepatterns
    • a well-defined sequence of message exchanges between the consumer and the provider.
  • Amessage 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, ensuringinteroperability .

22. JBI Messaging Architecture 23. Normalized Message Exchange (1)

  • External Service Consumer Message Processing

24. Normalized Message Exchange (2)

  • External Service Provider Message Processing

25. Example

  • One-way Message Adapter
    • A message is sent to the JBI environment, transformed, then sent to a destination outside of the environment.

26. Service Invocation to MEP Mapping 27. Message Exchange Patterns (MEPs)

  • An MEP defines the sequence, direction, and cardinality of all messages that occur in the course of invoking and performing the operation.
  • All message exchanges between consumer and provider are mediated by the NMR.
  • The components interact with the NMR, using their individualDeliveryChannels
    • SendingMessageExchangeinstance
    • AcceptingMessageExchangeinstance
  • MEPs
    • In-only Message Exchange Pattern
    • Robust In-Only Message Exchange Pattern
    • In-Out Message Exchange Pattern
    • In-Optional-Out Message Exchange Pattern

28. In-only Message Exchange Pattern

  • Describing a one-way messaging pattern

29. Robust In-Only Message Exchange Pattern (fault scenario)

  • Allowing the provider to easily return error responses to in-only message exchange

30. In-Out Message Exchange Pattern

  • Normal response

31. In-Out Message Exchange Pattern (Contd)

  • Fault response

32. In-Optional-Out Message Exchange Pattern

  • Normal response 1

33. In-Optional-Out Message Exchange Pattern (Contd)

  • Normal response 2

34. In-Optional-Out Message Exchange Pattern (Contd)

  • Provider fault response

35. In-Optional-Out Message Exchange Pattern (Contd)

  • Provider done response

36. One-way Service Invocation Between two Service Engines 37. SE Invokes Service Provided by Remote JBI Instance: Robust In with Fault 38. SE Invokes Remote Service 39. Management (

View more