There are lots of things that you need to consider before you choose OSB or SOA or both. Like below.
a. What is the business requirements
b. Do you want to transfer message in runtime or in batch mode
c. Do you want to dehydrate your instances or not
d. Do you want to have the interface in sync mode or async mode
e. what is the max payload size
f. what are the protocols involved in the integration ? and so on...
Share your usecase that you want to develop, then we can help you.
When chosing SOA it wil have implications on the whole organisation. Not a problem, but good to keep in mind.
Within the Oracle SOA Suite, the OSB is the preferred tool for enabling transport external to the SOA Suite.
It is a very good product.
When necessary, you can integrate with adapters from BPEL/ESB world.
Below are examples of use cases that require a full
-fledged orchestration engine and should not be implemented on Oracle Service Bus:
•Service needs to maintain state
•Service requires complex transaction management
•Requires multiple transactions
•Compensation logic required on rollback
•Short or long-lived process
•Exception handling requires Human workflow
•Service needs to handle asynchronous callbacks reliably
Hi there, this is a good discussion and I agree with all said.
My general rule is, if you're orchestrating and calling more than one set of services and maybe some custom code use BPEL and SCA to accomplish that. So in itself processing happens in a whole different layer, but when a service is basic and atomic thus calling only one storeproc or something in those line (one service) just use OSB straight for that. OSB should be pass through and a gateway to functionality and can also be a gateway to your composite applications... So it's a good idea to proxy your composite services so that is another layer making that some atomic functionality but course grained at the back.