WebSphere Message Broker Application Development Training


Published on

IBM WebSphere Message Broker Application Development Presentation gives introduction to WMB and MQ concepts.

Proficiency Level: Beginner to Intermediate.

This document should not be considered as reference for WMB and MQ concepts. This is only an understanding document.

Please post your comments/reviews/suggestions/complaints here or email me: vvijayaraghava@hotmail.com

I tried to upload the Powerpoint presentation, but the document is not getting uploaded. Hence uploading the presentation in the form of PDF.

Published in: Education
1 Comment
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

WebSphere Message Broker Application Development Training

  1. 1. Prepared by: V Vijaya Raghava WebSphere Message Broker Concepts, Technical Walkthrough, Application Development
  2. 2. 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. 3. 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. 4. 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. 5. 5 Agenda contd…  Enterprise Service Bus  Different kinds of ESB  Examples of ESB  Various Middleware Products
  6. 6. 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. 7. 7 Agenda contd…  Publish & Subscribe  Publish & Subscribe – Implementation  WebSphere MQ Interoperability  WMB Components  Development Environment  Runtime Environment  WMB Components – Interaction
  8. 8. 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. 9. 9  WebSphere Message Broker – Built-in Nodes  WebSphere Information Centre Agenda contd…
  10. 10. 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. 11. 11 Agenda contd…  Technical Introduction to WebSphere MQ  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. 12. 12 Agenda contd…  Technical Introduction to WebSphere MQ  Deployment Process using MQ Explorer  Message Broker Queue Explorer  Transformation interfaces
  13. 13. 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. 14. 14 Agenda contd…  Developing Applications using ESQL  LAB 1 - Simple Hello World Application  Developing Applications using ESQL  LAB 2 - Bookstore Application
  15. 15. 15 Agenda contd…  Developing Applications using Java – Concepts  Developing Applications using Java – Labs  LAB 3 - Simple Hello World Application  LAB 4 - Connecting with Database (Bookstore Application)
  16. 16. 16 Agenda contd…  Developing Applications using Mappings – Concepts  LAB 5 - Simple Hello World Application  Message Sets and Message Definitions  The Message Set Editor  The Message Definition Editor  The Message Mapping Editor  LAB 6 - Simple Mapping Concept
  17. 17. 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. 18. 18 Agenda contd…  WebSphere Message Broker Examples  Application Samples  LAB 7–10  Technology Samples  LAB 11–15  Troubleshooting & Problem Determination  Documentation
  19. 19. 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)
  20. 20. Application Integration
  21. 21. 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. 22. 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. 23. 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. 24. 24 Introduction to Application Integration – 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. 25. 25 Introduction to Application Integration – 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. 26. 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. 27. 27 Challenges and Issues Businesses facing today  Lack of business process standards • Architectural policy limited  Point application buys to support redundant LOB needs  Inflexible infrastructure built over time, no roadmap
  28. 28. 28 Challenges and Issues Businesses facing today 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. 29. 29 Challenges and Issues Businesses facing today How to move forward
  30. 30. 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. 31. 31 The Complexity of Application Integration A B CD E
  32. 32. 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. 33. 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. 34. 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. 35. 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. 36. 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. 37. 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. 38. 38 Defining EAI contd… User Interface level Data level App Interface level Method level Legacy Data Packaged Application Business Process
  39. 39. 39 Defining EAI contd… – 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. 40. 40 Defining EAI contd… – 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. 41. 41 Defining EAI contd… – 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. 42. 42 Defining EAI contd… – Enterprise Chaos
  43. 43. 43 Defining EAI contd… – Application Complexity increases as technology is added WebSphere MQ soap/http soap/jms http File MQ/JMS
  44. 44. 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. 45. 45 Defining EAI contd… – Using EAI Technology to bring order to the enterprise
  46. 46. 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. 47. 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. 48. 48 Types of EAI Contd… – 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. 49. 49 Types of EAI Contd… – 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. 50. 50 Types of EAI Contd… – 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. 51. 51 Types of EAI Contd… – 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. 52. 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. 53. 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
  54. 54. ?
  55. 55. Service Oriented Architecture – Introduction
  56. 56. 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
  57. 57. 57 Current Environment
  58. 58. 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. 59. 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. 60. 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. 61. 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. 62. 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. 63. 63 Applications can be composed of or exposed as Services
  64. 64. 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. 65. 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. 66. 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. 67. 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. 68. 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
  69. 69. 69 Before SOA – After SOA
  70. 70. 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. 71. 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. 72. 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. 73. 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. 74. 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. 75. 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. 76. 76 SOA is an evolutionary step for architecture
  77. 77. 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. 78. 78 Expanding SOA Footprint Business Unit 1 Business Unit 3 Business Unit 2
  79. 79. 79 SOA Principles (self study)  Standardized Service Contracts  Loose Coupling  Abstraction  Reusability  Autonomy  Statelessness  Discoverability  Composability
  80. 80. 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. 81. 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. 82. 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. 83. 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. 84. 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. 85. 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. 86. 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. 87. 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. 88. 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. 89. 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
  90. 90. ?
  91. 91. Enterprise Service Bus – Introduction
  92. 92. 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. 93. 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. 94. 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. 95. 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. 96. 96 An ESB gives SOA its full value An ESB turns this… …into this. Service Service Service Service Service ServiceService Service Enterprise Service Bus Service Service Service Service Service ServiceService Service 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: Enterprise Service Bus
  97. 97. 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. 98. 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. 99. 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. 100. 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. 101. 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. 102. 102 ESB Example – Healthcare Integration
  103. 103. 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. 104. 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 Enterprise Service Bus New Flight Availability Service Old Flight Availability Service
  105. 105. 105 ESB Example – Role of ESB in an enterprise WebSphere MQ soap/http soap/jms http File MQ/JMS Enterprise Service Bus
  106. 106. 106 ESB Example – Role of ESB across different businesses
  107. 107. 107 Various Middleware Products TIBCO Microsoft Biztalk Server Oracle Fusion Middleware WebMethods Progress Openedge Jboss Enterprise Middleware IBM WebSphere Message Broker
  108. 108. 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. 109. 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. 110. 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. 111. 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.
  112. 112. ?
  113. 113. Introduction to IBM WebSphere Message Broker
  114. 114. 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. 115. 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. 116. 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. 117. 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. 118. 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. 119. 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. 120. 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. 121. 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. 122. 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. 123. 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. 124. 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. 125. 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. 126. 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 – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etools.mft. quicktour.doc/doc/quick_tour.html – Quick tour: WMB 8.x – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etools.mft. quicktour.doc/doc/quick_tour.html – http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.etools.mft. quicktour.doc/doc/WMB_BusinessNeeds/tour.html
  127. 127. 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. 128. 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. 129. 129 WMB – Database Support – DB2 – Informix – Microsoft SQL Server – Oracle – Sybase
  130. 130. 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. 131. 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. 132. 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. 133. 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. 134. 134 Mergers and Acquisitions Scenario – 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. 135. 135 Mergers and Acquisitions Scenario – 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. 136. 136 WebSphere Message Broker – Architecture
  137. 137. 137 WebSphere Message Broker – Architecture
  138. 138. 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. 139. 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. 140. 140 WMB – Capabilities (contd.) – 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. 141. 141 WMB – Capabilities (contd.) – 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. 142. 142 WMB – Capabilities (contd.) – 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. 143. 143 WMB – Capabilities (contd.) 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. 144. 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. 145. 145 WMB – Capabilities (contd.) – Message Transformation and Enrichment – 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. 146. 146 WMB – Capabilities (contd.) – 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. 147. 147 WMB – Capabilities (contd.) – 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. 148. 148 WMB – Capabilities (contd.) – Message Transformation and Enrichment – 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. 149 WMB – Capabilities (contd.) – Message Transformation and Enrichment 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. 150. 150 WMB – Capabilities (contd.) – Message Transformation and Enrichment 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. 151. 151 WMB – Capabilities (contd.) – Message Transformation and Enrichment – 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. 152. 152 WMB – Capabilities (contd.) – 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. 153. 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. 154. 154 Enterprise Messaging – Messaging Transmission
  155. 155. 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. 156. 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. 157. 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. 158. 158 Publish Subscribe Implementation – Contd..
  159. 159. 159 Publish Subscribe Implementation – Contd..
  160. 160. 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. 161. 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. 162. 162 Publish Subscribe – Other Examples – Magazine publishing – Airline departure notification
  163. 163. 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. 164. 164 WebSphere MQ Interoperability contd…
  165. 165. 165 WMB – Components Overview
  166. 166. 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. 167. 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. 168. 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.
  169. 169. 169 Sample Message Flow
  170. 170. 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. 171. 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. 172. 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. 173. 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. 174. 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. 175. 175 Development Environment (contd.) 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. 176. 176 Development Environment (contd.) 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. 177. 177 Broker Application Development Perspective Toolkit Help Quick Starts Wizard Appear in the Project pane, when workspace is empty. Perspectives
  178. 178. 178 Broker Application Development Perspective (contd.) Projects Brokers Properties Problems Deployment Log Node Palette
  179. 179. 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. 180. 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. 181. 181 Runtime Environment (contd.) – 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. 182. 182 Runtime Environment (contd.) 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. 183. 183 Runtime Environment (contd.) 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. 184. 184 Runtime Environment (contd.) 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. 185. 185 Runtime Environment (contd.) 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. 186. 186 Runtime Environment (contd.) 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. 187. 187 Runtime Environment (contd.) 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. 188. 188 Runtime Environment (contd.) 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. 189. 189 Runtime Environment (contd.) 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. 190. 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. 191. 191 Interaction of Message Broker Main Components
  192. 192. 192 Interaction of Message Broker Main Components
  193. 193. 193 WebSphere Message Broker runtime architecture
  194. 194. 194 Usage Patterns with Message Broker Service Enablement Service Virtualization OR OR OR Message Enablement Message Brokering File Processing Event Processing
  195. 195. ?
  196. 196. Introduction to IBM WebSphere MQ Explorer
  197. 197. 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. 198. 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. 199. 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. 200. 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.
  201. 201. 201 WebSphere MQ Explorer
  202. 202. 202 Broker Properties
  203. 203. 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. 204. 204 Message Flow – Revisited – 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. 205. 205 Message Flow – Revisited – 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. 206. 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. 207. 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. 208. 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. 209. 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") Logical message format Parsed Constructed "Root" MQMD Format Report Version "Body" Order Name Supplier Order # Address Item Logical message format 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. 210. 210 Message Model (contd.) – Models are needed for parsing, validation and transformation – Domains avoid the need to write custom code to parse messages!
  211. 211. 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. 212. 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. 213. 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. 214. 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. 215. 215 Message Broker Parsers – Contd… – 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. 216. 216 Message Broker Parsers – Contd… – 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. 217. 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 Message Broker Parsers – Contd…
  218. 218. 218 Message Broker Parsers – Contd… – 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. 219. 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. 220. 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. 221. 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. 222. 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. 223. 223 Logical Tree Structure 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. 224. 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. 225. 225 Logical Tree Structure – 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. 226. 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.
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.