ORACLE SOA SERVICE COMPONENTS,ADAPTORS

Service Components:

BPEL Process : BPEL (Business Process Execution Language) is an XML-based language that enables task-sharing in a distributed computing or grid computing environment.

Business Process Execution Language(BPEL) is an execution language for defining business processes. In short, it is the language for orchestrating multiple Web Services based on the business logic.

Business Rule : A decision component, also called a business rule service component, supports use of Oracle Business Rules in a SOA composite application. Decision components support the following SOA composite usage.

A decision component can be used within a SOA composite and wired to a BPEL component.
A decision component can be used within a SOA composite and used directly to run business rules.
A decision component can be used with the dynamic routing capability of Mediator.
A decision component can be used with the Advanced Routing Rules in Human Workflow.
Human Task : Oracle SOA Suite provides a graphical tool, known as the Human Task Editor, for modeling your task metadata. The modeling process consists of the following:
Creating and modeling a human task service component in the SOA Composite Editor
Associating it with a BPEL process
Generating the task form for displaying the human task during runtime in Oracle BPM Worklist.
Mediator : Oracle Mediator is a service component of the Oracle SOA Suite that provides mediation capabilities such as selective routing, transformation, and validation capabilities, along with various message exchange patterns, such as synchronous, asynchronous, and event publishing or subscriptions.
Oracle Mediator provides a lightweight framework to mediate between various components within a composite application.
Oracle Mediator converts data to facilitate communication between different interfaces exposed by different components that are wired to build a SOA composite application.
Difference between Mediator and BPEL

BPEL

1) Complex Logic

2) Good Support language in form of”activities”

3) Performance wise very slow

4) Support of Dehydration and Instance Monitoring

5) For Long Running process BPEL is the Right Solution

6) To implement the controlled Transactions

Integration of Rules Engine and Human Workflow

7) To implement the service virtualization BPEL is not the right approach

Mediator

1) Less Complex Logic

2) Less Support

3) Three times faster than BPEL

4) No support of de hydration

 5) For Long Running process not a proper solution

6) You cannot control the transactions in Mediator.

7) Mediator is the right approach for the service virtualization

Spring Context : The spring framework is a lightweight container that makes it easy to use different types of services. Lightweight containers can accept any JavaBean, instead of specific types of components.

Service Adapters:

ADF-BC Adapter : The ADF-BC service enables you to integrate Oracle Application Development Framework (ADF) applications using service data objects (SDOs) with SOA composite applications.                  

AQ Adapter : The AQ adapter enables you to interact with a single consumer or multiconsumer queue.
Oracle Streams AQ provides a flexible mechanism for bidirectional, asynchronous communication between participating applications.
 Advanced queues are an Oracle database feature, and are therefore scalable and reliable. Multiple queues can also service a single application, partitioning messages in a variety of ways and providing another level of scalability through load balancing.
B2B : The Oracle B2B service enables you to browse B2B metadata in the MDS repository and select document definitions.
Oracle B2B is an e-commerce gateway that enables the secure and reliable exchange of transactions between an organization and its external trading partners.
Oracle B2B and Oracle SOA Suite are designed for e-commerce business processes that require process orchestration, error mitigation, and data translation and transformation within an infrastructure that addresses the issues of security, compliance, visibility, and management.

BAM Adapter : The Oracle BAM adapter enables you to integrate Java EE applications with Oracle BAM Server to send data.

Database Adapter : The database adapter enables a BPEL process to communicate with Oracle databases or third-party databases through JDBC.

Direct Binding : The direct binding service uses the Direct Binding Invocation API to invoke a SOA composite application in the inbound direction and exchange messages over a remote method invocation (RMI). This option supports the propagation of both identities and transactions across JVMs and uses the T3-optimized path.
 Both synchronous and asynchronous invocation patterns are supported.You can also invoke an Oracle Service Bus (OSB) flow or another SOA composite application in the outbound direction.

EJB Service : The EJB service enables Enterprise JavaBeans and SOA composite applications to interact by passing SDO parameters (uses a WSDL file to define the interface) or Java interfaces (does not use a WSDL file to define the interface).

File Adapter : The file adapter enables a BPEL process or Oracle Mediator to exchange (read and write) files on local file systems. The file contents can be in both XML and non-XML data formats.

FTP Adapter : The FTP adapter enables a BPEL process or Oracle Mediator to exchange (read and write) files on remote file systems through use of the file transfer protocol (FTP). The file contents can be in both XML and non-XML data formats.

HealthCare Adapter : The Oracle Healthcare adapter enables you to create an end-to-end health care integration process in a SOA composite application. The Healthcare adapter establishes the connection between a SOA composite application and the external health care applications with which data is shared or with an internal topic or queue, where data can be made available internally or to other systems

Http Binding : The HTTP binding service enables you to integrate SOA composite applications with HTTP binding.

As a service binding component in the Exposed Services swimlane to invoke SOA composite applications through HTTP POST and GET operations
As a reference binding component in the External References swimlane to invoke HTTP endpoints through HTTP POST and GET operations
JMS Adapter : The JMS adapter enables an Oracle BPEL process or Oracle Mediator to interact with a Java Messaging System (JMS).
The JMS architecture uses one client interface to many messaging servers. The JMS model has two messaging domains:
Point-to-point: Messages are exchanged through a queue and each message is delivered to only one receiver.
Publish-subscribe: Messages are sent to a topic and can be read by many subscribed clients.
MQ  Adapter : The MQ adapter provides message exchange capabilities between BPEL processes and Oracle Mediator and the WebSphere MQ queuing systems.
The Messaging and Queuing Series (MQ Series) is a set of products and standards developed by IBM. The MQ Series provides a queuing infrastructure that provides guaranteed message delivery, security, and priority-based messaging.

Oracle Applications : The Oracle applications adapter provides connectivity to Oracle Applications. The adapter supports all modules of Oracle Applications in Release 12 and Release 11i, including selecting custom integration interface types based on the version of Oracle E-Business Suite.

SalesForce : The Runtime component of the Salesforce adapter implements the Cloud Runtime SDK to interact with Salesforce.com Enterprise WSDL SOAP APIs.

Socket Adapter : The socket adapter enables you to create a client or a server socket, and establish a connection. This adapter enables you to model standard or nonstandard protocols for communication over TCP/IP sockets. The transported data can be text or binary in format.

Third Party Adapter : The third party adapter enables you to integrate third-party adapters such as PeopleSoft, SAP, and others into a SOA composite application. These third-party adapters produce artifacts (WSDLs and JCA files) that can configure a JCA adapter.

UMS Adapter :

Web Service :

BPEL CONSTRUCTS:

Web service :

Invoke : Opens a port in the BPEL process service component to send and receive data. For example, this port is used to retrieve information verifying that a customer has acceptable credit using a credit card authorization service. For synchronous callbacks, only one port is needed for both the send and receive functions.

Partner Link : Defines the location and the role of the web services with which the BPEL process service component connects to perform tasks, and the variables used to carry information between the web service and the BPEL process service component. A partner link is required for each web service that the BPEL process service component calls. You can create partner links in several ways, including the following.

Receive : This activity specifies the partner link from which to receive information and the port type and operation for the partner link to invoke. This activity waits for an asynchronous callback response message from a service, such as a loan application approver service. While the BPEL process is waiting, it is dehydrated (compressed and stored) until the callback message arrives. The contents of this response are stored in a response variable in the process.
The receive activity supports the bpelx:property extensions that facilitate the passing of properties through the SOAP header, and the obtaining of SOA runtime system properties for useful information such astracking.compositeInstanceId and tracking.conversationId.

Reply : This activity allows the process to send a message in reply to a message that was received through a receive activity. The combination of a receive activity and a reply activity forms a request-response operation on the WSDL port type for the process.

Activities :

Assign : This activity provides a method for data manipulation, such as copying the contents of one variable to another. Copy operations enable you to transfer information between variables, expressions, endpoints, and other elements.

Compensate :  This activity invokes compensation on an inner scope activity that has successfully completed. This activity can be invoked only from within a fault handler or another compensation handler.

 Compensation occurs when a process cannot complete several operations after completing others. The process must return and undo the previously completed operations. For example, assume a process is designed to book a rental car, a hotel, and a flight.

The process books the car and the hotel, but cannot book a flight for the correct day. In this case, the process performs compensation by unbooking the car and the hotel.The compensation handler is invoked with the compensate activity, which names the scope on which the compensation handler is to be invoked.

Empty : This activity enables you to insert a no-operation instruction into a process. This activity is useful when you must use an activity that does nothing (for example, when a fault must be caught and suppressed).

Terminate : A terminate activity enables you to end the tasks of an activity (for example, the fault handling tasks in a catch branch).

 For example, if a client's bad credit history is identified or a social security number is identified as invalid, a loan application process is terminated, and the client's loan application document is never submitted to the service loan providers.

Throw : This activity generates a fault from inside the business process.

Wait : This activity allows a process to specify a delay for a certain period or until a certain deadline is reached. A typical use of this activity is to invoke an operation at a certain time. This activity enables you to wait for a given time period or until a certain time has passed. Exactly one of the expiration criteria must be specified.

Structured Activities :

Flow : This activity enables you to specify one or more activities to be performed concurrently. A flow activity completes when all activities in the flow have finished processing. Completion of a flow activity includes the possibility that it can be skipped if its enabling condition is false.

Pick : This activity waits for the occurrence of one event in a set of events and performs the activity associated with that event. The occurrence of the events is often mutually exclusive (the process either receives an acceptance or rejection message, but not both).

If multiple events occur, the selection of the activity to perform depends on which event occurred first. If the events occur nearly simultaneously, there is a race and the choice of activity to be performed is dependent on both timing and implementation.

Scope : This activity consists of a collection of nested activities that can have their own local variables, fault handlers, compensation handlers, and so on. A scope activity is analogous to a { } block in a programming language.
Each scope has a primary activity that defines its behavior. The primary activity can be a complex structured activity, with many nested activities within it to arbitrary depth. The scope is shared by all the nested activities.

Sequence : This activity enables you to define a collection of activities to be performed in sequential order. For example, you may want the following activities performed in a specific order:
A customer request is received in a receive activity.
The request is processed inside a flow activity that enables concurrent behavior.
A reply message with the final approval status of the request is sent back to the customer in a reply activity.

Switch : This activity consists of an ordered list of one or more conditional branches defined in a case branch, followed optionally by an otherwise branch. The branches are considered in the order in which they appear.

The first branch whose condition is true is taken and provides the activity performed for the switch. If no branch with a condition is taken, then the otherwise branch is taken. If the otherwise branch is not explicitly specified, then an otherwise branch with an empty activity is assumed to be available. The switch activity is complete when the activity of the selected branch completes.

While : This activity supports repeated performance of a specified iterative activity. The iterative activity is repeated until the given while condition is no longer true.