We are implementing an AIA service which should follow an Asynchronous (request/delayed-response) MEP. I need some advice from people who have implemented this pattern.
The rough requirements are that we have two ABCS Requesters for two different systems, which read from files and call the EBS (eventually there may be an EBF involved as well but don't want to confuse the question). The response for the operation will take up to 10 minutes but we need to deal with the response when it comes back at the requester level.
It looks something like this
<--> EBS <--> ABCSProvider1
My question is, why does AIA only create a single port service in ABCS Provider and it forces me to call back via a seperate WSDL when I select the request/delayed-response option in he service constructor.
This means that I must have two EBS services (one EBS Request and one EBS Response) - unless I am missing something (which is entirely possible) and dynamically route the response to the appropriate endpoint and then correlate it.
I understand this is possible, but it seems an overkill to me when I could have two ports on the Provider ABCS wsdl (which the service constructor does not create), which I could then callback on and the EBS will then create a callback to the calling client. This would make the whole process easier to manage IMO.
I could change the generated WSDL and add a callback port, but as the service constructor generates the ABCS like this, I do not want to just alter this without understanding maybe why I shouldn't.
Do people recommend the Fire and Forget Async MEP as seems to be documented in AIA documentation for a scenario like this and if so why?
Have people implemented the two port single WSDL solution (as is created by SOA Suite if you build a service as Async from scratch) as an AIA provider?
If anybody has a sample Async project in AIA showing this sort of scenario, I would love to see it.
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