oracle service bus architecture, jargon and resources1
DESCRIPTION
OSB service busTRANSCRIPT
-
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 [email protected]
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!