I am working on a requirement which is as follows:
1) Need to make a composite service out of a wsdl (already defined)
2) There are around 10 operations in the wsdl
3) Each operation is an action on some Business Entity such as Create, Update, Delete, Query etc.
4) We require to implement all operations as a single endpoint i.e. as a single composite application
Could you please suggest what is the best SCA structure for this requirement.
The Web Services binding can be used at inbound ( Exposed Service Lane) to expose your SOA composite application over single endpoint.
Need to make a composite service out of a wsdl (already defined)
In the create Web Service window click on find existing wsdl to locate your pre existing wsdl.
After that you can use the mediator to do selective routing based on operation type and the passed it to other SCA component or you can use Pick Activity on Message Branch in BPEL to accept request from different wsdl operations.
Thanks for your replies Adam and Abhinav.
So I believe there are two approaches I can take for my solution i.e.
1) Have a mediator as an entry point which will fan out the message to the appropriate SCA component (I want to go for BPEL here as processes are a little chatty).
2) Use BPEL as an entry point with a pick activity and multiple on message branches (one for each operation)
Approach 1 seems to be more cleaner and modular where as going by AIA standards we should have a BPEL component as an entry point into the system (ABCS - Application Business Connector Service).
My confusion is to select the best approach out of these two.
I would say go for Approach 1 as it will give you the ability to do schema validations, transformations, property values assignments and filtering before sending the request further down to other composite components.
But do try to evaluate your design with requirements before deciding !!
Approach 1 indeed seems like the better approach here. Also, to clear your doubt on AIA recommendation of BPEL as entry point into the system as ABCS, the ABCS is verb or operation specific. So as per AIA standards if you have 10 operations then you need to create 10 ReqABCSs each implementing a single BPEL. If you follow this you will have 10 composites and then to fulfill your requirement of a single interface to consumers, you will need to build an Adapter (composite containing mediator) which routes to correct ReqABCS based on operation. So basically AIA also recommends approach similar to approach 1 listed here.
Thanks for your replies, these were really helpful.
Just to add here, we do not have any requirement of schema validation or even transformation at the mediator level (approach 1). The request message will be passed to the BPEL as is, without doing anything to it, this leads to two more concerns here:
1) Approach 1: The mediator component used in this approach is not doing anything just an operation based route to the appropriate BPEL. Is this component redundant ?
2) Approach 2: I believe that this approach is not recommended, so just for understanding purpose I want to know what are the drawbacks involved in this approach. Is pick activity has some performance impact (all the operations in the use case are synchronous) or is there any other reason ?