OSB_001：Oracle Service Bus 10gR3 介绍

Oracle Service Bus的前身是BEA的AquaLogic Service Bus。

OSB的价值所在OSB enables IT to move away from complex, brittle, point-to-point integration implementations and accelerate service re-use and deployment.
The goal of Oracle Service Bus is to eliminate tightly coupled point-to-point connections and replace with an intelligent intermediary designed to enable service governance, visibility, interaction and management across heterogeneous service end-points, for both service consumers (service clients) and service providers (business services).
A key design philosophy of Oracle Service Bus is in that it physically separates a set of management functions from the service implementations, thus allowing the implementations to evolve independently and dynamically as driven by the needs of the business without requiring costly infrastructure development efforts.

OSB的核心特点
OSB is a lightweight, stateless, high-performance architecture, delivers an intermediary for use as a core element of distributed services networks.
Oracle Service Bus is policy-driven and enables loose coupling between service clients (the service consumers) and business services (the service providers), providing a point of security control, monitoring and SLA enforcement.
Changes to service integration relationships are implemented dynamically through configuration, not code, enabling customers to change and evolve their service architectures with respect to security; service location, availability and responsiveness; data formats; logging and monitoring; transports and communications.
问题1：请具体说明OSB的动态配置的含义?
Many ESB products have development-oriented model with tools generating J2EE code that is then deployed into the app server (such as WebLogic Integration).
Oracle Service Bus is designed from the ground up to be driven by metadata that can be updated at runtime (vs. design time).
Instead of deploying J2EE artifacts, one deploys XML metadata repositories between dev, stage, and production environments, in an incremental manner.
This in our view should significantly reduce the regression test cost typically associated with code-oriented deployments.
问题2：OSB似乎与BPEL有很多功能重叠，我们该如何选择?
Actually OSB fits even better the definition of a pure ESB (complete web-based service console, pipeline design, wealth of features targeting SOA operations, etc.) so the previous positioning still works very well, if not better - the different audiences and use cases between BPEL and ESB are clearer than ever. See below for more details on positioning BPEL vs ESB.

问题3：何时使用 BPEL，何时使用ESB?
In a nutshell, BPEL is really targeted at orchestration of services, while an ESB is meant to mediate and provide location and technology transparency of services.
BPEL users often build applications - and their primary tool is an IDE (JDeveloper), while ESB administrators often manage services - and their primary tool is the OSB web console.
By preserving this clear separation of concerns, one can relocate a service, or add capacity to a service without impacting the application design and flows whatsoever.
There is some features overlap between BPEL PM and OSB, mostly because of their history. BPEL PM has been used to implement ESB patterns in the past, and OSB has been used to do some lightweight orchestration.
But by using them for their primary purpose you will benefit from their respective optimizations and strengths: BPEL PM is designed to handle long-running, stateful processes while OSB excels at very fast mediation of services.

OSB is specifically targeted at service brokering and stateless message routing and transformation.
OSB can be used by itself in scenarios where interactions do not require complex sequencing.
For example, OSB is not a good fit for interactions between clients and servers (for service-oriented models) or message producers and consumers (for message-oriented models) that hand off messages to multiple endpoints, collect responses, then collate into a single response.
In this case, the endpoints themselves should be process-aware and can do their own correlation.
OSB's goal is to be a simple service/message bus that is not aware of application-specific process logic; it can be operated almost as an infrastructure "appliance" rather than an application. There is also a set of scenarios where OSB is used as a pure management intermediary: its role is primarily not to route and transform messages, but rather monitor message flows, track message data, and enforce SLAs for service endpoints.