Internals Of IBM Integration Bus - SHARE

Transcription

Internals of IBM Integration BusDavid ColesIBM Integration Bus Level 3 Technical Lead,IBM Hursley – dcoles@uk.ibm.com7th August 201416200InsertCustomSessionQR ifDesired.

Agenda IntroductionRuntime ProcessesThreadsMemoryDiagnostic InformationExternal Internals– Execution Engine / Stack Size– Node lifecycle– Parsers and the Logical Tree

Introducing IBM Integration BusIBM’s Strategic Integration Technology– Single engineered product for .NET, Java and fully heterogeneous integration scenarios– DataPower continues to evolve as IBM’s integration gatewayIntegrationGatewayEdgeIntegration BusERP/EIS/CRMFilesWeb 2.0DevicesWeb ServicesRetailMicrosoftMQ, abasesA Natural Evolution for WebSphere Message Broker users Significant innovation and evolution of WMB technology base New features for Policy-based WLM, BPM integration, Business rules and .NETDesigned to incorporate WebSphere Enterprise Service Bus use cases Capabilities for WESB are folded in to IBM Integration Bus over time Conversion tools for initial use cases built in to IIB from day one WESB technology remains in market, supported. Migrate to Integration Bus when readyMobile

Integration Bus ComponentsIntegrationBus ToolkitIntegrationBus ExplorerCommand lineThird PartyToolsIntegration Bus Java APIIntegration Bus NodeWeb UIIntegration BusREST APIGET /admin/eg/MYEGNAMEFrom: machine@ibm.comUser-Agent: MyApp/1.0

Runtime Processes

Processes bipimain– z/OS only. The first process in any IIB address space. APFauthorised to set up authorised routines. bipservice– Lightweight and resilient process that starts and monitors thebipbroker process (a.k.a AdminAgent).– If the bipbroker process fails, bipservice will restart it. bipbroker– A more substantial process. Contains the deploymentmanager, for CMP and REST connections, as well as theWebUI server. All commands, toolkit connections and WebUIgo through this process.– Responsible for starting and monitoring the biphttplistenerand DataFlowEngine processes.– If either process fails, bipbroker will restart them. biphttplistener– Runs the brokerwide HTTP connector for HTTP and SOAPnodes. DataFlowEngine (a.k.a Integration Server)– Runtime engine for all deployed resources.

Processes by platform Linux and Unix systemsPIDParentPID Windows

Processes grouped by Address Space on z/OS/s nnBRKMessage Broker Address SpacesControlProcessExecutiongroup 1Executiongroup re ollerMessage Flow ter NodeWarehousing NodeLEprocessNeonRulesOutputNodeRRS

Displaying broker at the process level on z/OS

Horizontal Scaling with additional processes IBM Integration Bus supports horizontal scaling. This is achieved byincreasing the number of integration servers the service is running in. Reasons to add additional integration servers:– Increased throughput– Operational simplicityPhysical Server– Workload isolationIntegration Node– Better H/W utilisation– Higher grationServerIntegrationServerHorizontally ScaleMsgRateCPUMQ QueueManager123Servers4

Threads

Integration Flow threads (instances) Every flow will have at least 1 thread per input node.– On z/OS, these threads are TCBs. Held within a pool for each input node. Increase threads by adding “additional instances”. The integration server will start additional instances ondemand, as the amount of incoming work increases, upto the limit specified. If they are idle then additional instances are stopped. Additional instances can be started immediately whenthe integration server starts. Be aware of adding additional instance at the flow levelwhen there are multiple input nodes in the same flow!

Setting additional instances In IIB V9, additional instances can be set by creating aworkload management policy in the WebUI Additional instances can also be defined on the input node, as aBAR file override and from IIB Explorer.

Vertical Scaling with additional threads IBM Integration Bus supports vertical scaling. This is achieved byincreasing additional instances (threads) of the service running withinthe integration server. Reasons to add additional instances:– Increased throughputPhysical Server– Lower memory requirement– Better H/W utilisationIntegration Node– Policy managementIntegrationServerMsgRateCPU123Additional Instances4Vertically ScaleMQ QueueManager

Other thread pools There are other thread pools for the HTTP connectors.Integration NodebiphttplistenerHTTP Listener HTTP Connector for embedded listenerIntegrationIntegrationServerServerHTTP ListenerMQ QueueManager– mqsireportproperties IB9NODE -e default -o HTTPConnector -a HTTP Connector for broker wide listener– mqsireportproperties IB9NODE -b httplistener -o HTTPConnector -a

HTTP Connector parameters Check the IIBInfocenter for a list ofall the HTTPConnectorparameters, and theirdefault values.

Memory

Memory use within an Integration Server The Integration Server runtime comprises both C and Java. Thismeans there is a multi faceted approach to checking memory.Integration Server The Integration Server is aprocess (DataFlowEngine).Its size is limited by availablememory and configuration onthe operating system. There is 1 JVM within eachIntegration Server. The JVMhas preconfigured minimumand maximum HEAPsettings.Native MemoryJVM Memory

What are the main consumers of memory? Normal (low) consumers of memory include:– Deployment artefacts– Configuration, such as increasing the min JVM HEAP– Message flows– Additional instanceSee Parser– Stats later! What to watch for:– Size of input messages (1K or 1GB)– How messages are parsed (whole file or records)– Message Tree copying (transformation nodes)– Custom code (ESQL, Java etc)– Caching (Shared Variable, GlobalCache etc)– JVM settings

How to check process memory usage Use operating system tools to view the DataFlowEngine process size– Windows, Process Explorer– AIX– Unix/Linux– z/OS–––vsz The size in kilobytes of the core image of the processrss Indicates the real memory (resident set) size of the process (in 1 KB units)Real 4k pages

How to check JVM memory usage1. Check defaults:–mqsireportproperties IB9NODE -e default -o ComIbmJVMManager –a jvmMinHeapSize–Initial value: -1, which represents 33554432 bytes (32MB) with the globalcache disabled, or 100663296 (96MB) with the global cache enabled jvmMaxHeapSize–Initial value: -1, which represents 268435456 bytes (256 MB)2. Check usage with Resource Statistics

Diagnostic Information

Diagnostic Information in WMB Diagnostic Information–––––––Resource StatisticsFlow StatisticsActivity LogAdministration LogSystem LogTraceStdout/Stderr

Resource Statistics Graphical Performance Monitor– Reports comprehensive usage according of well known resources Message Flows, Nodes, JVM, HTTP, SOAP/HTTP sockets etc Optionally partitioned by Broker, Execution Group and Message Flow Reporting Mechanisms– Graphically reported through IIB Explorer Sort, filter and chart performance characteristics View CPU, IO and other metrics Log data to file in CSV/Excel readable format for post processing– User Configurable Reporting Interval XML report messages consumed by any end user application Examples of Available Resource Report Metrics– JVM: Memory used, thread count, heap statistics – Sockets: Socket host/port open; bytes sent, bytes received

Flow Statistics Using the WebUI inIntegration Bus v9:– Control statistics at alllevels– Easily view and compareflows, helping tounderstand which areprocessing the mostmessages or have thehighest elapsed time– Easily view and comparenodes, helping tounderstand which havethe highest CPU orelapsed times.– View all statistics metricsavailable for each flow– View historical flow data

Integration Bus Explorer & Activity Log View activity as it happens using explorer Filter by resource managers

Administration Queue / Log The tools include a lot of information that is usefulto the administrator, for example:– Administration queue: What operationalchanges are currently pending– Administration log: What changes have beenrecently applied to the broker’s configuration,and by whom?

Types of trace in Integration BusTrace is available for separate components which can be formatted to a fileusing: mqsichangetrace to enable trace mqsireadlog (BIPRELG) to read trace mqsiformatlog (BIPFMLG) to formatTypes of trace available: User Trace – for you. Service Trace – for IBM Support Command Trace – for IBM Support CVP (Component Verification) Trace – for all

User Trace ExampleUserTrace tells you exactly what is happening as a message passesthrough an integration data flow.See which nodes are being called, which parsers are being used, andwhat ESQL is executed.

SYSLOG / JOBLOG / STDOUT / STDERRThe Integration Bus runtime writes important operational messages to the system log: On z/OS, each JOBLOG includes all messages written by processes within theaddress space. The SYSLOG includes messages from all IIB JOBLOGs. On Windows, these messages are written to the event log. On Unix and Linux, these messages are written to the syslog.STDOUT/STDERR may also be written to: On z/OS, each JOBLOG includes any STDOUT/STDERRwritten by processes within the address space. On Windows, the console.txt file in%MQSI REGISTRY%\components\ node \ EG UUID On Unix/Linux, the stdout and stderr files in MQSI REGISTRY/components/ node / EG UUID

External Internals

Stack based execution engine Useful to understand how flows execute when designing themStart ‘MQ Input’Start ‘Compute’Start ‘Mapping’Start ‘MQ Output’Finish ‘MQ Output’Finish ‘Mapping’Start ‘Java Compute’Finish ‘Java Compute’Finish ‘Compute’Finish ‘MQ Input’ Stack:MQ InputComputeMappingJavaComputeMQ OutputLooping node connections can lead to large stack requirementsWith looping and large flows may need to increase the threadstack size– MQSI THREAD STACK SIZE sizeInBytes (Unix/Windows) (default is 1Mb)On z/OS the thread stack size is dynamic– Default size is 1Mb with 1Mb extents– Using the extents can impact performance if you regularly use them– Increase the default or extent size CEE RUNOPTS THREADSTACK64(ON,4M,1M)– Use RPTSTG(ON) option to get a report of stack sizes which were used

Transaction Model on z/OS Message flowThe z/OSbroker has aglobaltransactionmodel exactlyas you’dexpect. It ispossible fornodes to electto commitoutside thistransaction.RRS is usedfor contextmanagement& commitmentcontrolbetween theflows resourcemanagers, butonly whenrequired. coordinatedTransaction Yes or No * MQInput node * transactionMode Yes (or Automatic) global UOW Transaction DataUpdate node MQOutput node transactionMode Automatic Native Context transactionMode Yes (or Automatic) non-transactional DataInsert node * * Private Context transactionMode Commit local UOW begin global transaction ATRBEG private context SqlExecute Resource Manager WMQ commit node transaction SqlTransact Resource Manager DB2 commit global transaction MQCMIT Transaction Manager WMQ COMMIT Resource Recovery Services RRS commit global transaction SRRCMIT

Notes : Transaction Model Transactional message flows are important–A message flow which transforms and routes data often has a need to be transactional. That is, the message flow must complete either*all or none* of its processing. Remember, from an end-to-end application perspective, the message flow is *part* of the application.Transactional data flows and data nodes.–A message flow can be identified as transactional using the Coordinated Transaction checkbox on a broker assigned message flow. Theintention behind this attribute is that all node operations within the message flow can be coordinated under the same, global, transaction.On z/OS, this option is always used for message flows, whether selected or not.–A node performs its operations within the envelope of this message flow global transaction, and can elect to be within the globaltransaction or not. A Transaction Mode checkbox enables this for WMQ and database nodes. Note the visibility (ACID) implications!Resource Recovery Services (RRS) is *NOT* always the transaction coordinator.–As message flows run in essentially a batch type address spaces, RRS is the global transaction coordinator, if required.–Execution groups are linked with an MQ RRS stub, so WMQ registers an interest with RRS for commitment control.–Specifying the keywords CONNECTTYPE 2, AUTOCOMMIT 0, MULTICONTEXT 0, and MVSATTACHTYPE RRSAF in theinitialization file BIPDSNAO enables global transaction processing.RRS Context–RRS Context is a concept that enables a program to have different roles. It's like one person having many ways of behaving which don'tinteract with each other. It means that applications can simultaneously be different things to different systems.–Broker flows have two contexts. A *native* context is used whenever it wants to perform the role of including node operations under theglobal transaction. A *private* one has the effect of excluding database node operations from a global transaction.–Plug-in nodes are always within the global transaction. A message flow is always in *native* context for these nodes.WebSphere MQ–*Transaction Mode* within a message queuing node governs whether MQPUT and MQGET operations are explicitly performed eitherinside or outside syncpoint on a per call basis. These nodes therefore always use the native, and never the private, RRS context.Database–For database nodes, *Transaction Mode* determines under which RRS context the transaction will be performed. If the node is within theglobal transaction, then the native context is used. For a Transaction Mode of *commit*, the private context, so that DB2 and RRS seethe operation from a logically different party. These nodes commit (using SQLTransact) their operations as the node is exited.Commitment Control–The global transaction is begun implicitly when a resource manager communicates with RRS. The overall message transaction iscommitted (or backed out!) control returns to the input node. At COMMIT time, WMQ will pass control to RRS only if required.–RRS will call all registered resource managers (WMQ, DB2) in a two phase commit protocol to ensure a global transaction. Recall thatnodes which elected for a Transaction Mode of commit had resources updated (and externally visible!) close to their point of issuing. IfRRS is not required WMQ will perform the commitment control and delete any RRS interests.

Node Lifecycle (Mid-flow) All mid-flow nodes follow this life cycle– Constructor– –Validate configured propertiesCalled either during deployment or on broker startup.If it throws an exception, deployment or startup is rolled back/stopped The broker does not try to start the flow again until the broker is restartedComplete tasks that will always work or always fail If you need to initialize an external connection that might need to be retried, considerdoing so on the first message through the flow so that the flow can retry the connectionas necessaryEvaluate––– Called when the node is created as the flow is initializedProperties are then set on the nodeonInitialize()––– IBM written and plugin/compute nodesCalled when execution of a message is requiredPerform required node processingExceptions which are thrown and thrown back down the flow to be handledOnDelete–––Called before a node is deletedUse if you want the node to perform cleanup operations, for example closing sockets,Should not throw exceptions

Node Lifecycle (Input) All non-connector input nodes follow this basic lifecycle Constructor–Called when the node is created as the flow is initialized Properties are then set on the nodeonInitialize() run–––– Called by broker when we want the node to try and read dataNode reads data and then propagates the resulting messageAdditional instances If you want your input node to support additional instances then before propagating themessage the node needs to call dispatchThread to try and dispatch another thread toread more dataReturns success/failure/timeout depending on resultonDelete

ParsersModelInput Message Bit-streamFredSmith,GraphicsC a r d Parser convertslogical structureto bit-streamParser convertsbit-stream tological structure o r d e r n a m e M r . S m i t h / n ModelOutput Message Bit-stream

Message ModelingPhysicalLogical order name first John /first last Smith /last /name item Graphics Card /item quantity 32 /quantity price 200 /price date 07/11/09 /date /order OrderNameJohn,Smith,Graphics Card,32,200,07/11/09John Smith.Graphics ceDateStringIntegerIntegerDate

Here is an example of how a physical data structure could be mapped to a logical tree.– Notice how multiple physical formats can correspond to the same logical tree. Thefirst physical format is an XML structure that shows our Order message. The secondis a comma separated value (CSV) structure of the same. The third comprises a set of fixedlength fields in a custom wire format.– By manipulating the logical tree inside the Message Broker rather than the physical bit-stream,the nodes can be completely unaware of the physical format of the data being manipulated. Italso makes it easy to introduce new message formats into the broker. Applications have and require diverse data formats.– We all know that XML is the data format that's going to solve every data processing problemthat exists! We also know that "XML ", the follow-on compatible meta format that someone ina research laboratory is working on will solve all the problems we don't even know we havetoday! The fact is that, without wanting to appear cynical, every generation goes through thisprocess. Surely it was the same when COBOL superseded assembler.– The fact is, that for historic, technical, whimsical, political, geographical, industrial and a wholehost of other reasons you probably never even thought of, a hugely diverse range of dataformats exist and are used successfully by a myriad of applications every second of every day.It's something that we have to live with and embrace because it isn't going to get any better anytime soon.– The advantage WebSphere Message Broker brings by modelling all these messages is that wecan rise above the message format detail; so that whether it's a tag delimited SWIFT orEDIFACT message, a custom record format closely mapping a C or COBOL data structure, orgood old XML, we can talk about messages in a consistent, format independent way. MessageBroker can manage this diversity.

The Logical Message Model.–Reconsider messages and their structure. When we architect messages (no matter what theunderlying transport technology), we concern ourselves firstly with the logical structure. Forexample, a funds transfer message might contain an amount in a particular currency, atransaction date and the relevant account details of the parties involved. These are theimportant business elements of the message; when discussing the message, we refer to theseelements.–However, when we come to realize the message, we have to choose a specific data format.This may be driven by many factors, but we have to choose one. You may be aware of theadvantages of various message formats or have your own personal favourite, or may fancyinventing a new one, but the fact remains that you have to choose a physical *wire format*. Sofor our transfer message, we might decide to use XML, with its elements, attributes andPCDATA (and a DTD, if we're being really exact), or we might map more closely to a C datastructure modelling our message with ints, shorts, chars etc. and worry about *their* variousrepresentations(!)–The Logical message model provided by IBM Integration Bus allows one to describe amessage in terms of a tree of elements, each of which has a (possibly user defined) type. Atthe message tree leaf nodes, the elements have simple types such as strings, integers,decimals, booleans etc. Moreover, elements can have various constraints and qualifiers appliedto them that more fully describe them; e.g. elements might be optional, appear in a certainorder or only contain certain values.

Message Tree eadersEncoding Body TransactionalOrderName Item Qty Price DateFirst Last

Parser Domains The message domain identifies the parser that is used to parse and write instances ofthe message.– Eg: BLOB, XMLNSC, DFDL The remaining parts of the message template, message model, message (type), andphysical format, are optional, and are used by model-driven parsers such as the DFDLparser.4 Main parser types– Root– Properties– Header– BodyNeither the Root or Properties parsers claim any of the incoming bitstream

The logical tree Tree is made up of SyntaxElement objects which are logically linked– MbElement / NbElement / CciElement Each element contains the Name, Namespace and Value which describe that elementEach element knows what type of element it is (Folder, Name, Value, NameValue, etc)Each element knows its family relationshipEach element knows its parse state (leftComplete/rightComplete)– This supports partial/onDemand Type(Integer)Value(Value Type)leftSibling(Pointer to SyntaxElement)firstChild(Pointer to SyntaxElement)parent(Pointer to SyntaxElement)lastChild(Pointer to SyntaxElement)rightSibling(Pointer to SyntaxElement)

The logical tree - linkage The logical tree is made up of ImbSyntaxElement objects which are logically linkedParentleftSibling / rightSiblingfirstChild / lastChildParentParentParentleftSibling / rightSiblingleftSibling / rightSiblingleftSibling / rightSiblingfirstChild / lastChildfirstChild / lastChildfirstChild / lastChildParentleftSibling / rightSiblingfirstChild / lastChild

The logical tree - navigation Navigation of the tree is done using a set of similar methods across all languagesParentNullleftSiblingNull/ rightSiblingNullfirstChild / rent()getFirstChild()ParentNullleftSibling/ rightSiblingNullfirstChild/ arentleftSibling / rightSiblingNullNullfirstChild/ tleftSibling / rightSiblingNullNullfirstChild/ lastChildNull

Trace node output - ?( ['MQROOT' : 0xed8efe0](0x01000000:Name ):Properties ( ['MQPROPERTYPARSER' : 0xed2b2c0](0x03000000:NameValue):MessageSet '' ssuedBy '' (CHARACTER))(0x01000000:Name ):MQMD ( ['MQHMD' : 0xed2bcb0](0x03000000:NameValue):SourceQueue 'VFE.IN1' (CHARACTER).(0x03000000:NameValue):OriginalLength -1 (INTEGER))(0x01000000:Folder):XMLNSC ( ['xmlnsc' : 0x1d24b30](0x01000000:Folder):order (.)))

Trace node output – Root element/Parser( ['MQROOT' : 0xed8efe0](0x01000000:Name ):Properties ( ['MQPROPERTYPARSER' : 0xed2b2c0](0x03000000:NameValue):MessageSet '' ssuedBy '' (CHARACTER))(0x01000000:Name ):MQMD ( ['MQHMD' : 0xed2bcb0](0x03000000:NameValue):SourceQueue 'VFE.IN1' (CHARACTER).(0x03000000:NameValue):OriginalLength -1 (INTEGER))(0x01000000:Folder):XMLNSC ( ['xmlnsc' : 0x1d24b30](0x01000000:Folder):order (.)))

Trace node output - Parsers( ['MQROOT' : 0xed8efe0](0x01000000:Name ):Properties ( ['MQPROPERTYPARSER' : 0xed2b2c0](0x03000000:NameValue):MessageSet '' ssuedBy '' (CHARACTER))(0x01000000:Name ):MQMD ( ['MQHMD' : 0xed2bcb0](0x03000000:NameValue):SourceQueue 'VFE.IN1' (CHARACTER).(0x03000000:NameValue):OriginalLength -1 (INTEGER))(0x01000000:Folder):XMLNSC ( ['xmlnsc' : 0x1d24b30](0x01000000:Folder):order (.)))

Trace node output – Element Type( ['MQROOT' : 0xed8efe0](0x01000000:Name ):Properties ( ['MQPROPERTYPARSER' : 0xed2b2c0](0x03000000:NameValue):MessageSet '' ssuedBy '' (CHARACTER))(0x01000000:Name ):MQMD ( ['MQHMD' : 0xed2bcb0](0x03000000:NameValue):SourceQueue 'VFE.IN1' (CHARACTER).(0x03000000:NameValue):OriginalLength -1 (INTEGER))(0x01000000:Folder):XMLNSC ( ['xmlnsc' : 0x1d24b30](0x01000000:Folder):order (.)))

Trace node output – Element Name( ['MQROOT' : 0xed8efe0](0x01000000:Name ):Properties ( ['MQPROPERTYPARSER' : 0xed2b2c0](0x03000000:NameValue):MessageSet '' ssuedBy '' (CHARACTER)) ( ['MQHMD' : 0xed2bcb0](0x01000000:Name ):MQMD(0x03000000:NameValue):SourceQueue 'VFE.IN1' (CHARACTER).(0x03000000:NameValue):OriginalLength -1 (INTEGER))(0x01000000:Folder):XMLNSC ( ['xmlnsc' : 0x1d24b30](0x01000000:Folder):order (.)))

Trace node output – Element Value( ['MQROOT' : 0xed8efe0](0x01000000:Name ):Properties ( ['MQPROPERTYPARSER' : 0xed2b2c0](0x03000000:NameValue):MessageSet '' ssuedBy '' (CHARACTER))(0x01000000:Name ):MQMD ( ['MQHMD' : 0xed2bcb0](0x03000000:NameValue):SourceQueue 'VFE.IN1' (CHARACTER).(0x03000000:NameValue):OriginalLength -1 (INTEGER))(0x01000000:Folder):XMLNSC ( ['xmlnsc' : 0x1d24b30](0x01000000:Folder):order (.)))

Trace node output – Element Value Type( ['MQROOT' : 0xed8efe0](0x01000000:Name ):Properties ( ['MQPROPERTYPARSER' : 0xed2b2c0](0x03000000:NameValue):MessageSet '' ssuedBy '' (CHARACTER))(0x01000000:Name ):MQMD ( ['MQHMD' : 0xed2bcb0](0x03000000:NameValue):SourceQueue 'VFE.IN1' (CHARACTER).(0x03000000:NameValue):OriginalLength -1 (INTEGER))(0x01000000:Folder):XMLNSC ( ['xmlnsc' : 0x1d24b30](0x01000000:Folder):order (.)))

Building the logical tree – aka parsing! For XML it is easy to visually see how we get from the input message to the logicalmodelBut how?The parser fires events back to a handler and the handler then creates the tree– Java SAX like parsing– DFDL parser follows same model– This model allows of OnDemand/partial parsing Reduced memory as you do not always require all of the logical tree in memory Order Name Order First John /First Last Smith /Last /Name Item Graphics Card /Item ?Name Item Qty Price DateString Qty 32 /Qty Price 200 /Price Date 07/11/09 /Date /Order First LastStringStringStringStringString

Building the logical tree – aka parsing!Events: startDocument– startElement (Order) Order Name First John /First Last Smith /Last /Name Item Graphics Card /Item Qty 32 /Qty Price 200 /Price Date 07/11/09 /Date /Order Order

Building the logical tree – aka parsing!Events: startDocument– startElement (Order) startElement (Name) Order Order Name First John /First Last Smith /Last /Name Item Graphics Card /Item Qty 32 /Qty Price 200 /Price Date 07/11/09 /Date /Order Name

Building the logical tree – aka parsing!Events: startDocument– startElement (Order) startElement (Name)– startElement (First) Order Order Name First John /First Last Smith /Last /Name Item Graphics Card /Item Name Qty 32 /Qty Price 200 /Price Date 07/11/09 /Date /Order First

Building the logical tree – aka parsing!Events: startDocument– startElement (Order) startElement (Name)– startElement (First)» elementValue(John)– endElement Order Order Name First John /First Last Smith /Last /Name Item Graphics Card /Item Name Qty 32 /Qty Price 200 /Price Date 07/11/09 /Date /Order FirstString

Building the logical tree – aka parsing!Events: startDocument– startElement (Order) startElement (Name)– startElement (First)» elementValue(John)– endElement– startElement (Last) Order Name First John /First Order Last Smith /Last /Name Item Graphics Card /Item Qty 32 /Qty Name Price 200 /Price Date 07/11/09 /Date /Order First LastString

Building the logical tree – aka parsing!Events: startDocument– startElement (Order) startElement (Name)– startElement (First)» elementValue(John) (String)– endElement– startElement (Last)» elementValue(Smith) (String)– endElement Order Order Name First John /First Last Smith /Last /Name Item Graphics Card /Item Name Qty 32 /Qty Price 200 /Price Date 07/11/09 /Date /Order First LastStringString

Building the logical tree – aka parsing!Events: startDocument– startElement (Order) startElement (Name)– startElement (First)» elementValue(John) (String)– endElement– startElement (Last)» elementValue(Smith) (String)– endElement endElement Order Order Name First John /First Last Smith /Last /Name Item Graphics Card /Item Name Qty 32 /Qty Price 200 /Price Date 07/11/09 /Date /Order First LastStringString

Building the logical tree – aka parsing!Events: startDocument– startElement (Order) startElement (Name)– startElement (First)» elementValue(John) (String)– endElement– startElement (Last)» elementValue(Smith) (String)– endElement endElement startElement (Item) Order Order Name First John /First Last Smith /Last /Name Name Item Item Graphics Card /Item Qty 32 /Qty Price 200 /Price Date 07/11/09 /Date /Order First LastStringString

Building the logical tree – aka parsing!Events: startElement (Name)– startElement (First)» elementValue(John) (String)– endElement– startElement (Last)» elementValue(Smith) (String)– endElement endElement startElement (Item)– elementValue(Graphics Card) (String) endElement Order Order Name First John /First Last Smith /Last /Name Item Graphics Card /Item Name ItemString Qty 32 /Qty Price 200 /Price Dat

Introducing IBM Integration Bus IBM's Strategic Integration Technology - Single engineered product for .NET, Java and fully heterogeneous integration scenarios - DataPower continues to evolve as IBM's integration gateway A Natural Evolution for WebSphere Message Broker users Significant innovation and evolution of WMB technology base