1

Architecture, Jargon and Resources

Oracle Service Bus

3

Web Svc Stack

Security Framework

MDBs JMS

Light Weight Web App

Work Manager

Deployment Framework

XQuery XBeans

Monitoring & Alert

Config Framework

User, Credential Access ctrl

OSB Runtime

Message Action Engine

Split-Join Flow Engine

Transport SDK

Lightweight Portal Framework

Service Bus console

WLS

Data Services

WLS

Common Services

UI

OSB Development

Services Resources

Report

Test Console

OEPE/Eclipse

Service Bus IDE

4

Binding Layer packs and unpacks messages as necessary handles security for messages hands messages off to start the message flows

(request and response) Transport Layer (Inbound) communication layer between client services (or

service consumers) and Oracle Service Bus deals with raw bytes of message data in the form

of input/output streams support for compatible transport protocols,

including HTTP(S), JMS, FTP, File, and E-mail Transport Layer (Outbound) communication between business services (or

service producers) and Oracle Service Bus not involved in data processing but handles

meta-data for messages, including endpoint URIs, transport headers

Proxy Services Proxy services are a fundamental concept in the architecture of Oracle Service Bus. Proxy services are definitions of intermediary Web services that the Service Bus implements locally. Oracle Service Bus allows configuration of a proxy service by defining its interface in terms WSDLs and the type of transport it uses. Message processing logic is specified in message flow definitions when defining a proxy service

PresenterPresentation NotesOracle Service Bus architecture is centered around an Enterprise Service Bus. The bus provides message delivery services, based on standards including SOAP, HTTP and Java Messaging Service (JMS). It is typically designed for high-throughput, guaranteed message delivery to a variety of service producers and consumers. It supports XML as a native data type, while also offering alternatives for handling other data types.Oracle Service Bus is policy driven and enables you to establish loose coupling between service clients and business services, while maintaining a centralized point of security control and monitoring. It stores persistent policy, proxy service, and related resource configurations in metadata, that can be customized and propagated from development through staging to production environments required. The message-brokering engine accesses this configuration information from its metadata cache.Oracle Service Bus is an intermediary that processes incoming service request messages, determines routing logic, and transforms these messages for compatibility with other service consumers. It receives messages through a transport protocol such as HTTP(S), JMS, File, and FTP, and sends messages through the same or a different transport protocol. Service response messages follow the inverse path. The message processing by Oracle Service Bus is driven by metadata, specified in the message flow definition of a proxy service.

Messaging / Protocols Multiple transports with transport bridging End-to-end guaranteed delivery SOAP, Non-SOAP, ReST, Non-XML support Sync/Async Request/Response, one-to-many publish Endpoint management

Priority based Throttling Load balancing and HA

Service Service Service

Service

Service Service Service

Service

Service Bus Security Authentication Authorization Identity Message Security

FTP MQ Messaging / Protocols

SMTP

Repository

Reporting SLA Alerts

Stateless Orchestration

Content Routing

Transformation

Validation

Service Management

Message Brokering Config Framework

HTTP/S SOAP JMS File

Change Center

UDDI Discovery

Monitoring

EJB/RMI Tux

JMX

Policy

Import/Export

Service Bus Security Transport (SSL) & Message (WS-Security) Security Authentication & Authorization Message Integrity & Message Confidentiality

Message Brokering Content-based routing SOAP, JMS, MQ - Headers & Content Integrated data transformation

XQuery and XSLT transformation support Schema driven console tools to create routing rules Support for non-XML content through MFL

Stateless orchestration

Configuration Framework Services mediated & proxies exposed by Service Bus Service metadata store Complete validation before deployment Cluster deployment

Service Management Monitor system operations with alerts and key monitoring

points Service Level Agreements

Performance thresholds Error thresholds

Pipeline Alert generation Service Management Dashboard Programmatic access to monitoring metrics

PresenterPresentation NotesRequest and response flows in a proxy service execute in different threads.Service callouts are always blockingHTTP Route or Publish actions are non-blocking if QoS is best-effortJMS Route or Publish actions are always non-blocking.Enable content streaming of body for very large message processing.Use split-join mediation pattern for parallelize the messaging and thus improving performance.Avoid using Java callouts and service callouts in general if possible

6

The context of a proxy service is a set of XML variables that are shared across the request flow and response flow. New variables can be dynamically added or deleted to the context. Predefined context variables contain information about the message, transport headers, security principles, metadata for the current proxy service, and metadata for the primary routing and publishing services invoked by the proxy service. The core of the context contains the variables $header, $body, and $attachments. These wrapper variables contain the Simple Object Access Protocol (SOAP) header elements, SOAP body element, and Multipurpose Internet Mail Extensions (MIME) attachments, respectively. The context gives the impression that all messages are SOAP messages, and non-SOAP messages are mapped to this paradigm. The context can be read and modified by XQuery expressions and updated by transformation and in-place update actions

PresenterPresentation NotesSince a proxy service can route messages to multiple business services, a proxy service can be configured with an interface that is independent of the business services it communicates with. Using generic proxy templates, the proxy service can be a configured as a message-flow definition that dynamically routes messages to appropriate business services based on content-based routing logic.A proxy service can also map message data into appropriate protocol formats required by the end-point business service, allowing for dynamic run-time protocol switching.

The implementation of a proxy service is specified by a message flow definition. The message flow defines the flow of request and response messages through the proxy service. The following four elements are used to construct a message flow: A pipeline pair, one for the request and one for

the response. The pipelines consist of a sequence of stages that specify actions to perform during request or response processing.

A branch node to branch based on the values in designated parts of the message or message context or to branch based on the operation invoked.

A route node used to define the message destination. The default route node is an echo node that reflects the request as the response.

A start node.

7

PresenterPresentation NotesMessage flow elements can be combined in arbitrary ways to form a tree structure with the start node always (and only) occurring as the root of the tree and the route nodes. The last nodes in a branch (leaf nodes) may be route nodes or echo nodes.

The request message starts at the start node and follows a path to a leaf node, executing actions in the request pipelines. If the leaf is a route node, a response is generated (could be empty if the service is a one way service). If the leaf is an echo node, the request is also considered to be the response. The response follows the inverse path in the tree skipping actions in the branch nodes, but executing actions in response pipelines.

8

Asynchronous request/reply Synchronous request/reply

Subscribe Push Pub-Sub/Broadcast or Fan-out

SOAP/HTTP

SOAP/HTTP

Oracle Service BusSOAP/HTTP

NativeMQ

NativeMQSOAP

/HTTP

JMS Queue

Oracle Service Bus

NativeMQ

JMS Queue

NativeMQ

Oracle Service BusNative

MQ

NativeMQ

JMS Topic

NativeMQ

Oracle Service Bus

Synchronous Request/reply

Asynchronous Request/reply

Fan Out

Pub-Sub

Aggregator and Split-Join

Oracle Service Bus 11g Components

10

Application Client

Service Clients

Oracle Service Bus Enterprise Services

transport transport Service Proxy

Service Business Service

Service Brokering

Inbound interface Outbound interface

11

Application Client

Service Clients

Oracle Service Bus Enterprise Services

Service

Application Client

Application Client

Application Client

HTTP/SOAP

JMS

FTP

REST

File Application Client

WS-RM

TUX

MQ

EJB

JCA

Service

Service

Service

Service

Request / Response

Service Messaging

Multiple communications paradigms Request/response Synchronous and asynchronous One-to-many, many-to-one Pub-sub Mix-and-match (e.g. sync-to-async)

Synch / Asynch

Split / Join

Publish / Subscribe

Any to Any Protocol Any to Any Payload

XML non-XML Binary

No WSDL Required

12

Adapter Certifications

Packaged with OSB install

AQ

Database

EBusiness Suite

Packaged separately

SAP

PeopleSoft

Siebel

JD Edwards

13

14

Dynamic publish Publish a message to a service specified by an XQuery expression.

Publish Identify a statically specified target service for a message and to configure how the message is packaged and sent to that service.

Publish table Publish a message to zero or more statically specified services. Switch-style condition logic is used to determine at run time which services will be used for the publish.

Routing options Modify any or all of the following properties in the outbound request: URI, Quality of Service, Mode, Retry parameters, Message Priority.

Service callout Configure a synchronous (blocking) callout to an Oracle Service Bus-registered proxy or business service.

Transport headers Set the header values in messages

15

For each Iterate over a sequence of values and execute a block of actions

If Then Perform an action or set of actions conditionally, based on the Boolean result of an XQuery expression.

Raise error Raise an exception with a specified error code (a string) and description.

Reply Specify that an immediate reply be sent to the invoker.

Resume Resume message flow after an error is handled by an error handler. This action has no parameters and can only be used in error handlers.

Skip Specify that at run time, the execution of this stage is skipped and the processing proceeds to the next stage in the message flow

16

Assign Assign the result of an XQuery expression to a context variable.

Delete Delete a context variable or a set of nodes specified by an XPath expression.

Insert Insert the result of an XQuery expression at an identified place relative to nodes selected by an XPath expression.

Java callout Invoke a Java method, or EJB business service, from within the message flow.

MFL transform Convert message content from XML to non-XML, or vice versa, in the message pipeline

Rename Rename elements selected by an XPath expression without modifying the contents of the element.

Replace Replace a node or the contents of a node specified by an XPath expression. The node or its contents are replaced with the value returned by an XQuery expression

Validate Validate elements selected by an XPath expression against an XML schema element or a WSDL resource

PresenterPresentation NotesNow its time to get familiar with some BPEL keywords. As one learns BPEL, one has to get familiar with its terminology.

PartnerLink is a representation of external endpoints like web services, JCA adapters, etc.Switch activity is for conditional branching - like a if-else construct.Invoke activity is for invoking external services through PartnerLinks.Receive activity is for getting call back messages from external systems.Flow activities are for parallel processing.While activity is similar to a while loop and is used for doing repetition of a given activity.

There are other activities like Wait, Pick, Java Exec, etc.

Oracle BPEL 11g stores the process state in a database which is known as the de-hydration store. During runtime, storing process instance state in the database is known as de-hydration and retrieving process instance state from the database is called hydration.

17

Application Client

Service Clients

Oracle Service Bus Enterprise Services

Service

Error-handling Features

Technology Errors/Faults

Validation Errors

Security Errors: authentication, authorization, signing, decryption

Process SOAP Faults

Raise Error on Custom-Defined Conditions

Enrich Custom Error Messages for invoking services

Search/Report by Error Conditions

Error-handlers at Service, Pipeline and Stage level

Validate

Proxy Business

Error Code

HTTP/SOAP

18

19

PresenterPresentation NotesIf you have more questions, please write to me at arrun.pareek@gmail.com

Thank you once again.

Oracle Service Bus 11gThe ArchitectureHigh Level ArchitectureKey Architecture ConceptsOSB in a NutshellOSB Key ConceptsMessage ContextOSB Key ConceptsMessage Flow -DefinitionsOSB Messaging PatternsThe ComponentsProxy & Business ServicesAdaptive Messaging In OSBJCA and Packaged System AdaptersSlide Number 13OSB Communication ActionsOSB Flow Control ActionsOSB Message ProcessingError-Handling, Testing & DebuggingSlide Number 18Q&AThank You!