[ http://issues.apache.org/jira/browse/ODE-33?page=comments#action_12428711 ] Alex Boisvert commented on ODE-33: ----------------------------------
As a matter of architecture, it's usually better to pass EPRs that are universally accessible (e.g. HTTP endpoints) over EPRs that are limited to specific environments (e.g. JBI endpoints) because you never know how far the EPRs will travel in a service composition architecture, or who's going to receive your EPRs. Put another way, I would see it as a responsibility of the JBI container or binding components to optimize invocations whenever possible by recognizing that connection paths are available in-VM or through more efficient transports. Plus, it avoids all kind of problems on the sender side such as having to decide which EPR or endpoint to send to another service. > Obtaining the "initial" EPR for a partner link should be done as lazyly as > possible. > ------------------------------------------------------------------------------------ > > Key: ODE-33 > URL: http://issues.apache.org/jira/browse/ODE-33 > Project: Apache Ode > Issue Type: Bug > Components: BPEL Runtime > Environment: JBI > Reporter: Maciej Szefler > > At the moment, the initial EPR assigned to a partner link is resolved at the > time when the process is instantiated in memory (i.e. registered with the > BpelEngineImpl). This does not work in the JBI setting where the > getExternalEndpoint method is used to obtain an EPR that a partner could > understand. The problem is that the Service Unit that exposes the external > endpoint may not have been started by the time the BPEL process service unit > is started. If this happens then the initial EPR cannot be correctly > configured. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
