Oracle SOA components

Mediator:
Route: Determines the service component (BPEL process, business rule, human task, and mediator) to which to send the messages.
Validate: Provides support for validating the incoming message payload by using a schematron or an XSD file.
Filter: If specified in the rules, applies a filter expression that specifies the contents (payload) of a message be analyzed before any service is invoked.
Transformation: If specified in the rules, transforms document data from one XML schema to another, thus enabling data interchange among applications using different schemas.

Adapters:
Files
DB
JMS
JCA
BAM
FTP

Oracle Business Rules
Oracle Business Rules, initiated by a BPEL process service component, enable dynamic decisions at runtime allowing you to automate policies, constraints, computations, and reasoning while separating rule logic from underlying application code. In addition, the human task and mediator service components can make use of rules for dynamic routing. A mediator service component can use a business rule for routing messages, and a human task can use a business rule for routing assignments. The Oracle Metadata Repository (MDS) stores the rulesets for Oracle Business Rules.

Oracle BPEL Process Manager
Oracle BPEL Process Manager provides the standard for assembling a set of discrete services into an end-to-end process flow, radically reducing the cost and complexity of process integration initiatives. Oracle BPEL Process Manager enables you to orchestrate synchronous and asynchronous services into end-to-end BPEL process flows.
You integrate BPEL processes with external services (known as partner links). You also integrate technology adapters and services, such as human tasks, transformations, notifications, and business rules within the process.

BPEL Example

Synchronous (Short running) BPEL process consists of following:
1. Receive from client
2. Invoke
3. Reply to client

Right hand partner_links represent references to external services invoked by BPEL process

Sample BPEL Process example:
RoutePOEntryPoint (WebService Client for Composite app)
--> RoutePO (Mediator ) decides which BPEL to process
     --> ApproveCreditCardOrderBPEL for CreditCard orders --> uses ValidateCCService external web service as a partner link
      --> FullfillmentBPEL for PayPal orders -->  uses USPS adapter OR UPSJMSAdapter OR FedExJMS adapter as partner links
-->

SOA

http://www.infoq.com/resource/articles/applied-soa/en/resources/Applied-SOA.pdf

Legacy
Applications are built with internal logic to call each remote application/service they need to use. Kind of point to point integrations. With this approach, there are proprietery APIs, custom integration links and tight coupling of data and implementation

EAI
Connectivity between each application is based on middleware or message bus using EAI vendor's API which is proprietery