This content has been marked as final. Show 3 replies
Hi,1 person found this helpful
My experience with the service constructor is that it only gives you a starting point and the composite including wsdls need to be finished off.
For request/delayed response we have always tried to develop two seperate transient ABCS's. This works much better from a maintance point of view.
Your requirment may mean that you do need to have a non-transient ABCS to cope with the response but you should consider wether it is possible to include all the data needed to process the response in the message and have it returned to a seperat ABCS. If your target app supports this you will remove the need to have non-transient components which will make the system much more robust.
For the EBS Services we develop a single composite but have two services inside that composite, one for the request and the other for the response.
Provider ABCS does not need to have 2 port types for this scenario. You would have 2 port types in Provider ABCS only if it interacts with provider application in an asynchronous manner. In that situation, provider application will be sending the callback response by invoking the service operation defined in the callback response port type within provider ABCS.
Your question is more about why we need to have 2 EBS - one for processing request and another for processing callback response. For this situation, you do not have to add additional port type in provider ABCS WSDL.
You can certainly leverage the mediator’s call back facility to eliminate the Response EBS that is normally recommended for processing the callback. 11g mediator does have the support and you can leverage that.
We did look at this feature during the 11g adoption and decided not to leverage this feature after prototyping for the following reasons:
1. EBS Operations need to support fire-and-forget as well as asynchronous delayed response MEPs. We had to support this functionality of Requester ABCS at run time indicating in the EBM whether it needs the response or not. EBS.Operation would be invoked by both fire-and-forget and asynchronous delayed response MEP requesters; and for the delayed responses, ResponseEBS.Operation would be used. Hardwiring the MEP at the EBS Operation level would lead us to create 2 operations – one for fire-and-forget and another for asynchronous delayed response
2. This stateless programming model allows us to be OSB-friendly
3. To be backwardly compatible with 2.x services
Any custom solution built by you can certainly leverage the 11g Mediator's callback facility provided your requester ABCS is coded always to receive a callback from EBS. You could certainly leverage this pattern if you dont have a need for Requester ABCS to invoke EBS using fire-and-forget pattern.
Thanks for the responses. I suppose to put it into context, I have no problem with AIA Async services 'per se' and understand that the documentented method works and achieves what is required.
Ravi, you made it very clear why the decision was made and I undertand that now, I was really trying to understand the 'why' as opposed to the how ( although to see a 'pure' example would have helped :-) ), so this helps me.
I had read through the documententation and had seen some examples where the requester to provider is fire and forget and depending on a message parameter, it will either fire off a callback or not. There is a seperate EBS for the response objects, and this will then callback to a requester and correlate the response (or potentially a dynamic endpoint from the EBS). I was interested in why this approach was being taken as I prefer to have any 'callbacks' within the same wsdl as the request service. I can use the WS-Addressing 'Reply To' parameter to enable clients to request a callback. I suppose I was just a little bit unsure of this as this would leave an EBS potentially exposing calls to an ABCS Requester or a Provider calling a provider on the return leg.
It is really just understanding why AIA does certain things in some ways and if there are any technical reasons why we should strictly adhere to a pattern (i.e. the Async MEP) or if we can adjust depending on our requirements.
Thanks again for the reples though, as it has helped a lot in clarifying the situation and I will now mark this thread as solved.
Edited by: rodhiggins on 29-Jul-2012 17:33