WebSphere Message Broker Application Development Training

Prepared by: V Vijaya Raghava
WebSphere Message Broker
Concepts, Technical Walkthrough, Application Development

Prepared by: Vijaya Raghava
Mobile: +91.900.076.7644
Email ID: vvijayaraghava@hotmail.com
Prepared and Updated on: July 19, 2013
Version 1.51

3
Agenda
 Pre-requisites for the Training
 Introduction
 Application Integration
 The Complexity of Application Integration
 Challenges and Issues Businesses are facing today
 Point-to-Point Communication
 Enterprise Application Integration
 Why EAI
 Defining EAI
 The Connectivity Challenge
 Types of EAI
 EAI Approach to Integration
 Enterprise Application Integration – Benefits

4
Agenda contd…
 Service Oriented Architecture
 What is a service
 SOA Definition
 How do you know when you’ve got SOA?
 SOA vs Traditional EAI
 Benefits of SOA
 Principles & Benefits of SOA
 Enterprise Service Bus
 Definition
 SOA with an ESB
 ESB – Flexibility
 An ESB gives SOA its full value
 Integrating business applications through an ESB

5
Agenda contd…
 Enterprise Service Bus
 Different kinds of ESB
 Examples of ESB
 Various Middleware Products

6
Agenda contd…
 Introduction to WebSphere Message Broker
 Overview
 Quick Tour
 WebSphere Message Broker
 Platform Support
 Database Support
 Protocol, Transports, Data Formats and Processing
Support
 WebSphere Message Broker Business Scenario
 Technical Overview – Architecture
 Capabilities
 Enterprise Messaging
 Message Brokering

7
Agenda contd…
 Publish & Subscribe
 Publish & Subscribe – Implementation
 WebSphere MQ Interoperability
 WMB Components
 Development Environment
 Runtime Environment
 WMB Components – Interaction

8
 WebSphere MQ Explorer
 Message Flow – Revisited
 Message Broker Parsers
 Message Tree
 Logical Tree Structure
 Message tree structure
 Environment tree structure
 Local environment tree structure
 Exception list tree structure
 Message Flow Editor
 WebSphere Message Broker Software – Components
Agenda contd…

9
 WebSphere Message Broker – Built-in Nodes
 WebSphere Information Centre
Agenda contd…

10
Agenda contd…
 Technical Introduction to WebSphere MQ
 Today’s Enterprise IT Environment
 Why Interfaces are so expensive to build and maintain ?
 Service Oriented Architecture – Revisited
 Program-to-Program Communication
 Synchronous Communication Model
 Asynchronous Communication Model
 Program-to-Program Communication Factors
 Time Independence
 Three Styles of Communication
 WebSphere MQ Eliminates application network concerns

11
Agenda contd…
 Local and Remote Queue Concept
 Message Queue Interface
 Message Queue Interface – Calls
 Message Composition
 Message Types
 Message Persistence
 Queue & Queue Manager
 Message Queues Types
 Queues Expiry
 Message Broker User Roles
 How MQ Series Works

12
Agenda contd…
 Deployment Process using MQ Explorer
 Message Broker Queue Explorer
 Transformation interfaces

13
Agenda contd…
 Prerequisites
 Introduction to ESQL
 ESQL Overview
 Datatypes
 Operators
 Variables
 Statements
 Functions & Procedures
 Field References
 Modules
 Reserved Words
 Non Reserved Words
 Special Characters
 Managing ESQL files
 Writing ESQL files
 Programming Examples

14
Agenda contd…
 Developing Applications using ESQL
 LAB 1 - Simple Hello World Application
 Developing Applications using ESQL
 LAB 2 - Bookstore Application

15
Agenda contd…
 Developing Applications using Java – Concepts
 Developing Applications using Java – Labs
 LAB 4 - Connecting with Database (Bookstore Application)

16
Agenda contd…
 Developing Applications using Mappings – Concepts
 Message Sets and Message Definitions
 The Message Set Editor
 The Message Definition Editor
 The Message Mapping Editor
 LAB 6 - Simple Mapping Concept

17
Agenda contd…
 WebSphere Message Broker Installation, Startup
Configurations
 Message Broker Installation
 Startup Configurations – Windows 7
 Startup Configurations – Windows XP
 Testing Message Flow Applications
 Creating / Deleting Default Configurations
 Testing Message Flow Applications using Test Client
 Testing Message Flow Applications with SoapUI
 Debugging Message Flow Applications

18
Agenda contd…
 WebSphere Message Broker Examples
 Application Samples
 LAB 7–10
 Technology Samples
 LAB 11–15
 Troubleshooting & Problem Determination
 Documentation

19
Prerequisites for the training
 Attendees are expected to have an understanding of the following:
 Debugging in Rational Application Developer.
 XML Concepts including the following:
– XML Syntax
– XML Naming Conventions
– Prolog
– Processing Instructions
– Comments
– Document Type Definition
– Elements
– Attributes
– Entities
– XML Namespaces
– Validation of XML Documents
– XML Schema
 Web Services Concepts (including SOAP, WSDL)

21
Agenda
– What is an Application?
– Introduction to Application Integration
– Challenges and Issues Businesses facing today
– Point-to-Point Communication
– The Complexity of Application Integration
– Point-to-Point Communication – Consequences
– Enterprise Application Integration
– Why EAI
– Defining EAI
– The Connectivity Challenge
– Types of EAI
– EAI Approach to Integration
– EAI Benefits

22
What is an Application ?
User Interaction
Logic
Data
Logic
Integration
Logic
Process
Logic
Business
Rules
This image cannot currently be displayed.
This image cannot currently be displayed.
Monitoring &
Management
Logic

23
Introduction to Application Integration
 Present Situation
– Your organization probably uses many applications and services
that were built over many months or years.
– Now new business needs were identified.
– As a result, these applications probably are of different ages,
were written by different people using different languages and
technologies, reside on different hardware platforms, use
different operating systems, and provide very different
functionality.
 Impact
– Many of your applications often have very little in common at all
– Resulting in isolated functionality and multiple instances of the
same data
– Redundant activities, higher costs, and inefficient response to
your customers.

24
– Enterprise systems consist of many logical endpoints
– Off-the-shelf apps, services, packaged applications (SAP, Siebel etc)
– Web applications, devices, appliances, custom built software and many
more!
– Endpoints expose a set of inputs and outputs, which comprise:
– Protocols such as MQ, TCP/IP, database, HTTP, files, FTP, SMTP, POP3
– Formats like (C/COBOL), XML, industry (SWIFT, EDI, HL7), user-defined
– Point-to-point connections quickly deteriorate into spaghetti
– Inflexible architecture which is expensive to maintain and resistant to
change
– Message Broker connects these endpoints together in
meaningful ways
– Message Broker simplifies application and device integration!
– Avoids rewrites in response to new integration requirements
– Simplifies maintenance by reducing expensive coupling
– Flexibility adding anonymity between producers and consumers of data
– Adds insight into applications and business value they bring

25
– Application integration (sometimes called Enterprise Application
Integration or EAI) is the process of bringing data or a function
from one application program together with that of another
application program.
– Application integration is the secure and orchestrated sharing of
processes and/or data between applications within the
enterprise.
– Application Integration is a big challenge for enterprises

26
Challenges and Issues
Businesses facing today
– How are Composite (Integrating) Applications different?
The “Good Old Days”
• 1 mainframe computer
• 1 user device
• 1 network connection
• 1 population of users
• 1 set of user requirements
• 1 user location
• 1 program
• 1 program “owner”
Composite Applications
• Many computers
• Many user devices
• Many types of network connections
• Many diverse populations of users
• Many different user requirements
• Many user locations
• Many programs
• Many program “owners”

27
 Lack of business process
standards
• Architectural policy limited
 Point application buys to
support redundant LOB
needs
 Inflexible infrastructure built
over time, no roadmap

28
Inflexible IT systems: Symptoms and solutions
Symptom Solution
Multiple applications Multiple
platforms
Componentize application and IT
functions
Varying degrees of
interoperability
No seamless integration
Implement a standard method for
applications to interact with each
other
Changes to one system =
changes to other systems
Decouple system interfaces
No common data format
or process model
Implement common method for
viewing/using data and
processes

29
How to move forward

30
Point-to-Point Integration
– In a point-to-point integration model, a unique connector
component is implemented for each pair of applications or
systems that must communicate.
– This connector handles all data transformation, integration, and
any other messaging related services that must take place
between only the specific pair of components it is designed to
integrate.
– Best suited for small infrastructures, where only two or three
systems must be integrated

31
The Complexity of Application Integration
A B
CD
E

32
Point-to-Point Integration – Consequences
– Point-to-point connections quickly deteriorate into spaghetti
– Inflexible architecture which is expensive to maintain and resistant to
change

33
Enterprise Application Integration
– Application integration refers to solutions that are implemented to
integrate software applications within and between organizations
– Represents the task of integration of various applications so that
they may share information and processes freely.
– Is the creation of robust and elegant business solutions by
combining applications using common middleware and other viable
technologies.
– Application Integration is concerned with:
• integration of legacy software applications,
– these applications vary across departments,
– Written by different people at different times
– exist on different platforms,
– Coded in different programming languages
– use different data formats and provide different functionality
– Different user interfaces exist for each application.
– Integrating the applications is a more practical and cost effective
solution than the alternative of re-writing the existing applications.

34
Why EAI ?
– System development over the last 20 years has tended to
emphasize core functionality as opposed to integration
– Many systems are highly stovepiped
– There are a number of organizations fitted with different types of
open and proprietary systems. each with its own development,
database, networking and operating system. Thus resulted a
heterogeneous environment.
– Ultimately, it comes down to a cost issue. Building a system with
integration in mind reduces the amount of money spent on
further system development
– Necessity of interconnection of disparate systems in order to
meet the needs of the business

35
Why EAI ? Contd…
– Evolution of Stovepipes
– Systems tend to support single organizations with little initial
incentive to integrate with other departments
– Failure of mainframes to solve problems, provide features to
users, etc. tend to act as an incentive to stovepipes
– Organizations tend to protective of their systems and are
unwilling to compromise

36
Why EAI ? Contd…
– Integration of Stovepipe Applications Is Very Difficult
Product
Management
DB2
Inventory
Management
Configuration
Management
Service
Order
Management
Trouble
Management
Billing
Management
Performance
Management
Oracle Oracle DB2 Oracle DB2 Oracle
• Data Redundancy
• Synchronization Problems
• Application Authorization Issues
• Vendor and Application Lock-in
• Isolated data silos
• Administrative Nightmare
• Integration/customization
Nightmare
• Transition from legacy systems to
a more flexible new operational
infrastructure
Architectural Issues Integration Issues

37
Defining EAI
– EAI is defined as “the unrestricted sharing of data and business
processes among any connected applications and data sources
in the enterprise.”
– Using EAI effectively will allow us to integrate without have to
make major changes to our current infrastructure.

38
Defining EAI contd…
User Interface
level
Data
level
App Interface
level
Method
level
Legacy
Data
Packaged
Application
Business
Process

39
– Traditional Systems
– Generally referred to as ‘legacy’ systems
– May consist of anything from PC’s to minicomputers, even large
mainframes
– While the architecture of these systems may be obsolete, they still
contain functionality that must be maintained by the organization in
order to do it’s job.
– Microcomputer Systems
– Personal computers
– A wide range of hardware, operating system and applications
make it difficult to integrate these systems with each other or
legacy systems

40
– Distributed Systems
– Some number of systems tied together by a network that
supports applications run across the network
– May comprise the range of computer sizes
– A wide range of system types exist: client/server, Internet,
intranet, etc.
– Packaged Systems
– Off-the-shelf software
– Software that is purchased rather than designed
– Most are natural stovepipes, since they haven’t been designed
with integration in mind and are closed systems

41
– How did the things get this Bad ?
– Most organizations lacked architectural foresight.
– As they upgraded from legacy systems, they moved to newer
‘open’ systems without consideration to how well these new
systems would fit into their current structure and integrate with
existing legacy systems.

42
– Enterprise Chaos

43
– Application Complexity increases as technology is added
WebSphere MQ
soap/http
soap/jms
http
File
MQ/JMS

44
The Connectivity Challenge
Why?
More Flexibility
More Speed
More Efficiency
Better Services
Better Information
Increased Revenue
Reduced Cost
Lower Risk
Customers want
to improve this….
… to run their
business like this.

45
– Using EAI Technology to bring order to the enterprise

46
Types of EAI
– An enterprise system is made up of business processes and
data.
– So when an IT expert contemplates to use EAI technology, he
has to first understand how these business processes are
automated and the importance of all business processes.
– This understanding will bring out a lot of useful hints:
• For determining the amount of work needed
• How much time it will take
• Which business processes and data are to be integrated etc.

47
Types of EAI Contd…
– At What Level EAI is needed in an application?
• Data Level
• Application Interface level
• Method Level
• User Interface level

48
– Data Level
• Is the process and the techniques and technology of
transferring data between data stores.
• This can be described as extracting information from one
database, if need, processing that information, and updating
the same in another database
– Advantages
• Cost Effective
– No Code Changes
– No Deployments

49
– Application Interface Level
• leveraging of interfaces exposed by custom or packaged
applications.
• Developers make use of these interfaces to access both
business processes and simple information.
• Using these interfaces, developers are able to bring many
applications together, allowing them to share business logic
and information.
– Advantages & Usage
• Most preferred EAI technology for this type is Message
Brokers (Eg: IBM WebSphere Message Broker )
– as these can extract the information from one application, put
it in a format understandable by the target application and
transmit the information.

50
– Method Level
• Allows the enterprise to be integrated through the sharing of
common business logic or methods.
• This can be accomplished by:
– Defining methods that can be shared and therefore integrated
by a number of applications
– Providing infrastructure for such method sharing.
• The mechanisms to share methods among applications are
many including distributed objects, application servers
• Methods can be shared by
– Hosting them on a central server
– Accessing them between applications (distributed objects)

51
– User Interface Level
• Developers are able to bundle applications by using their user
interface as a common point of integration.
• For example mainframe applications that do not provide
database level access may be accessed through the user
interface application

52
EAI Approach to Integration
– Creation of business solutions by combining applications using
common middleware.
– Middleware is application-independent product that provides
services that mediate between applications.
– Rather than each application requiring a separate connector to
connect to every other connector, components in an EAI-based
infrastructure use standardized methods to connect to a common
system that is responsible for providing integration, message
brokering, and reliability functionalities to the entire network.
– EAI loosens the tightly coupled connections of point to point
integration
– An application can send a message without any knowledge of
the consumer's location, data requirements, or use for the
message
– Linking Applications, Services, Databases and Legacy
Systems

53
Enterprise Application Integration – Benefits
– Effective application integration can provide your organization
with the following important business benefits:
– Allowing applications to be introduced into the organization more
efficiently and at a lower cost
– Allowing you to modify business processes as required by the
organization
– Providing more delivery channels for your organization
– Allowing you to add automated steps into business processes that
previously required manual intervention

Service Oriented Architecture – Introduction

56
Agenda
– Current Environment
– Service Oriented Architecture – Introduction
– Bridging the Gap between Business and IT: How?
– SOA Introduction
– What is SOA?
– SOA vs Traditional EAI
– Before and After SOA
– Why SOA?
– SOA Simplifies Connectivity Interfaces
– Value of SOA
– SOA is an evolutionary step
– Expanding SOA Footprint
– Principles of SOA
– Benefits of SOA
– Applying SOA Challenges

58
Service Oriented Architecture
– What is a Service ?
– A service is an application function packaged as a reusable
component that can be used in a business process.
– Exposes a well defined interface
– Appears as a self-contained function
– Uses messages to hide implementation details
– Has no dependencies on the state of other services
– Reusable services
– Service Oriented Architecture (SOA) is an architectural style to reuse and
integrate existing systems for designing new applications.
– The goal of SOA Integration is to expose an organization's computing
assets as reusable services that can communicate and integrate more
readily. This can eliminate the "integration spaghetti" that exists in most
companies today.

59
Bridging the Gap between Business and IT: How?
How do I
optimize my
business
processes?
Business Models
Identify Process Activities
I/T Components exposed
as SOA Services
How do I
integrate to
my existing
systems?
Business and
I/T can use a
common
language
a.k.a.
“Process
Integration”
Business
Process
Activities
=
I/T Services
Granularity

60
SOA – Definition
 An approach for building distributed systems that
allows tight correlation between the business
model and the IT implementation.
 Characteristics:
– Represents business function as a service
– Shifts focus to application assembly rather than
implementation details
– Allows individual software assets to become
building blocks that can be reused in developing
composite applications representing business
processes
– Leverages open standards to represent software
assets

61
What is Service Oriented Architecture (SOA) ?
… a service?
A repeatable business
task – e.g., check
customer credit; open
new account
… service orientation?
A way of integrating your
business as linked
services
and the outcomes that
they bring
… service oriented
architecture (SOA)?
An IT architectural style
that supports
service orientation
… a composite application?
A set of related &
integrated services that
support a business
process built on an SOA

62
SOA – Definition
– An architectural style for building distributed systems that deliver
application functionality as services to either user applications or
other services
– A Software Architecture which
– … defines the use of services to support the requirements of software
users. Resources are available to other participants as independent
services accessed in a standardized way.
– … comprises loosely coupled, high interoperable application services.
These services interoperate based on a formal definition independent of
the underlying platform and programming language. The interface
definition hides the vendor and language-specific implementation.
– … is independent of development technology (e.g. Java, .NET, COBOL,
C, ASM). The software components become very reusable because the
interface is defined in a standards-compliant manner.

63
Applications can be composed of or exposed as Services

64
Applications can implement business process
workflows… by using services
Review
application
Review
application
Customer
eligibility
Retrieve
credit
report
Retrieve
credit
report
Credit
assessment
Credit
assessment
Request
additional
info
Request
additional
info
Generate declineGenerate decline
Final
application
review
Final
application
review
Generate approval
& account info
Generate approval
& account info
Determine
Customer Eligibility
Retrieve Credit
Report
Request
additional info
Generate
decline
Etc….
Business Process is implemented by integrating services

65
SOA vs Traditional EAI
– Prior to the advent of SOA, the true contender for Enterprise
Integration was EAI. A plethora of tools and technologies
emerged in this space quickly to fill the void. However, due to a
lack of standards in the initial stages several issues arose,
including:
– Proprietary vendor toolsets leading to lengthy learning curves
– Complex and lengthy implementation cycles
– Department- or Business Unit-Specific containering for EAI
implementations
– Limited application shelf life
– Technology-driven implementations without the requisite business
goal analysis.

66
SOA vs Traditional EAI contd…
Traditional EAI SOA
Technology Driven Business Driven
Project Based, confined to Department or
Business Group
Enterprise Driven, Company-wide Effort
Generally a Bottom Up approach, driven by
product and technology
Starts with Top Down approach, followed by
bottom up and then settles with Hybrid
Partially supported by Standards Almost wholly standards based at all levels
with XSD, WSDL, JAXWS, BPEL etc.
Extension of client server and Point to Point
(Adapter) integration paradigms
New Paradigm that requires a new train of
thought
Can work successfully with traditional
software development methodologies
such as SDLC, SCRUM, Agile.
Needs new types of control mechanisms
such as Governance and Competency
Centers in addition to traditional
Methodologies
Integration pattern generally resembles Hub
and Spoke
Several patterns of integration possible, of
which Hub and Spoke can be a component
Does not lend itself to enterprise-wide
integration
Complements your existing investment in
middleware by adding an Enterprise
Integration Layer on top

67
Application Centric
Application
Application
Finance
DistributionManufacturing
Supply
Narrow Consumers
Limited Business Processes
Overlapped resources
Overlapped providers
Business scope
Application
Integration
Architecture
Business functionality is
duplicated in each application
that requires it.
EAI ‘leverage’ application silos with the
drawback of data and function
redundancy.
bound to
EAI vendor
Redundancy

68
Service Centric
Service Architecture
Service
Service
Service
Service
Finance
DistributionManufacturing
Supply
Service virtualizes how that capability is
performed, and where and by whom the
resources are provided, enabling multiple
providers and consumers to participate
together in shared business activities.
Multiple Service Consumers
Multiple Business Processes
Multiple Discrete Resources
Multiple Service Providers
Business scope
SOA structures the business and its systems as a set
of capabilities that are offered
as Services, organized into a Service Architecture
Shared
Services

70
Why SOA ?
To enable Flexible, Federated Business Processes
Enabling a virtual federation of
participants to collaborate in an
end-to-end business process
Enabling alternative
implementations
Enabling reuse of
Services
Enabling virtualization of business resources Enabling aggregation from multiple
providers
Identification
Ticket Sales
Ticket Collection
Inventory
Logistics
Manufacturing
Availability
Service
Service
Service
Service
Service
Service
Service
Service Service
Service
Ordering
source:TietoEnator AB,
Kurts Bilder

71
Why SOA ? To enable Business Process Optimization
and the Real Time Enterprise (RTE)
Seamless End to End Process
Systems
SOA Pattern: Standardized Service
provided by multiple suppliers
Service from Multiple Suppliers
SOA Patterns: Single, Multi-Channel
Service for consistency
BPM Expressed in
terms of Services
Provided/Consumed
Enterprise
source:TietoEnator AB,
Kurts Bilder
Smart Clients
Stores POS
Mobile
3rd Party Agents
Portal
Service to Customers

72
Why SOA ? Other reasons…
 To keep pace with global competition:
– “We are taking apart each task and sending it
… to whomever can do it best, … and then
we are reassembling all the pieces”
from Thomas Friedman’s ‘The World is Flat’
 The standards and technology are finally in
place, with broad industry support
 Availability of best practices for
effective governance
 The necessary software to get started
is available today

73
SOA simplifies connectivity interfaces…
…but you still need to know (1) what services you can connect to, (2) where they are, (3) how
to connect to them, (4) how to log into them, (5) how to mediate the differences in data
between them.
SOA turns this… …into this.
Application Application Application Application
ApplicationApplicationApplicationApplication
Service Service Service Service
Service ServiceService Service
Interface Interface Interface
Interface Interface Interface Interface
= interface
 Enables re-use of both
the business
applications and their
interfaces.
 Decouples the
interfaces from the
business
applications.
 Reduces the
number and
technical
complexity of
interfaces.
 Introduces rich business
abstractions to describe
the application interface.

74
SOA Defined – in another way…
SOA is a software architecture model
– in which business functionality are logically grouped and encapsulated
into
• self contained,
• distinct and reusable units called services that represent a high
level business concept
• can be distributed over a network
• can be reused to create new business applications
• contain contract with specification of the purpose, functionality,
interfaces (coarse grained), constraints, usage
... of the business functionality
Services are autonomous, discrete and reusable units of business functionality
exposing its capabilities in a form of contracts.
Services can be independently evolved, moved, scaled even in runtime.

75
Value of SOA
 Service orientation promotes few, coarse grained interactions
between the service providers and consumers
 Reduces the dependencies between the two participating entities
 SOA provides for well-described service interfaces
 Allows the use of services without the need to understand their
implementation details
 SOA facilitates technology and platform independence
 SOA reduces the complexities associated with application integration
along with technology platform independence
 This should result in low cost of maintenance
 SOA manifests the same architectural model for both and external
partner application integration

76
SOA is an evolutionary step
for architecture

77
SOA is an evolutionary step
in distributed communications
Hub and Spoke
managed / centralized
Supports lose coupling of
systems
Message Broker
n lines of connectivity
Centralized management
Limited scalability
Single point of failure
Point-to-Point
unmanaged / decentralized
Suitable for small
environments
n² lines of connectivity
Message Bus
managed / decentralized
Common communication
infrastructure
Common command
infrastructure
n lines of connectivity
Proprietary communication
protocols
Complex management

78
Expanding SOA Footprint
Business Unit 1
Business Unit 3
Business Unit 2

79
SOA Principles (self study)
 Standardized Service Contracts
 Loose Coupling
 Abstraction
 Reusability
 Autonomy
 Statelessness
 Discoverability
 Composability

80
Standardized Service Contracts
 “Services within the same service inventory are in compliance with the same
contract design standards."
 Services use service contract to
– Express their purpose
– Express their capabilities
 Use formal, standardized service contracts
 Focus on the areas of
– Functional expression
– Data representation
– Policy

81
Loose Coupling
 “Service contracts impose low
consumer coupling requirements and
are themselves decoupled from their
surrounding environment."
 Create specific types of relationships
within and outside of service
boundaries with a constant emphasis
on reducing (“loosening”)
dependencies between
– Service contract
– Service implementation
– Service consumers
Source: Thomas Erl

82
Abstraction
 “Service contracts only contain essential information and information about
services is limited to what is published in service contracts”
 Avoid the proliferation of unnecessary service information, meta-data.
 Hide as much of the underlying details of a service as possible.
– Enables and preserves the loosely coupled relationships
– Plays a significant role in the positioning and design of service compositions
Source: Thomas Erl

83
Reusability
 “Services contain and express agnostic logic and can be positioned as
reusable enterprise resources."
 Reusable services have the following characteristics:
– Defined by an agnostic functional context
– Logic is highly generic
– Has a generic and extensible contract
– Can be accessed concurrently
Source: Thomas Erl

84
Autonomy
 "Services exercise a high level of control over their underlying runtime
execution environment."
 Represents the ability of a service to carry out its logic independently of
outside influences
 To achieve this, services must be more isolated
 Primary benefits
– Increased reliability
– Behavioral predictability
Source: Thomas Erl

85
Statelessness
 "Services minimize resource consumption by deferring the management of
state information when necessary."
 Incorporate state management deferral extensions within a service design
 Goals
– Increase service scalability
– Support design of agnostic logic and improve service reuse
Source: Thomas Erl

86
Discoverability
 "Services are supplemented with
communicative meta data by which
they can be effectively discovered
and interpreted."
 Service contracts contain
appropriate meta data for discovery
which also communicates purpose
and capabilities to humans
 Store meta data in a service registry
or profile documents
Source: Thomas Erl

87
Composability
 "Services are effective composition
participants, regardless of the size
and complexity of the composition."
 Ensures services are able to
participate in multiple compositions
to solve multiple larger problems
 Related to Reusability principle
 Service execution should efficient in
that individual processing should be
highly tuned
 Flexible service contracts to allow
different types of data exchange
requirements for similar functions
Source: Thomas Erl

88
Applying SOA – Benefits
– Asset reuse
– Service is component of reuse
– Lower Development Cost
– Eliminate duplicate services
– Faster Time-to-Value
– Compose new applications from existing services
– Extend Business Reach
– Allow new clients to exploit existing services without change
– Providing a new front end
– Business Responsiveness
– Dynamically reconfigure services to meet new business opportunities
– Governance
– Standardize, mandate and measure service usage
– Allows you to introduce control

89
 Service Orientation
 Reuse
 Sharing of Responsibilities
 Increased complexity!
Applying SOA – Challenges
Business functionality has to be made available as
services. Service contracts must be fixed
Implemented services must be designed with reuse in
mind. This creates some overhead.
Potential service users must be involved in the design
process and will have influence on the service design

Enterprise Service Bus – Introduction

92
Agenda
– What is an Enterprise Service Bus?
– SOA with an ESB
– ESB Flexibility
– An ESB Gives SOA its full value
– Integrating business applications through an ESB
– Two core principles of enabling flexibility
– Different kinds of ESB
– ESB Example – Healthcare Integration
– ESB Example – Retail
– ESB Example – Reservation System
– ESB Example – Role of ESB in an enterprise
– ESB Example – Role of ESB across different businesses
– Various Middleware Products in the Market
– Which Middleware Product to choose ???

93
What is an ESB ?
– A software infrastructure for SOA which
– … comprises a set of interaction points to which services are connected.
Services are able to invoke other services which are connected to the
bus.
– ... simplifies an SOA by minimizing the explicit connectivity between
services.
– … allows the creation of dynamic and flexible connectivity between
services during service invocation without changing service
consumers or providers.
– “A Web-services-capable infrastructure that supports intelligently
directed communication and mediated relationships among
loosely coupled and decoupled biz components.”
– Gartner Group

94
SOA with an ESB
– Simplification of Infrastructure
– It DOES simplify the way you think about service connectivity.
– It DOESN’T change the way you think about services.
– Dynamic and Flexible Infrastructure
– New connectivity
– e.g. add customer request audit.
– Flexible connectivity
– e.g. prioritize customer request.
– Service replacement
– e.g. New service upgrade without…

95
ESB – Flexibility
The next stage of Integration
An Enterprise Service Bus (ESB) is a flexible connectivity infrastructure
for integrating applications and services.
 Point-to-Point connection
between applications
 Simple, basic connectivity
Messaging Backbone
 EAI connects applications
via a centralized hub
 Easier to manage larger
number of connections
Enterprise Application
Integration (EAI)
 Integration and choreography of
services through an Enterprise
Service Bus
 Flexible connections with well
defined, standards-based
interfaces
Service Orientated
Integration

96
An ESB gives SOA its full value
An ESB turns this… …into this.
Enterprise Service Bus
Interface Interface Interface
Interface Interface Interface Interface
 Logs and manages
the interaction and
correlates events.
 Communicates
using the right
protocol.
 Customizes
communications so
that the message to
the receiver makes
sense.
 Connects and signs you
into the appropriate
service without
requiring a hardcoded
connection.
The ESB:

97
An ESB gives SOA its full value
Service Enrichment
•Match & Route communications
between services
•Converts between transport protocols
•Transforms between data formats
•Identifies and distributes bus events
… simplifying the overall architecture and reducing IT cost

98
Integrating business applications through an ESB
98
An Enterprise Service Bus (ESB) is a flexible connectivity infrastructure
for integrating applications and services.
An ESB performs the following
between requestor and service
Connects
Everything to everything
Matches & Routes
Communications between services
Converts
Between different transport protocols
Transforms
Between different data formats
Distributes
Business events

99
Integrating business applications through an ESB
Converts between different
transport protocols
Matches & routes communications
between services
Connects everything
to everything
Distributes Business
events
Transforms between
different data formats
An ESB enables flexible SOA connectivity for integrating
business applications, services and processes

100
Two core principles of enabling flexibility
The ESB faciltates the decoupling of interactions between
requestor(s) and provider(s)
Service Virtualization
Routing
Protocol and transports
Transformation of interfaces
The ESB fulfils two core principles in support of separation of concerns:
Aspect Oriented Connectivity
Security
Management
etc …
Log and Audit
Event tracking
Service
Requestor
Service
Requestor
Service
Requestor
Service
Requestor
Service
Provider
Service
Provider

101
Different kinds of ESB
– Basic ESB
– XML as only supported data format
– Web Services protocol emphasis (SOAP/HTTP)
– Adapters for everything
– XML conversion on and off the bus
– Protocol conversion on and off the bus
– Advanced ESB
– All formats supported natively
– XML, COBOL, C, SWIFT, EDI, MIME, Acord, X12
– All protocols supported natively
– Web Services PLUS MQ, JMS, File, SCADA device, user defined…
– Minimizes need for adapters
– Improves performance and manageability
– WebSphere MQ and Message Broker form an Advanced ESB

102
ESB Example – Healthcare Integration

103
ESB Example – Retail
An Enterprise Service Bus lets you add new services gradually.
Internet
Trading partner
communities
Analytics &
Optimization
DMZ DMZ
Internet
Customer communities
Enterprise
APP
APP
Service
Service
DBAPPDB
APP
APP DB
Commerce
Web eCommerce
– Retail is a great example of the broad landscape of integration
– Many different end points both inside and outside the organisation
– Multiple formats and protocols (TLOG, files, JSON/HTTP etc) plus devices
– Flexibility is key as new capabilities need to blend in (mobile, analytics etc)

104
ESB Example – Reservation System
Travel
Reservation
Process
New Cheque
Traveller
Service
Cheque
Credit
Service
Book
Flight
Service
Hotel
Availability
Service
Flight
Availability
Service Travel
Reservation
process
Travel
Reservation
Process
New Flight
Availability
Service
Old Flight
Availability
Service

105
ESB Example – Role of ESB in an enterprise
WebSphere MQ
soap/http
soap/jms
http
File
MQ/JMS

106
ESB Example – Role of ESB across different
businesses

107
Various Middleware Products
TIBCO
Microsoft Biztalk Server
Oracle Fusion Middleware
WebMethods
Progress Openedge
Jboss Enterprise Middleware
IBM WebSphere Message Broker

108
Which Middleware Product to choose ???
– If Integrated Development Environments are key to the
effectiveness of your team
– If your infrastructure platform is structured around
Microsoft .NET technology
– If your infrastructure runs on a Java programming platform

109
If Integrated Development Environments are key to the
effectiveness of your team
– Microsoft’s solution brings together several languages with
developer support for Web, client-server, mobile, reporting,
analytics, and integration.

110
If your infrastructure platform is structured around
Microsoft .NET technology
– Finding the closest fit with a .NET architecture will provide you
with the most seamless integration when operating on a
Microsoft platform.

111
If your infrastructure runs on a Java programming platform
– Ease of integration, compatibility with existing systems, and
scalability are things to keep in mind when selecting your vendor
product solution.

Introduction to IBM WebSphere Message Broker

114
Agenda
– WebSphere Message Broker Overview
– What is WMB
– WMB – Features
– Quick Tour
– Documentation
– WMB – Platform Support
– WMB – Database Support
– Comprehensive protocols, transports, data formats and processing
– WebSphere Message Broker Business Scenario
– Mergers and Acquisitions Scenario
– WMB Architecture
– WebSphere Message Broker Capabilities
– Message Routing
– Interacting with External Systems and Resources
– Message Broker -Transforms messages ‘in flight’
– Message Transformation and Enrichment

115
Agenda contd…
– How do we connect applications?
– Enterprise Messaging
– Message Brokering
– Publish & Subscribe
– Publish & Subscribe Implementation
– Publish Subscribe Implementation – Example 1: Bus and Train
Schedules
– Publish Subscribe Implementation – Example 2: Bus, Train, Plane
Schedules
– Publish Subscribe – Other Examples
– Magazine publishing
– Airline departure notification
– WebSphere MQ Interoperability

116
Agenda contd…
– WMB Components - Overview
– Development Environment
– Message Flows
– Message Sets
– Broker Application Perspective
– Runtime Environment
– Broker
– Execution Groups
– Configuration Manager
– Broker Domain
– User Name Server
– Broker Administration perspective
– WMB – Components revisited
– Interaction of Message Broker Main Components
– WebSphere Message Broker runtime architecture
– Usage Patterns with Message Broker

117
WebSphere Message Broker Overview
– Business integration is the coordination and cooperation of all
your business processes and applications.
– It involves bringing together the data and process intelligence in
your enterprise, and harnessing these so that your applications
and your users can achieve their business goals.
– It provides a mechanism for
• connecting, routing, and transforming business data from a
variety of transports without any need to change the underlying
applications generating the data.
– WebSphere Message Broker, in short WMB from now
onwards, enhances the flow and distribution of information by
enabling the transformation and intelligent routing of messages
without the need to change either the applications that are
generating the messages or the applications that are consuming
them.

118
WMB (contd.)
– In WebSphere Message Broker, connectivity is provided by applications
that communicate by sending and receiving messages.
– WebSphere MQ messaging provides a secure and far-reaching
communications infrastructure that you can expand with WebSphere
Message Broker or WebSphere Event Broker to apply intelligence to
your business data as it travels through your network.
– Key capabilities that make WebSphere Message Broker a valuable
solution for business integration
– Distributes any type of information across and between multiple
diverse systems and applications, providing delivery of the correct
information in the correct format and at the correct time
– Reduces the number of point-to-point interconnections and simplifies
application programming by removing integration logic from the
applications

119
WMB (contd.)
– Routes information in real time based on topic and content to any
endpoint using a powerful publish/subscribe messaging engine
– Validates and transforms messages in-flight between any
combination of different message formats, including Web Services,
and other XML and non-XML formats
– Routes messages based on (evaluated) business rules to match
information content and business processes
– Improves business agility by dynamically reconfiguring information
distribution patterns without reprogramming end-point applications
– Access control to securely deliver personalized information to the
right place at the right time

120
So what is WMB ?
– WebSphere Message Broker is a powerful information broker that
allows both business data and information, in the form of messages, to
flow between disparate applications and across multiple hardware and
software platforms.
– Business rules can be applied to the data that is flowing through the
message broker in order to route, store, retrieve, and transform the
information.
– With WebSphere Message Broker, organizations of any size can
eliminate point-to-point connections and batch processing in order to
increase business flexibility and smart interoperability of systems
regardless of platform, protocol or data format.

121
So what is WMB ?
Built for universal connectivity and transformation in
heterogeneous IT environments
Range of EAI
patterns
Multiple platforms
High volume
processing
Extensive
transformations of data
formats
Standard protocols
Built on WebSphere
MQ

122
So what is WMB ? contd…
– Endless integration to virtually any
platform, operating system or device
– Exploits the industry-leading WebSphere
MQ messaging infrastructure
– Easily handles complex messaging
structures delivering extensive
administration and systems management
facilities
– Continued Innovation:
– Over 100 nodes for connectivity, integration,
and transformation
– Starter to full enterprise versions
– Works with the latest implementations of
standards

123
WebSphere Message Broker (contd.)
– WebSphere Message Broker addresses the needs of business
and application integration by managing the flow of information.
– It provides services, based on message brokers, to allow one to:
– Route a message to several destinations, using rules that act on the
contents of one or more of the fields in the message or message
header.
– Transform a message, so that applications using different formats can
exchange messages in their own formats.
– Store a message, or part of a message, in a database.
– Retrieve a message, or part of a message, from a database.
– Modify the contents of a message; for example, by adding data
extracted from a database.

124
WebSphere Message Broker (contd.)
– The benefits of WebSphere Message Broker can be realized
both within and outside an enterprise:
– Processes and applications can be integrated by providing message
and data transformations in a single place, the broker. This helps
reduce the cost of application upgrades and modifications.
– Systems can be extended to reach suppliers and customers by
meeting their interface requirements within the brokers; can help
improve the quality of interactions, allowing expeditious responses to
changing or additional requirements.

125
WMB – Features
 Universal connectivity from anywhere, to anywhere
– Simplify application connectivity for a flexible and dynamic infrastructure
 Comprehensive protocols, transports, data formats and processing
– Connect to applications, services, systems and devices:
– MQ, JMS, HTTP(S), SOAP, REST, file (including FTP, FTE, ConnectDirect),
database, TCP/IP, MQTT, CICS, IMS, SAP, SEBL, .NET, PeopleSoft,
JDEdwards, SCA, CORBA, email and more!
– Understands the broadest range of data formats:
– Binary (C/COBOL), XML, CSV, DFDL, JSON, industry (SWIFT, EDI, HL7 etc),
IDOCs, user-defined
– Built-in suite of request processors:
– Route, filter, transform, enrich, monitor, publish, decompose, sequence,
correlate, detect…
 Extensive management, performance and scalability
– Extensive administration and systems management facilities for developed solutions
– Wide range of operating system and hardware platforms including virtual and cloud
– High performance transactional processing, additional vertical & horizontal
scalability
– Deployment options include Trial, Express, Standard and Advanced

126
Quick Tour
– IBM WebSphere Message Broker - Version 7
– http://www-01.ibm.com/software/integration/wbimessagebroker/v7-
video.html
– Quick tour: WMB 6.1
– http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etools.mft.
quicktour.doc/doc/quick_tour.htm
– Quick tour: WMB 7.x
quicktour.doc/doc/quick_tour.html
– Quick tour: WMB 8.x
quicktour.doc/doc/quick_tour.html
quicktour.doc/doc/WMB_BusinessNeeds/tour.html

127
Documentation
– Documentation ( WMB and MQ )
– http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/index.jsp
– http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp
– Technical Resources
– http://www-1.ibm.com/software/integration/wbimessagebroker/library/
– http://www.redbooks.ibm.com/abstracts/sg247826.html?Open
– http://www.ibm.com/developerworks/websphere/library/techarticles/0912_lucas/09
12_lucas.html

128
WebSphere Message Broker – Platform Support
– AIX®
– HP-Itanium
– HP-UX on PA-RISC
– Linux on POWER®
– Linux on x86
– Linux on x86-64
– Linux on System z
– Solaris on SPARC
– Solaris on x86-64
– Windows 32-bit
– z/OS4
Always check the WebSphere Message Broker site for the latest updates
http://www-306.ibm.com/software/integration/wbimessagebroker/

129
WMB – Database Support
– DB2
– Informix
– Microsoft SQL Server
– Oracle
– Sybase

130
Comprehensive protocols, transports, data formats
and processing
– Connect to applications, services, systems and devices:
– MQ, JMS, HTTP(S), SOAP, REST, file (including FTP, FTE,
ConnectDirect), database, TCP/IP, MQTT, CICS, IMS, SAP, SEBL,
.NET, PeopleSoft, JDEdwards, SCA, CORBA, email and more!
– Understands the broadest range of data formats:
– Binary (C/COBOL), XML, CSV, DFDL, JSON, industry (SWIFT, EDI, HL7
etc), IDOCs, user-defined
– Built-in suite of request processors:
– Route, filter, transform, enrich, monitor, publish, decompose, sequence,
correlate, detect…
– Universal connectivity from anywhere, to anywhere
– Simplify application connectivity for a flexible and dynamic infrastructure

131
Comprehensive protocols, transports, data formats
and processing – Contd…
WebSphere MQ Multicast
(Reliable Multicast Messaging (RMM))
(Very low latency for LANs)
WebSphere MQ Real-time
(Very low latency over WANs, and the
Internet)
WebSphere MQ Telemetry
(RFID, sensors & actuators)
WebSphere MQ Everyplace
(Mobile device applications)
WebSphere MQ (+ File Transfer Edition)
(Enterprise applications (+ managed file transfer))
Any 3rd-party JMS
(TIBCO EMS, Sonic MQ, BEA JMS, webMethods,
See Beyond, Vitria)
HTTP and HTTP(S)
TCP/IP Sockets
FTP and File
TIBCO Rendezvous
(plug-in component)
SMTP
IBM Protocols Industry and Vendor Protocols
Enterprise Applications
SAP
Oracle Siebel
JDEdwards
Peoplesoft
CICS
Custom

132
WMB Business Scenario (self study)
– WMB manages the flow of information in your business, applying
business rules to route, store, retrieve, and transform the
information as required by the different systems in your business
and the systems of your customers, suppliers, partners, and
service providers.
– Mergers and acquisitions scenario

133
Mergers and Acquisitions Scenario –
The Background
– Company A is a motor and general insurance company that has
been in business for approximately 50 years and currently has
approximately 5 million policyholders.
– The company uses agents and a call center to communicate with
customers. The company has a large legacy IT infrastructure,
which includes CICS® Transaction Server on z/OS® and IBM®
DB2® Universal Database™ on z/OS.
– Company B is small Internet-based motor insurance company,
which currently has less than one million policyholders, and is
expanding.
– The company's IT infrastructure includes WebSphere Application
Server on Windows® 2003, and Oracle Enterprise and IBM DB2
Universal Database on Windows XP.

134
The Problem
– Company A acquired Company B to gain access to the Internet-
based insurance market and to use Company B's Internet-based
skills and IT infrastructure.
– The two companies have customer and policy data of different
formats but, for legal reasons, the data from the separate
companies cannot be merged.
– However, the administration costs of managing the separate IT
infrastructures are high. Also, customers, agents, and call center
staff need a single administration process to interact with the
company's data.

135
The Solution
– As the two companies have merged:
– users can request an insurance quotation
by giving some basic personal information
in a form on the new company's Web site.
– WebSphere Application Server, on which
the Web site runs, forwards the request in
XML format to WebSphere Message Broker
using the request queue in a WebSphere
MQ cluster.
– WebSphere Message Broker transforms
the XML request to the COMMAREA format
that is used by Company A's systems, then
routes the request to Company A's
systems.
– WebSphere Message Broker also routes
the request, in XML format, to Company B's
systems. Both systems return a quotation to
WebSphere Message Broker.

136
WebSphere Message Broker – Architecture

137
WebSphere Message Broker – Architecture

138
WMB – Capabilities
– Applications have much greater flexibility in selecting which
messages they want to receive, because they can specify a topic
filter, or a content-based filter, or both, to control the messages that
are made available to them.
– Diverse applications can exchange information in dissimilar forms,
with Message Brokers handling the processing required for the
information to arrive in the right place in the correct format, according
to the rules that you have defined. The applications do not need to
know anything except their own conventions and requirements.
– The Message Broker provides a framework that supports supplied
basic functions along with user-defined enhancements, to enable
rapid construction and modification of business processing rules that
are applied to messages in the system

139
WMB – Capabilities (contd.)
– The primary capabilities of WebSphere Message Broker are
• Message Routing
• Message Transformation
• Message Enrichment
• Publish/Subscribe
• Database Access
• Web Services Support
• Aggregation
• Augmentation
– Together these capabilities make WebSphere Message Broker a
powerful tool for Business Integration

140
– WebSphere Message Broker processes messages in two ways:
message routing and message transformation.
– Message Routing
– Message Transformation
Receive Message
Filter
Message
Lookup
Mechanism
Set
Destination
Route to
Destination

141
– Message Routing
– Messages can be routed from sender to recipient based on the
content of the message.
– The message flows that you design control message routing.
– A message flow describes the operations to be performed on the
incoming message, and the sequence in which they are carried out.
– Each message flow consists of the following parts:
– A series of steps used to process a message.
– Connections between the nodes, defining routes through the processing.
– The routing can be simple point-to-point routing or it can be based on
matching the content of the message to business rules defined to the
broker.
– WebSphere Message Broker is built upon WebSphere MQ

142
– Message Routing (contd..)
– IBM supplies built-in nodes and samples for many common functions.
– You create message flows in the Message Broker Toolkit which is an
integrated development environment and broker domain administration
console, and is known as the workbench.
142
[Customer, Order,
Quantity, Price, Date]
Fred Smith,
Graphics Card,
32, 1.50,
07/11/06
A B
<order>
<name>Mr. Smith</name>
<item>Graphics Card</item>
<quantity>32</quantity>
<price>1.05</price>
<date>11/07/06</date>
</order>
C

143
Creating an Application Integrator
 Join Applications &
Information sources
 Heterogeneous &
decoupled
 Data validate
 Data routing
 Data transform
(reshape, reformat)
 DBMS Integration
 Transactional
 Stateless
 Simple
 Extensible
 Standards Based
 Transformation (Reshape, Reformat)
 Business Rules
 Intelligent Routing, Publish / Subscribe
 Multiple Protocols in and out.

144
• Examine the content of a message
• Transform the content
Message Broker
Input
Node
Appl.
A
Q1
Original
Message
Appl.
B
Q2
Reformatted
/ Reshaped
Message
Content accessed
from database
Database
Content
+
Output
Nodes
Augment message
Appl.
C
Q3
Augmented
Message
Transformation
Node
Transform message
Transform
Database
Node
Augment
Warehouse
Node
Warehoused
Message
Warehouse
Message Broker -Transforms messages ‘in flight’
– Delivers messages to the right place and in the right format.
– Examine the content of a message
– Transform the content
– Augment the message
– Warehouses the message and assure Transactional delivery.

145
– Messages can be transformed before being delivered
– Messages can be transformed between applications to use different
formats, for example, transforming from a custom format in a legacy
system to XML messages that can be used with a Web service.
– Messages can also be transformed and enriched by integration with
multiple sources of data such as databases, applications, and files
– For the messages that flow through the broker, business information
can be stored in databases or can be extracted from databases and
files and added to the message for processing in the target
applications.
– Complex manipulation of message data can be performed using the
facilities provided in the Message Brokers Toolkit, such as ESQL and
Java.

146
– Message Transformation and Enrichment (contd.)
– Can also be transformed by modifying, combining, adding, or
removing data fields, perhaps involving the use of information stored
in a database.
– Information can be mapped between messages and databases. More
complex manipulation of message data can be achieved by writing
code, for example in Extended SQL (ESQL) or Java, within
configurable nodes.
– Transformations can be made by various nodes in a message flow.
– Before a message flow node can operate on an incoming message, it
must understand the structure of that message.
– Some messages contain a definition of their own structure and
format. These messages are known as self-defining messages, which
you can handle without the need for additional
information about structure and format.

147
– Message Transformation and Enrichment (contd.)
– Other messages do not contain information about their structure and
format. To process them, you must create a definition of their
structure.
– The message definitions that you design are created within a
message set which contains one or more message definitions.
– Message sets also categorize message definitions.

148
– Message Broker has several transformation options including:
– Mapping
– XSLT
– ESQL
– Java
– PHP
– .NET
– Every transformation option has strengths and weaknesses !!!
– Performance and scalability
– Backend integration
– Skill sets and learning curve
– Developer usability
– Portability and maintenance
– Use a transformation technology appropriate to the problem at hand!

149
149
<order>
<name>
<first>John</first>
<last>Smith</last>
</name>
<item>Graphics Card</item>
<quantity>32</quantity>
<price>200</price>
<date>07/11/08</date>
</order>
John,Smith,Graphics Card,
32,200,07/11/08
John Smith............
Graphics Card.........
3220020071108.........
Order
Name Item Qty Price Date
First Last
String String
String Integer Integer Date
Physical Logical
XML
Custom
CSV
Same logical tree
regardless of formats
making it easy to add
new formats

150
Message Set
C Header
XML
Schema
COBOL
Copybook
WSDL
DTD
File Import
Enterprise
Information
System
(SAP, Siebel,
PeopleSoft)
Pre-built
SOAP, MIME, CSV,
IDOC, SWIFT,
EDIFACT, X12, FIX,
HL7,
etc
Define
your own
using the
Eclipse-based
Tooling
Parsers
Message Broker
WebSphere
Transformation
Extender
Type tree

151
– The conversion of one message format into another
 Graphical, easy to
use
 Drag and Drop
fields, apply
functions
 Convert XML to
anything
 Uses standard XSL
Style sheets
 Describe powerful
transformations
quickly
 Uses SQL-based
language (ESQL)
 Uses Java
programming
language
 Ability to use XPath
 Run a WebSphere
Transformation
Extender map

152
– Examples of Message Addressing
152
public class jcn extends MbJavaComputeNode {
public void evaluate(MbMessageAssembly assembly) throws MbException {
...
String lastName =
(String)assembly.getMessage().evaluateXPath(“/Body/Order/Name/Last”);
...
}
}
IF Body.Order.Date < ‘2008/01/01’ THEN
INSERT INTO Database.OldOrders (LastName,Item,Quantity)
VALUES (Body.Order.Name.Last,
Body.Order.Item,
Body.Order.Quantity);
ENDIF;

153
How Do We Connect Applications?
Protocols
Message Formats
Mediation Patterns
Applications need to talk with each
other over a communications protocol.
e.g. MQ, TCP/IP, HTTP, File system,
FTP, SMTP etc.
Applications need to exchange data,
with specific formats
e.g. Binary (C/COBOL), XML, Industry
(SWIFT, EDI, HL7), User-defined
Mediation patterns allow applications to
interoperate. e.g. Route, Transform,
Enrich, Filter, Monitor, Distribute,

154
Enterprise Messaging
– Messaging Transmission

155
Message Brokering
– Message Broker offers various kinds of processing nodes:
– Receive and Route messages.
– Transform a message to an alternative representation
– Select a message for further processing based upon the content.
– Interact with an external database to augment a message or store the
whole part of a message.
– Respond to events and errors.
AppA
App C
QM C
QM A
QM B
comma
separated
COBOL
XML
App B
(MQ)
Input
Filter
(MQ)
Output
(MQ)
Output
Compute
Compute
xml
CWF
QM BRK1
Message Broker
Message
Flow

156
Publish and Subscribe
– The simplest way of routing messages is to use point-to-point
messaging to send messages directly from one application to
another.
– Publish/subscribe provides an alternative style of messaging in
which messages are sent to all applications that have subscribed
to a particular topic.
– The broker handles the distribution of messages between
publishing applications and subscribing applications.

157
Publish and Subscribe (contd.)
– Information Delivery Models
– The publish / subscribe model can be used in different ways.
– The number of publishers might be small, and the number of subscribers
might be large.
– An example of this might be a large sporting event, where a large number of
individuals want to receive information about a small number of events.
– The number of publishers might be large, with a small number of subscribers.
– An example of this might be an internet ordering system, where a large number of
clients place orders, but the subscriber is a single instance of the order application.

158
Publish Subscribe Implementation – Contd..

159
Publish Subscribe Implementation – Contd..

160
Publish Subscribe Implementation – Example 1
Bus and Train Schedules
Publisher 1
Bus Schedules
Publisher 2
Train Schedules
Subscriber 1
Train Schedules
Subscriber 2
Train and Bus
Schedules
Broker
Schedules are
published to the
broker
Published information
is subscribed to and
then received by the
subscribers

161
Publish Subscribe Implementation – Example 2
Bus, Train, Plane Schedules
Publisher 1
Bus Schedules
Publisher 2
Train Schedules
Subscriber 1
Train and Plane
Schedules
Subscriber 2
Bus
Schedules
Broker 1
Publisher 3
Plane
Schedules
Subscriber 3
All Schedules
Broker 2

162
Publish Subscribe – Other Examples
– Magazine publishing
– Airline departure notification

163
WebSphere MQ Interoperability
– Single Administrative explorer
for WebSphere Message
Broker and WebSphere MQ
Operations and security.
– Publish /Subscribe topology
defined with WebSphere MQ
v7 facilities.
– Support and exploitation of
WebSphere MQ Multiple
Instance Queue Managers for
high availability.

164
WebSphere MQ Interoperability contd…

165
WMB – Components Overview

166
WMB – Components Overview (contd.)
Development Environment
– For the creation of message flows, message sets, and other
message flow application resources
Runtime Environment
– Contains the components for running those message flow
applications that are created in the development environment

167
Development Environment
– The development environment is where the message flow
applications that provide the logic to the broker are developed.
– The broker uses the logic in the message flow applications to
process messages from business applications at run time.
– In the Message Brokers Toolkit, you can develop both message
flows and message sets for message flow applications.
– Development Environment comprises of the following
components
• Message Flows
• Message Sets
• Broker Application Perspective

168
Development Environment (contd.)
Message Flows
– The development environment is where the message flow
applications that provide the logic to the broker are developed.
– The broker uses the logic in the message flow applications to
process messages from business applications at run time.
– A choice of methods is available for defining the logic in the
message flows to transform data. (See Message Transformations on pg.: 103)
• Extended Structured Query Language (ESQL)
• Java
• eXtensible Style sheet Language for Transformations (XSLT)
• Drag-and-drop mappings
– The nodes in the message flows define the source and the target
transports of the message, any transformations and
manipulations based on the business data, and any interactions
with other systems such as databases and files.

170
Message Flow (contd.)
– Message flows are transactional
– Provides vital processing and data manipulation
– Completes all or none of its processing successfully.
– Message flows are multithreaded
– Message passing through a series of nodes will execute on a single
thread.
– To allow message flows can be defined with many additional
threads assigned to them to increased message throughput.
– Peak workloads use additional threads, which are pooled during inactivity.
– Message flow nesting and chaining allow construction of enhanced
capabilities.
– Sophisticated flows can be rapidly constructed by linking individual flows
together as well as nesting flows within each other.

171
Sample Message Flow (contd.)
– Pre-defined sequence of operations
– Typically one input message processed per Message Flow instance
– Multiple alternative paths possible.
– Routes to 1—n resources and runs sequence of operations

172
Message Flow Example
– For more information Message Nodes
A message flow contains the set of
operations required to take a message
from an originating application and
deliver copies of it, some possibly
transformed, to any number of
connected applications for processing.
Output targetTransform
Input source Output target
Output target
(Failure)
 Reusable
 Scalable
 Transactional

173
Message Flow Scenario – Example
Routing decision
is made based on
a field described
in the incoming
message
Message is routed to the ‘Generate batch
file’ node, which formats the message for
subsequent output to a file in the ‘Write
file’ node.
Message Flows
Provides the processing sequence
Required to connect
applications together
Nodes
Performs a different
(input, output or processing) action

174
Message Flow Error Behavior - Summary
Transactional?N
Y
MQMD.BackoutCount >
Queue BOTHRESH
N
Y
2.
BackoutQ
3.
DeadLetterQ
local FAIL path
insert
rollback to inputQ
inputQ
Input node's CATCH path
TryCatch node's CATCH path
Local error log
ExceptionList
Root & LocalEnvironmentreset
Get Msg (retry)
1
2
5
6
4
3
1. Input node's
FAIL path
BackoutCount >
2 * BOTHRESHY
N

175
Message Sets
– A message set is a definition of the structure of the messages
that are processed by the message flows in the broker.
– In order for a message flow to be able to manipulate or transform
a message, the broker must know the structure of the message.
– The definition of a message can be used to verify message
structure, and to assist with the construction of message flows
and mappings in the Message Brokers Toolkit.

176
Broker Application Development perspective
– The Broker Application Development perspective is the part of
the Message Brokers Toolkit that is used to design and develop
message flows and message sets. It contains editors that create
message flows, create transformation code such as ESQL, and
define messages.

177
Broker Application Development Perspective
Toolkit Help
Quick Starts Wizard
Appear in the
Project pane, when
workspace is empty.
Perspectives

178
Broker Application Development Perspective (contd.)
Projects
Brokers
Properties
Problems
Deployment Log
Node Palette

179
Runtime Environment
– The runtime environment is the set of components that are
required to deploy and run message flow applications in the
broker.
– Runtime Environment comprises of below components:
• Broker
• Execution Groups
• Configuration Manager
• Broker Domain
• User Name Server
• Broker Administration perspective

180
Runtime Environment (contd.)
Broker
– A broker is a set of execution processes that hosts one or more
message flows to route, transform, and enrich in flight messages.
– When a message arrives at the broker from a business
application, the broker processes the message before passing it
on to one or more other business applications.
– The broker routes, transforms, and manipulates messages
according to the logic that is defined in their message flow
applications.
– A broker uses WebSphere MQ as the transport mechanism both
to communicate with the Configuration Manager, from which it
receives configuration information, and to communicate with any
other brokers to which it is associated.
– Each broker has a database in which it stores the information
that it needs to process messages at run time.

181
– When you create a broker, the following resources are also
defined and created:
• A WebSphere MQ queue manager, if one does not exist.
• A set of fixed-name queues that are defined to the WebSphere
MQ queue manager.

182
Execution Groups
– An execution group is a named grouping of message flows that
have been assigned to a broker.
– The broker enforces a degree of isolation between message
flows in distinct execution groups by ensuring that they run in
separate address spaces, or as unique processes.
– Execution groups enable message flows within the broker to be
grouped together.
– Each broker contains a default execution group.

183
Execution Groups – Contd…
– Additional Execution Groups can be created as long as they are
given UNIQUE names within the Broker.
– Each execution group is a separate operating system process
and, therefore, the contents of an execution group remain
separate from the contents of other execution groups within the
same broker.
– Message flow applications are deployed to a specific execution
group.
– To enhance performance, the same message flows and
message sets can be running in different execution groups.

184
Configuration Manager
– The Configuration Manager is the interface between the
Message Brokers Toolkit and the brokers in the broker domain.
– It Stores configuration details for the broker domain in an
repository, providing a central store for resources in the broker
domain..
– When the Message Brokers Toolkit connects to the Configuration
Manager, the status of the brokers in the domain is derived from
the configuration information stored in the Configuration
Manager’s repository.

185
Configuration Manager (contd.)
– The Configuration Manager has four main functions:
– Records configuration details
– Deploys the broker topology and message processing operations to
the Broker component
– Provides status of the broker domain
– Communicates with other components in the broker domain.

186
Configuration Manager (contd.)
– Each broker domain must have a unique Configuration Manager.
– The Configuration Manager runtime component uses the
following resources (created when the Configuration Manager is
created):
– An repository.
– A WebSphere MQ queue manager
– may use an existing queue manager
– must be on the same physical system as the Configuration Manager
– A set of fixed-name queues, defined to the queue manager that hosts
the Configuration Manager.

187
Broker Domain
– Brokers are grouped together in broker domains.
– The brokers in a single broker domain share a common
configuration that is defined in the Configuration Manager.
– A broker domain contains one or more brokers and a single
Configuration Manager. It can also contain a User Name Server.
– The components in a broker domain can exist on multiple
machines and operating systems, and are connected together
with WebSphere MQ channels.
– A broker belongs to only one broker domain.

188
User Name Server
– A User Name Server is an optional component that is required
only when publish/subscribe message flow applications are
running, and where extra security is required for applications to
be able to publish or subscribe to topics.
– The User Name Server provides authentication for topic-level
security for users and groups that are performing
publish/subscribe operations.
– User Name Server requires
– A WebSphere MQ queue manager.
– A set of fixed-name queues, defined to the WebSphere MQ queue
manager that hosts the User Name Server.

189
Broker Administration Perspective
– The Broker Administration perspective is the part of the Message
Brokers Toolkit that is used for the administration of any broker
domains that are defined to the Message Brokers Toolkit.
– This perspective is also used for the deployment of message
flows and message sets to brokers in the defined broker
domains.
– Contains tools for creating message broker archive (bar) files.
– Bar files are used to deploy message flow application resources
such as message flows and message sets.
– Contains tools to help test message flows.
• These tools include Enqueue and Dequeue for putting and
getting messages from WebSphere MQ queues.

190
WMB – Components revisited
Controller Administrative
Agent
"Root
"
Repor
t
"Body
"
"Root
"
Repor
t
"Body
"
"Root
"
Repor
t
"Body
"
"Root
"
Repor
t
"Body
"
"Root
"
Repo
rt
"Bod
y"
"Root
"
Repo
rt
"Bod
y"
Execution Groups
Message
Flows
Dictionaries
(Msg Sets)
Broker
App.
App. App.
App.
Message
Brokers
Toolkit
Config.
Manager
User Name
Server
Application Development:
Message Flows and
Message Definitions
Broker
Administration
Repository
Broker
Domain

191
Interaction of Message Broker Main Components

192
Interaction of Message Broker Main Components

193
WebSphere Message Broker runtime architecture

194
Usage Patterns with Message Broker
Service Enablement
Service Virtualization
OR
OR
OR
Message Enablement
Message Brokering
File Processing
Event Processing

Introduction to IBM WebSphere MQ Explorer

197
Agenda
– Introduction
– Capabilities
– Broker Properties
– Message Flow Properties
– Message Flow Revisited
– Predefined and self-defining messages
– Why Model Messages?
– Message Model
– Modeling Messages – Advantages
– Message Broker Parsers
– Message Processing Nodes
– Message Tree
– How the Message Tree is populated?

198
Agenda contd…
– Logical Tree Structure
– Message tree structure
– Environment tree structure
– Local environment tree structure
– Exception list tree structure
– Logical Tree Structure Examples
– Message Flow Editor

199
WebSphere MQ Explorer
– The Message Broker Explorer displays information about the
broker environment, information about the defined execution
groups, and information about the deployed applications..

200
WebSphere MQ Explorer – Capabilities
– Create, delete, start, and stop local brokers without using the
command line.
– Show the relationships between the brokers and queue
managers.
– Deploy a broker archive file to multiple execution groups in one
step.
– Visualize a brokers accounting and statistics data.
– Configure broker properties, including creating and modifying
services for broker communication with external services, such
as SMTP, JMS providers, and adapters.
– View the broker administration queue and remove pending tasks
that were submitted to the broker.
– View the Administration Log showing all activity that occurred on
a given broker.

203
Message Flow – Revisited
– A message flow is a sequence of processing steps that run in
the broker when an input message is received.
– You define a message flow in the workbench by including a
number of message flow nodes, each of which represents a set
of actions that define a processing step.
– The connections in the flow determine which processing steps
are carried out, in which order, and under which conditions.
– A message flow must include an input node that provides the
source of the messages that are processed. You must then
deploy the message flow to a broker for execution.
– When you want to exchange messages between multiple
applications, you might find that the applications do not
understand or expect messages in exactly the same format.

204
– You might need to provide some processing between the
sending and receiving applications that ensures that both can
continue to work unchanged, but can exchange messages
successfully.
– You define the processing that is required when you create and
configure a message flow.
– The way that you do this determines what actions are performed
on a message when it is received, and the order in which the
actions are completed.
– You can create a message flow using the built-in nodes, nodes
that you or a vendor have created (user-defined nodes), or other
message flows (known as subflows).
– When you want to invoke a message flow to process messages,
you deploy it to a broker, where it is executed within an
execution group.

205
– Subflows are simply message flows that are invoked from
another flow
– Input and output nodes in the subflow become terminals in the main flow
– Use subflows to break up large problems into smaller more manageable chunks
– Subflows are directly deployable to the Message Broker runtime
– Shared subflows deployed just once per execution group (or application)
– No need to redeploy message flows after changes to shared routines are made
– Redeployment of a subflow is automatically picked up by any consumers

206
Predefined and self-defining messages
– Each message that flows through a broker has a specific
structure that is meaningful to the applications that send or
receive that message.
– Predefined messages
– When you create a message in the WebSphere Message Broker
Toolkit, you define the fields (Elements) in the message, along with
special field types that you might need, and specific values (Value
Constraints) to which the fields might be restricted.
– When you deploy a message set to a broker, the message model is
sent to the broker in a form appropriate to the parser that is used to
parse and write the message.
– Self-defining messages
– You can create and route messages that are self-defining. The best
example of a self-defining message is an XML document.
– You can also model self-defining messages in the WebSphere
Message Broker Toolkit. However, you do not need to deploy these
message sets to the brokers that support those message flows.

207
Predefined and self-defining messages
– You can use:
– Messages that you have modeled in the Broker Application
Development perspective of the WebSphere® Message Broker
Toolkit; these messages are referred to as predefined messages.
– A model-driven parser requires predefined messages.
– Messages that can be parsed without a model; these are called self-
defining messages.

208
Why Model Messages ?
– WebSphere® Message Broker supplies a range of parsers to
parse and write message formats.
– Some message formats are self-defining and can be parsed
without reference to a model.
– However, most message formats are not self-defining, and a
parser must have access to a predefined model that describes
the message, if it is to parse the message correctly.
– An example of a self-defining message format is XML.
– In XML, the message itself contains metadata in addition to data
values, and it is this metadata that enables an XML parser to
understand an XML message even if no model is available.

209
Message Model
Physical message format
("wire format")
Logical message format
Parsed
Constructed
"Root"
MQMD
Format
Report
Version
"Body"
Order
Name
Supplier
Order #
Address
Item
Physical message format
("wire format")
Parsed
Constructed
"Root"
MQMD
Format
Report
Version
"Body"
Order
Name
Supplier
Order #
Address
Item
Parsed
Constructed
"Root"
MQMD
Format
Report
Version
"Body"
Order
Name
Supplier
Order #
Address
Item
MQMD
Order
Supplier
Item
Message
Repository Manager
(MRM)
NEON
self-defining
undefined
predefined

210
Message Model (contd.)
– Models are needed for parsing, validation and transformation
– Domains avoid the need to write custom code to parse messages!

211
Modeling Messages – Advantages
– Examples of messages that do not have a self-defining message
format are CSV text messages, binary messages that originate
from a COBOL program, and SWIFT formatted text messages.
– None of these message formats contain sufficient information to
enable a parser to fully understand the message.
– In these cases, a model is required to describe them.
– Even if your messages are self-defining, and do not require
modeling, message modeling has the following advantages:
– Runtime validation of messages. Without a message model, a parser
cannot check whether input and output messages have the correct
structure and data values.
– Enhanced parsing of XML messages. Although XML is self-defining,
all data values are treated as strings if a message model is not used.
If a message model is used, the parser is provided with the data type
of data values, and can cast the data accordingly.

212
Modeling Messages – Advantages
– Improved productivity when writing ESQL. When you are creating
ESQL programs for WebSphere Message Broker message flows, the
ESQL editor can use message models to provide code completion
assistance.
– Drag-and-drop operations on message maps. When you are creating
message maps for WebSphere Message Broker message flows, the
Message Mapping editor uses the message model to populate its
source and target views. Without message models, you cannot use
the Message Mapping editor.
– Reuse of message models, in whole or in part, by creating additional
messages that are based on existing messages.
– Generation of documentation.
– Provision of version control and access control for message models
by storing them in a central repository.
– To make full use of the facilities that are offered by WebSphere
Message Broker, model your message formats.

213
Message Broker Parsers
– A parser is a program that interprets the physical bit stream of
an incoming message, and creates an logical representation of
the message in a tree structure.
– The parser also regenerates a bit stream for an outgoing
message from the message tree representation.
– A parser is called when the bit stream that represents an input
message is converted to the form that can be handled by the
broker; this invocation of the parser is known as parsing.
– The form, a logical tree structure, is described in Logical tree
structure section.
– The way in which the parser interprets the bit stream is unique to
that parser; therefore, the logical message tree that is created
from the bit stream varies from parser to parser.

214
Message Broker Parsers – Contd…
– The parser that is called depends on the structure of a message,
referred to as the Message Template.
– Message template information comprises:
– Message domain
– Message set
– Message type
– physical format of the message.
– Together, these values identify the structure of the data that the
message contains.
– The broker requires access to a parser for every message
domain to which your input messages and output messages
belong. Parsers are called when required by the message flow.

215
– WebSphere® Message Broker provides built-in support for
messages in the following message domains by providing
message body parsers:
MRM
IDOC
This is an example text. Go ahead and replace it
JMSMap and JMSStream
XMLNSC, XMLNS, XML
DataObject
BLOB
1
2
3
4
5
6
7
SOAP
8 JSON
9 DFDL

216
– Some Body Parsers are model driven, which means that they
use predefined messages from a message set when parsing and
writing.
– The MRM, SOAP, DataObject, IDOC, and (optionally) XMLNSC
parsers are model-driven parsers.
– To use these parsers, messages must be modeled in a message set
and deployed to the broker from the WebSphere Message Broker
Toolkit.
– Other body parsers are programmatic, which means that the
messages that they parse and write are self-defining messages,
and no message set is required.
– When you use a model-driven parser, you must also specify the
Message Set and, optionally, the Message Type and Message
Format so that the parser can locate the deployed message
definition with which to guide the parsing or writing of the
message.

217
…draCscihparG,htimSderF
Input Message Bit-stream
…n/<htimS.rM>eman<>redro<
Output Message Bit-streamOutput Message Bit-stream
Parser converts
bit-stream to
logical structure
Model
Parser converts
logical structure
to bit-stream
Model

218
– On input, the broker
receives a message
bitstream and parses it into
a logical message tree
– On output, the broker
serializes a message tree
into a message bitstream.
– The parser and serializer
understand the structure of
the message because it
has been modeled by the
user in a message set.
<Person age=’32’ height=‘172’>
<Name>Joe Bloggs</Name>
</Person>
struct {
int height;
int age;
char Name[48];
} Person;
172 32 Joe Bloggs

219
Message Processing Nodes
DataInsert
IF Body.Person.height > 183 THEN
INSERT INTO Database.TallPeople
(Name,Height,Age)
VALUES (Body.Person.Name,
Body.Person.height,
Body.Person.age);
ENDIF;
Compute
IF (XML format required) THEN
OutputRoot.Properties.MessageFormat = 'XML';
ELSE IF (custom format)
OutputRoot.Properties.MessageFormat = 'CWF';
ELSE IF (SWIFT format)
OutputRoot.Properties.MessageFormat = 'TDS';
ENDIF;
Java
Compute
public class jcn extends MbJavaComputeNode {
public void evaluate(MbMessageAssembly assembly)
throws MbException
{
…
String personAge =
(String)assembly.getMessage().evaluateXPath(“/Body/Person/Age”);
…
}

220
Message Tree
– A message tree is a structure that is created, either by one or
more parsers when an input message bit stream is received by a
message flow, or by the action of a message flow node.
– A message is used to describe:
– A set of business data that is exchanged by applications
– A set of elements that are arranged in a predefined structure
– A structured sequence of bytes
– WebSphere Message Broker routes and manipulates messages
after converting them into a logical tree. This process of
conversion is called parsing.
– Parsing makes it understandable content and structure of a
message, and simplifies later operations.
– After a message has been parsed, it can be processed in a
message flow.

221
How the Message Tree is populated ?
– The message tree is initially populated by the input node of the
message flow.
– When the input node receives the input message, it creates and
completes the Properties tree (the first subtree of the message
tree).

222
Logical Tree Structure
– The logical tree structure is the (broker) representation of a
message. It is also known as the message assembly.
– When a message arrives at a broker, it is received by an input
node that you have configured in a message flow.
– Before the message can be processed by the message flow, the
message must be interpreted by one or more parsers that create
a logical tree representation from the bit stream of the message
data.
– The tree format contains identical content to the bit stream from
which it is created, but it is easier to manipulate in the message
flow.

223
MessageFormat = Physical format layer ID
Msd = 'MRM ' = 'BLOB'
Fmt = Physical format layer ID
Root
Properties
MQMD
MQRFH2
XMLNSC
MessageSet = MessageSet-ID
MessageType = MessageID
ReplyToQ
Format ='MQHRF2 '
mcd
Set = MessageSet-ID
Type = MessageID
Message
Name
Version
Complaint
Type
MRM BLOB
(Body)
Name
Version
Complaint
Type

224
Logical Tree Structure - Example
Root
Properties
MQMD
MRM
HomeAddress
Line
Zip
Country
WorkAddress
Line
Zip
Country
MessageType AddressesMsg
My_SetMessageSet
01 AddressesMsg.
10 HomeAddress.
20 Line PIC X(20) OCCURS 2 TIMES.
20 Country PIC X(2).
20 Zip PIC X(10).
10 WorkAddress.
20 Line PIC X(20) OCCURS 2 TIMES.
20 Country PIC X(2).
20 Zip PIC X(10).
AddressesMsg
t_AddressesMsg
HomeAddress WorkAddress
t_Address
Line Country Zip
xsd:string
My_AddressesMsg.mxsd
My_Set_Project
messageSet.mset
My_Set

225
– The input node creates this message assembly, which consists
of four trees
– Message tree structure
– Environment tree structure
– Local environment tree structure
– Exception list tree structure
– The first of these trees is populated with the contents of the input
message bit stream, the remaining three trees are initially empty.
– Each of the four trees created has a root element
– Each tree is made up of a number of discrete pieces of
information called elements.
– The root element has no parent and no siblings
– The root is parent to a number of child elements. Each child
must have a parent, can have zero or more siblings, and can
have zero or more children.

226
Message Tree Structure
– The message tree is a part of the logical message tree in which
the broker stores its representation of the message body.
– The message tree includes all the headers that are present in
the message, in addition to the message body.
– The tree also includes the Properties subtree, if that is created
by the parser.
– If a supplied parser has created the message tree, the element
that represents the Properties subtree is followed by zero or
more headers.
– The last element beneath the root of the message tree is always
the message body.

WebSphere Message Broker Application Development Training

WebSphere Message Broker Application Development Training

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (7)

Semelhante a WebSphere Message Broker Application Development Training

Semelhante a WebSphere Message Broker Application Development Training (20)

Último

Último (20)

WebSphere Message Broker Application Development Training