Java Business Integration JSR 208 - PowerPoint PPT Presentation

1 / 118
About This Presentation
Title:

Java Business Integration JSR 208

Description:

http://www.oracle.com/technology/tech/webservices/index.html. 43. Programming ... http://www.sun.com/products/soa/index.jsp. JCP (Java Community Process) ... – PowerPoint PPT presentation

Number of Views:218
Avg rating:3.0/5.0
Slides: 119
Provided by: pmlabIec
Category:
Tags: jsr | business | com | integration | java | jcp

less

Transcript and Presenter's Notes

Title: Java Business Integration JSR 208


1
Java Business IntegrationJSR 208
  • Chin-Yi Tsai
  • cyt_at_pmlab.iecs.fcu.edu.tw
  • http//140.134.26.25/cyt

2
Integration Difficulties
3
Integration Solution
Services (WS-I)
(interoperability)
Components (pluggable) (interoperability)
4
Specification(?Java EE 5????)Java Business
IntegrationJSR 208
JBI-Compliant Component1
JBI-Compliant Component2
5
ESB, SOA, JBI
  • ESB
  • Architecture technique to integrate incompatible
    business applications over a common messaging
    bus.
  • Unlock and extend your existing systems and
    technology investments on a modern Service
    Oriented and Event Driven Architecture
  • SOA
  • An architectural principle for structuring
    systems that SOA emphasizes the de-coupling of
    system components
  • ESB SOA
  • ESB is one architecture style that abides by the
    rules of a Service Orientated Architecture.
  • JBI
  • Defines common interfaces (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 for plug-in components
    that interact using a services model based
    directly on WSDL 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 a service unit.

10
Component as Container (Contd)
  • 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.
  • A group of JBI service units, along with a
    description of their relationships and target
    components, is called a service assembly.

11
Overview of JBI
  • Java Business Integration (JBI) is a
    specification developed under the Java Community
    Process (JCP) for an approach to implementing a
    service-oriented architecture (SOA).
  • Creating a standards-based architecture 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 mediated message exchange.

12
Overview of JBI (Contd)
  • JBI plug-in components are responsible for
    providing and consuming services.

13
JBI Architecture
  • JBI provides an environment in 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.
  • JBI provides for interoperation between plug-in
    components by means of message-based service
    invocation, described using a standard service
    description language.
  • 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.

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 installation context
  • Component context
  • Class loading
  • Error indication

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

17
Service Engine
  • Hosts business logic implementing services
  • Exposes service endpoints
  • Is a target for deployment a container

18
Binding Component
  • Handles protocol-specific message re-formatting
  • Should contain no business logic
  • ????????

19
Normalized Message Router
  • The normalized message router, or NMR, 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 is to
    route normalized message exchanges from one
    component to another.
  • Messages are delivered in a normalized form.

NMR
normalize
normalize
component
component
De-normalize
De-normalize
20
Normalized Message Router (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 exchange
    patterns
  • a well-defined sequence of message exchanges
    between the consumer and the provider.
  • 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.

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
    individual DeliveryChannels
  • Sending MessageExchange instance
  • Accepting MessageExchange instance
  • 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 (JMX)
  • The JBI environment, including bindings and
    engines, is administered through JMX. (MBean)
  • Installation of engines and bindings (components)
  • Life cycle management of components (start/stop
    controls)
  • Deployment of component artifacts to engines and
    bindings that support dynamic additions to their
    internal execution environments.
  • Monitoring and control.

40
Conclusion (Keywords)
  • JSR 208 (SOA infrastructure/enabler)
  • Meta-container (JBI Environment / JBI Container)
  • Plug-in
  • WSDL 2.0
  • JMX (Management)
  • Messaging (NMR)
  • SE BC
  • ESB enabler
  • Assembling JBI-compliant component
  • Installation (AP server, EJB Container, BPEL
    engine)
  • Installing it into the JBI environment thanks to
    JMX based administrative tools
  • Deployment (BPEL process definition)
  • JBI component can be seen as a container (ex
    BPEL engine)
  • Services (ex BPEL) must be deployed into the
    component thanks to JBI administrative tools
  • Activation
  • After deployment, services are accessible through
    the JBI environment as Endpoints

41
Reference
42
Reference
  • Sun SOA Home
  • http//www.sun.com/products/soa/index.jsp
  • The Java EE 5 Tutorial
  • http//java.sun.com/javaee/5/docs/tutorial/doc/
  • Java EE At a Glance
  • http//java.sun.com/javaee/
  • Project Open ESB
  • https//open-esb.dev.java.net/
  • LogicBlaze FUSE Open source SOA platform
  • http//www.logicblaze.com/index.jsp
  • ServiceMix Home
  • http//servicemix.org/site/home.html
  • ActiveMQ Home
  • http//www.activemq.org/site/home.html
  • PETALS Services Platform
  • http//petals.objectweb.org/
  • Mule Home
  • http//mule.codehaus.org/
  • Celtix
  • http//celtix.objectweb.org/
  • JBoss JEMS - The Open Source Platform for SOA
  • http//www.jboss.com/products/soa
  • Oracle Service-Oriented Architecture Technology
    Center
  • http//www.oracle.com/technology/tech/webservices/
    index.html

43
Reference (Contd)
  • Sun SOA Home
  • http//www.sun.com/products/soa/index.jsp
  • JCP (Java Community Process)
  • http//jcp.org/en/home/index
  • JSR 208 (JBI)
  • http//jcp.org/en/jsr/detail?id208

44
Appendix
45
ESB
ServiceMix Apache Synapsele Mule Celtix Suns
Java Open Enterprise Service Bus
46
ServiceMiX
  • Open Source JBI Container based on JBI
    Specification (JSR208)
  • Supports Transaction Management through Jencks
    andJava Transaction API (JTA)
  • Supports Java Message Service (JMS) through
    ActiveMQ
  • Can extend any J2EE compliant Server with JBI by
    simply deploying Servicemix (e.g. Geronimo)

47
ServiceMix
48
(ServiceMix) Standard Component-Binding Component
  • HTTP
  • FTP
  • File
  • RSS
  • Email
  • SOAP
  • WSIF (Web Service Invocation Framework)
  • SAAJ (Soap With Attachments and Apache Axis)
  • JAX WS (Java API for XML Web Services)
  • XSQL (XML Query Language)
  • JMS (Java Message Service)

49
(ServiceMix) Standard Component-Service Engine
  • BPE (Container for BPEL)
  • EIP (Enterprise Integration Patterns)
  • Groovy (Container for Scripting)
  • JCA (Java Connector Architecture)
  • JSR181 (Container for annotated POJOs)
  • Quartz (Timer)
  • XPath (Message Transformation with XPath)
  • XSLT (Message Transformation with XSLT)

50
ServiceMix
51
(ServiceMix) Straight-throw flow
52
(ServiceMix) Seda Flow
53
(ServiceMix) JMS Flow
54
Basic Example Message Flow Diagram
55
Basic Example Message Flow Diagram
  • Messages flow through the components as follows
  • The timer component sends a message to
    inputSender through the Normalized Message Router
    (NMR).
  • inputSender converts the message (marshals it)
    into a JMS message, then uses the jmsTemplate
    bean to publish the message.
  • jmsTemplate uses the jmsFactorybean to get a
    connection to the port associated with the JMS
    topic called "demo.org.servicemix.source." The
    message is published on the "demo.org.servicemix.s
    ource" topic.
  • jencks (the JCA resource adapter) listens on port
    61616 for messages.
  • inputReceiver subscribes to the
    "demo.org.servicemix.source" topic via jencks and
    receives the JMS message.
  • inputReceiver normalizes the JMS message and
    sends it to outputSender via the NMR.
  • outputSender marshals the normalized message to a
    JMS message and uses jmsTemplate to publish the
    message on the "demo.org.servicemix.result"
    topic.
  • jmsTemplate publishes it on the
    "demo.org.servicemix.result" topic using
    jmsFactory to get a connection to the result
    topic.
  • jencks listens on port 61616 for messages.
  • jmsTrace subscribes to the "demo.org.servicemix.re
    sult" topic and receives the JMS message via
    jencks.
  • jmsTrace converts the JMS message into a
    normalized message and sends it to trace via the
    NMR.
  • trace transforms the normalized message into a
    string and logs it to the console.

56
Basic Example Message Flow Diagram
  1. Using the distributoraposs 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
  2. 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).
  3. 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.
  4. 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.
  5. Each OrderTransformer sends the modified message
    to the OrderProcessor.
  6. The OrderProcessor is a binding component that
    has two functionsa. It places an order to the
    appropriate wholesaler through the
    wholesaleraposs Webservice or proprietary
    interface. b. It also publishes a message about
    the order on a topic.
  7. The message on the topic is subsequently picked
    up by the BusinessMonitor component via the
    jmsTrace component.
  8. The BusinessMonitor component monitors the orders
    for quality assurance and business analytics,
    such as data mining.

57
Basic Example Message Flow Diagram
58
BPEL Logical Flow Diagram
59
File Binding Logical Flow Diagram
60
HTTP Binding Example Message Flow Diagram
61
JMS Binding Example Message Flow Diagram
62
Quartz Example Message Flow Diagram
63
RSS Binding Example Message Flow Diagram
64
Department Store Distributor Order Processing
System
65
(No Transcript)
66
Online Ticket Reservation System
67
Online Application for Tax ID No. System
68
Department of Public Works Project Monitoring
System
69
Network Status Indicator
70
News Feed Monitoring System
71
(No Transcript)
72
Mule
  • Implementing ESB

73
Reliable One-way MEP with Fault Message Sequence
Chart
74
Reliable Two-way Exchange Message Sequence Chart
75
One-way Transactional Message Exchange
76
A simple integration problem using JBI
  • Example Adapter Pattern

77
JBI Components for Adapter Application
78
  • SU
  • SE-Tx Transformation Service
  • BC-Y Provider Service Proxy
  • SE-Seq Adapter Logic
  • BC-X Client Service Proxy

79
Graphic View of Adapter Service Assembly
  • SA

80
Adapter Pattern Message Sequence Diagram
81
JBI Component Installation Time
82
(No Transcript)
83
JBI Component Execution Time
84
Component Interaction -- Service Consumer
  • Find a service endpoint
  • Create a message exchange
  • Send the message

85
Component Interaction -- Service Provider
  • Activate an endpoint
  • Receive a message
  • Send the response
  • Close the exchange

86
(No Transcript)
87
SOA Architecture Principles
  • Well-defined service interfaces
  • Loose coupling
  • Document-based, mostly asynchronous,
    conversational interactions
  • Service registration and discovery

88
To Form Ideal SOA Infrastructure
  • Combine the best of previous technologies

89
JBI Architecture
90
Bring it Together
91
Assembling Services into Processes
92
Events-Driven Application Models
  • Asynchronous One-way Communication
  • Simple Events
  • Brokered Events
  • Enterprise Service Busses
  • Event Stream Processing Engines

93
Simple Events
  • Simple Events
  • Simulating Request/Reply

94
Brokered Event
  • Brokered Event
  • Point to point (Send to One Interested Party )

95
  • Enterprise Service Bus - Orchestration Service
  • Event Stream Processing (ESP)

96
SOA and Events
Event Sink
Event Source
Service Consumer
Service Provider
Notification
Event Sink
Event Source
Service Consumer
One-way
97
ESB enables SOA and EDA
  • SOA Service Oriented Architecture
  • Distributed, Web Services
  • WSDL, SOAP, XML, XSD
  • Registry Lookup, UDDI
  • Request / Reply
  • EDA Event Driven Enterprise
  • Message Oriented
  • Qualities of Service
  • Asynchronous Publish / Subscribe

98
JBI Messaging
  • JBI defines a model and the APIs for messaging
    between JBI components
  • All types of interaction
  • One-Way
  • Reliable One-Way
  • Request Response
  • Request Optional-Response
  • Messaging API
  • Components send messages to the JBI container
  • Components read messages from the JBI container
  • JBI vs JMS

99
JBI Addressing
  • An interface is a group of operations
  • A service implements an interface represented by
    qualified name and its WSDL definition
  • A service has one or more endpoints accessible by
    different bindings
  • Endpoints can be
  • external for services accessible via a binding
    component
  • internal for services provided by a service engine

100
JBI Component Packaging (installation)
  • Write an XML descriptor for the component
  • the deployment descriptor
  • Package the descriptor with component logic in a
    JAR archive
  • Install the component in JBI environment
  • Component deployment descriptor

101
Deployment
  • Provide services to JBI environment through the
    JBI component
  • Service (component artifact) is described by XML
    descriptor and packaged as Service Unit (SU)
  • Services that have to be deployed into different
    components to produce a new application can be
    grouped into a Service Assembly (SA).
  • The SA contains an XML descriptor to describe how
    each SU is deployed on its target component
  • Service assembly deployment descriptor

102
Components and Artifacts Lifecycle
  • Components and artifacts are managed with the
    same unified lifecycle
  • Lifecycle management is accessible by admin tools
    via standard JMX MBean defined by the
    specification

103
Applying JBI With ESB
  • Open ESB
  • Sun's Open Source Enterprise Service Bus
  • A standard, distributed integration
    infrastructure
  • Highly distributed scalable JBI services
  • Uses JBI Reference Implementation code
  • Based on MOMasync XML message exchanges
  • Centralized management
  • Standard deployment of composite services
  • QOS characteristics
  • Open ESB Architecture

104
Integration Solution Proxy Service
105
Integration Solution Proxy Service
  • Composite App Service Assembly
  • A collection of service unit
  • Proxy service deployment

106
Composite Application Using JBI
107
(No Transcript)
108
BPEL
109
JBI
  • Service based
  • Plug-in components serve roles
  • Service provider, consumer, both
  • Providers supply self-description
  • Messages
  • Operations and message exchange patterns
  • Services
  • Endpoints
  • All using WSDL
  • Service Engines
  • Provide local services
  • Business Processes (orchestration BPEL4WS)
  • Transformation (XSLT, EDI)
  • Business Logic (EJBs)
  • Integrated Java technology-based apps
  • Consume services
  • Binding Components
  • Proxy for remote service providers
  • Protocol SOAP, AS2, ebXML MSH, XML-over-HTTP,
    EDI, etc.
  • Access for remote service consumers
  • Protocol access to
  • SE-provided services
  • BC-proxied services
  • Contain no business logic
  • Convention break at your peril
  • No Restrictions

110
Normalized Message Router
  • Key to interoperation between components
  • Mediated Message Exchange
  • Normalized Message
  • Abstract Message (payload) Message Properties
    (metadata)
  • WSDL Abstract Message
  • WSDL interface operation message definition
  • Properties (metadata)
  • Protocol-supplied context information
  • Security tokens
  • Transaction information
  • Data other components may recognize
  • Message Exchange Pattern
  • Support for simple communications primitives
  • Message exchange patterns are defined from the
    providers perspective

111
Inside Message Exchange Handling
112
JBI
  • JBI is a messaging-based plug-in architecture
  • JBI does not define the pluggable component
    themselves, but
  • Defines the framework, container interface,
    behavior, and common services
  • JBI allows anyone to create JBI compliant
    integration plug-in component and integrate them
    dynamically into the JBI infrastructure
  • Key pieces of the JBI environment
  • SE
  • BC
  • NMR
  • JBI runtime environment (JBI meta container)

113
JBI
  • 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.
  • 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.
  • The JBI environment also supplies a set of
    services for self management, including services
    for component installation and life cycle
    management of components.
  • In summary, the JBI specification creates a
    standards-based technology for enterprise
    application integration.

114
JBI
  • 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.
  • 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
    "event" on topics or queues which are external to
    the bus, while other components can listen for
    messages on the normalized message bus.
  • 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.
  • 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.
  • 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.
  • All components on the ESB communicate with one
    another by passing messages.

115
  • 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.
  • 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.

116
  • Services that need to be accessed by the ESB are
    accessed as endpoints.
  • Endpoint is how a service is addressed by the
    ESB.
  • Service is the actual business entity the
    performs the desired function
  • Service units provide information about the
    services and their endpoints to the component
  • Service assembly is how several service units are
    packaged and deployed on to target components
  • 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.

117
  • 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.
  • 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.
  • 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.
  • 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
  • JBI Message API
  • JBI Service API
  • JBI Message Exchange Factory API
  • Service Description SPI
  • Message Exchange Patterns API
  • Endpoint Reference API

118
  • JBI supports two kinds of components, service
    engines and binding components. Components
    interact with JBI in two ways
  • SPIs Interfaces implemented by a binding or
    engine
  • APIs Interfaces exposed to bindings or engines
    by the framework
  • 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.
Write a Comment
User Comments (0)
About PowerShow.com