Architectural Issues with AIA Asynchronous MEP

Question

Hi,
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
ABCSRequester1
<--> EBS <--> ABCSProvider1
ABCSRequester2
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.

Answer 1

Hello,
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.
Ravi