You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by "Karthick Sankarachary (JIRA)" <ji...@apache.org> on 2008/08/14 03:02:44 UTC
[jira] Created: (ODE-364) Publising a SOAP message to a set of
interested BPEL processes
Publising a SOAP message to a set of interested BPEL processes
--------------------------------------------------------------
Key: ODE-364
URL: https://issues.apache.org/jira/browse/ODE-364
Project: ODE
Issue Type: New Feature
Components: BPEL Runtime
Affects Versions: 1.2
Environment: Platform-Independent
Reporter: Karthick Sankarachary
Fix For: 1.2
By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
This issue speaks as to how to implement such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
In general, there were two paths that need to be considered:
a) Out-Of-Process invocation of the shared service: This follows the path defined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
b) In-Process invocation of the shared service: This follows the path defined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process deregisters from it. Care must be taken though, to remove any older versions of processes in the server's map.
Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-364) Publish/Subscribe across processes
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated ODE-364:
--------------------------------------
Attachment: patch-for-ode-1x.txt
> Publish/Subscribe across processes
> ----------------------------------
>
> Key: ODE-364
> URL: https://issues.apache.org/jira/browse/ODE-364
> Project: ODE
> Issue Type: New Feature
> Components: BPEL Runtime
> Affects Versions: 1.2
> Environment: Platform-Independent
> Reporter: Karthick Sankarachary
> Assignee: Matthieu Riou
> Fix For: 1.3
>
> Attachments: patch-for-ode-1x.txt, patch-for-ode-trunk.txt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
> This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
> In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
> In general, there are two paths that need to be considered:
> a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
> b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
> During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
> Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ODE-364) Publish/Subscribe across processes
Posted by "Matthieu Riou (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matthieu Riou resolved ODE-364.
-------------------------------
Resolution: Fixed
Fix Version/s: (was: 1.2)
1.3
Assignee: Matthieu Riou
Patch applied yesterday on both branches.
> Publish/Subscribe across processes
> ----------------------------------
>
> Key: ODE-364
> URL: https://issues.apache.org/jira/browse/ODE-364
> Project: ODE
> Issue Type: New Feature
> Components: BPEL Runtime
> Affects Versions: 1.2
> Environment: Platform-Independent
> Reporter: Karthick Sankarachary
> Assignee: Matthieu Riou
> Fix For: 1.3
>
> Attachments: patch-for-ode-1x.txt, patch-for-ode-trunk.txt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
> This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
> In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
> In general, there are two paths that need to be considered:
> a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
> b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
> During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
> Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-364) Publishing a SOAP message to a set of
interested BPEL processes
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622714#action_12622714 ]
Karthick Sankarachary commented on ODE-364:
-------------------------------------------
To answer Alex's comments:
1) There was a proposal to add a boolean annotation in the provisioned service listed in the deployment descriptor (specifically, deploy/provide/service/shareable) that would indicate whether or not the endpoint was actually designed for pub-sub semantic. However, I did not get an overwhelming thumbs up for that idea, so it was dropped. I was hoping to enable endpoint sharing if and only if the "shareable" element on the corresponding service is true. Currently, that (hypothetical) attribute is treated as always being set to true.
2) I was assuming that the design-time tooling would ensure that request-response operations are not enabled for pub-sub. However, come to think of it, the engine could very well perform that validation at run-time by introspecting the service (that is about to be shared), and automatically disabling endpoint sharing if even one operation in that service is request-response. Having said that, there might be a use-case where using pub-sub in the context of request-response operations makes sense, particularly if the consumer (requestor) doesn't necessarily care which process provides the response, as long as it gets one (think of it as a distributed OR-Join workflow pattern.) In fact, I suspect that's why I probably wanted to handle request-response gracefully to begin with. In light of that, I suggest extending the "shareable" annotation with a boolean attribute (specifically, deploy/provide/service/shareable/@oneway), which by default would be true, to indicate whether or not to ensure if all operations are one-way. If its false, then the reply sent back to the consumer will be that of one of the subscribing processes.
> Publishing a SOAP message to a set of interested BPEL processes
> ---------------------------------------------------------------
>
> Key: ODE-364
> URL: https://issues.apache.org/jira/browse/ODE-364
> Project: ODE
> Issue Type: New Feature
> Components: BPEL Runtime
> Affects Versions: 1.2
> Environment: Platform-Independent
> Reporter: Karthick Sankarachary
> Fix For: 1.2
>
> Attachments: patch.txt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
> This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
> In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
> In general, there are two paths that need to be considered:
> a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
> b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
> During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
> Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-364) Publishing a SOAP message to a set of
interested BPEL processes
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated ODE-364:
--------------------------------------
Description:
By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
In general, there are two paths that need to be considered:
a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
was:
By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
This issue speaks as to how to implement such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
In general, there were two paths that need to be considered:
a) Out-Of-Process invocation of the shared service: This follows the path defined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
b) In-Process invocation of the shared service: This follows the path defined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process deregisters from it. Care must be taken though, to remove any older versions of processes in the server's map.
Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
Summary: Publishing a SOAP message to a set of interested BPEL processes (was: Publising a SOAP message to a set of interested BPEL processes)
> Publishing a SOAP message to a set of interested BPEL processes
> ---------------------------------------------------------------
>
> Key: ODE-364
> URL: https://issues.apache.org/jira/browse/ODE-364
> Project: ODE
> Issue Type: New Feature
> Components: BPEL Runtime
> Affects Versions: 1.2
> Environment: Platform-Independent
> Reporter: Karthick Sankarachary
> Fix For: 1.2
>
> Attachments: patch.txt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
> This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
> In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
> In general, there are two paths that need to be considered:
> a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
> b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
> During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
> Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-364) Publishing a SOAP message to a set of
interested BPEL processes
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated ODE-364:
--------------------------------------
Attachment: (was: patch.txt)
> Publishing a SOAP message to a set of interested BPEL processes
> ---------------------------------------------------------------
>
> Key: ODE-364
> URL: https://issues.apache.org/jira/browse/ODE-364
> Project: ODE
> Issue Type: New Feature
> Components: BPEL Runtime
> Affects Versions: 1.2
> Environment: Platform-Independent
> Reporter: Karthick Sankarachary
> Fix For: 1.2
>
> Attachments: patch.txt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
> This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
> In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
> In general, there are two paths that need to be considered:
> a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
> b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
> During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
> Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-364) Publish/Subscribe across processes
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated ODE-364:
--------------------------------------
Attachment: patch-for-ode-trunk.txt
> Publish/Subscribe across processes
> ----------------------------------
>
> Key: ODE-364
> URL: https://issues.apache.org/jira/browse/ODE-364
> Project: ODE
> Issue Type: New Feature
> Components: BPEL Runtime
> Affects Versions: 1.2
> Environment: Platform-Independent
> Reporter: Karthick Sankarachary
> Fix For: 1.2
>
> Attachments: patch-for-ode-trunk.txt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
> This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
> In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
> In general, there are two paths that need to be considered:
> a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
> b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
> During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
> Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-364) Publish/Subscribe across processes
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated ODE-364:
--------------------------------------
Attachment: (was: patch.txt)
> Publish/Subscribe across processes
> ----------------------------------
>
> Key: ODE-364
> URL: https://issues.apache.org/jira/browse/ODE-364
> Project: ODE
> Issue Type: New Feature
> Components: BPEL Runtime
> Affects Versions: 1.2
> Environment: Platform-Independent
> Reporter: Karthick Sankarachary
> Fix For: 1.2
>
> Attachments: patch-for-ode-trunk.txt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
> This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
> In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
> In general, there are two paths that need to be considered:
> a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
> b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
> During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
> Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-364) Publish/Subscribe across processes
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated ODE-364:
--------------------------------------
Attachment: (was: patch-for-ode-1x.txt)
> Publish/Subscribe across processes
> ----------------------------------
>
> Key: ODE-364
> URL: https://issues.apache.org/jira/browse/ODE-364
> Project: ODE
> Issue Type: New Feature
> Components: BPEL Runtime
> Affects Versions: 1.2
> Environment: Platform-Independent
> Reporter: Karthick Sankarachary
> Assignee: Matthieu Riou
> Fix For: 1.3
>
> Attachments: patch-for-ode-1x.txt, patch-for-ode-trunk.txt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
> This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
> In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
> In general, there are two paths that need to be considered:
> a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
> b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
> During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
> Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-364) Publishing a SOAP message to a set of
interested BPEL processes
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated ODE-364:
--------------------------------------
Attachment: patch.txt
A revised patch that implements the pub-sub mechanism as initially described, modulo the following rules:
a) A service may be shared by multiple processes, only if their individual deployments explicitly allow it, as shown below:
<deploy ...> ...
<provide ...>
<service ...>
<enableSharing/>
</provide> ...
</deploy>
b) Further, if the port type implemented by a service comprises operations that are request-response in nature, then sharing is disabled, even if their individual deployments say otherwise.
> Publishing a SOAP message to a set of interested BPEL processes
> ---------------------------------------------------------------
>
> Key: ODE-364
> URL: https://issues.apache.org/jira/browse/ODE-364
> Project: ODE
> Issue Type: New Feature
> Components: BPEL Runtime
> Affects Versions: 1.2
> Environment: Platform-Independent
> Reporter: Karthick Sankarachary
> Fix For: 1.2
>
> Attachments: patch.txt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
> This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
> In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
> In general, there are two paths that need to be considered:
> a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
> b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
> During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
> Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-364) Publishing a SOAP message to a set of
interested BPEL processes
Posted by "Alex Boisvert (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622687#action_12622687 ]
Alex Boisvert commented on ODE-364:
-----------------------------------
So if I understand correctly, two things are missing from this patch:
1) Validation to ensure that processes sharing the same endpoint were actually designed for pub-sub semantic. One way to achieve this would be an annotation in the deployment descriptor.
2) Validation to ensure that for processes designed for pub-sub, request-response operation are detected and reported as errors.
> Publishing a SOAP message to a set of interested BPEL processes
> ---------------------------------------------------------------
>
> Key: ODE-364
> URL: https://issues.apache.org/jira/browse/ODE-364
> Project: ODE
> Issue Type: New Feature
> Components: BPEL Runtime
> Affects Versions: 1.2
> Environment: Platform-Independent
> Reporter: Karthick Sankarachary
> Fix For: 1.2
>
> Attachments: patch.txt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
> This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
> In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
> In general, there are two paths that need to be considered:
> a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
> b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
> During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
> Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-364) Publishing a SOAP message to a set of
interested BPEL processes
Posted by "Assaf Arkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622694#action_12622694 ]
Assaf Arkin commented on ODE-364:
---------------------------------
"While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes. "
Deployment artifacts are there for a reason. If I accidentally use the same service in two places, that should be flagged as an error and stop deployment, not result in a hard to diagnose bug. Pub/sub is not the common case, it should be specified explicitly in deployment not applied implicitly as a result of something that might be an error.
"Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way."
If it's a bad idea (and it is), the engine must prevent it from happening by issuing an error. If used, a design-time tool should issue a warning earlier in the lifecycle of the process definition.
> Publishing a SOAP message to a set of interested BPEL processes
> ---------------------------------------------------------------
>
> Key: ODE-364
> URL: https://issues.apache.org/jira/browse/ODE-364
> Project: ODE
> Issue Type: New Feature
> Components: BPEL Runtime
> Affects Versions: 1.2
> Environment: Platform-Independent
> Reporter: Karthick Sankarachary
> Fix For: 1.2
>
> Attachments: patch.txt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
> This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
> In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
> In general, there are two paths that need to be considered:
> a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
> b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
> During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
> Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-364) Publishing a SOAP message to a set of
interested BPEL processes
Posted by "Assaf Arkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622812#action_12622812 ]
Assaf Arkin commented on ODE-364:
---------------------------------
Thumb up for enableSharing. I like that name.
> Publishing a SOAP message to a set of interested BPEL processes
> ---------------------------------------------------------------
>
> Key: ODE-364
> URL: https://issues.apache.org/jira/browse/ODE-364
> Project: ODE
> Issue Type: New Feature
> Components: BPEL Runtime
> Affects Versions: 1.2
> Environment: Platform-Independent
> Reporter: Karthick Sankarachary
> Fix For: 1.2
>
> Attachments: patch.txt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
> This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
> In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
> In general, there are two paths that need to be considered:
> a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
> b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
> During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
> Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-364) Publish/Subscribe across processes
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated ODE-364:
--------------------------------------
Attachment: patch-for-ode-1x.txt
> Publish/Subscribe across processes
> ----------------------------------
>
> Key: ODE-364
> URL: https://issues.apache.org/jira/browse/ODE-364
> Project: ODE
> Issue Type: New Feature
> Components: BPEL Runtime
> Affects Versions: 1.2
> Environment: Platform-Independent
> Reporter: Karthick Sankarachary
> Fix For: 1.2
>
> Attachments: patch-for-ode-1x.txt, patch-for-ode-trunk.txt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
> This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
> In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
> In general, there are two paths that need to be considered:
> a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
> b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
> During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
> Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-364) Publishing a SOAP message to a set of
interested BPEL processes
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated ODE-364:
--------------------------------------
Attachment: (was: patch.txt)
> Publishing a SOAP message to a set of interested BPEL processes
> ---------------------------------------------------------------
>
> Key: ODE-364
> URL: https://issues.apache.org/jira/browse/ODE-364
> Project: ODE
> Issue Type: New Feature
> Components: BPEL Runtime
> Affects Versions: 1.2
> Environment: Platform-Independent
> Reporter: Karthick Sankarachary
> Fix For: 1.2
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
> This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
> In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
> In general, there are two paths that need to be considered:
> a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
> b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
> During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
> Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-364) Publishing a SOAP message to a set of
interested BPEL processes
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated ODE-364:
--------------------------------------
Attachment: (was: patch.txt)
> Publishing a SOAP message to a set of interested BPEL processes
> ---------------------------------------------------------------
>
> Key: ODE-364
> URL: https://issues.apache.org/jira/browse/ODE-364
> Project: ODE
> Issue Type: New Feature
> Components: BPEL Runtime
> Affects Versions: 1.2
> Environment: Platform-Independent
> Reporter: Karthick Sankarachary
> Fix For: 1.2
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
> This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
> In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
> In general, there are two paths that need to be considered:
> a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
> b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
> During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
> Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-364) Publishing a SOAP message to a set of
interested BPEL processes
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated ODE-364:
--------------------------------------
Attachment: patch.txt
Patch For Enabling Pub-Sub
> Publishing a SOAP message to a set of interested BPEL processes
> ---------------------------------------------------------------
>
> Key: ODE-364
> URL: https://issues.apache.org/jira/browse/ODE-364
> Project: ODE
> Issue Type: New Feature
> Components: BPEL Runtime
> Affects Versions: 1.2
> Environment: Platform-Independent
> Reporter: Karthick Sankarachary
> Fix For: 1.2
>
> Attachments: patch.txt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
> This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
> In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
> In general, there are two paths that need to be considered:
> a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
> b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
> During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
> Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-364) Publishing a SOAP message to a set of
interested BPEL processes
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated ODE-364:
--------------------------------------
Attachment: patch.txt
> Publishing a SOAP message to a set of interested BPEL processes
> ---------------------------------------------------------------
>
> Key: ODE-364
> URL: https://issues.apache.org/jira/browse/ODE-364
> Project: ODE
> Issue Type: New Feature
> Components: BPEL Runtime
> Affects Versions: 1.2
> Environment: Platform-Independent
> Reporter: Karthick Sankarachary
> Fix For: 1.2
>
> Attachments: patch.txt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
> This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
> In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
> In general, there are two paths that need to be considered:
> a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
> b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
> During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
> Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-364) Publish/Subscribe across processes
Posted by "Alex Boisvert (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alex Boisvert updated ODE-364:
------------------------------
Summary: Publish/Subscribe across processes (was: Publishing a SOAP message to a set of interested BPEL processes)
> Publish/Subscribe across processes
> ----------------------------------
>
> Key: ODE-364
> URL: https://issues.apache.org/jira/browse/ODE-364
> Project: ODE
> Issue Type: New Feature
> Components: BPEL Runtime
> Affects Versions: 1.2
> Environment: Platform-Independent
> Reporter: Karthick Sankarachary
> Fix For: 1.2
>
> Attachments: patch.txt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
> This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
> In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
> In general, there are two paths that need to be considered:
> a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
> b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
> During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
> Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ODE-364) Publishing a SOAP message to a set of
interested BPEL processes
Posted by "Assaf Arkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622719#action_12622719 ]
Assaf Arkin commented on ODE-364:
---------------------------------
"Having said that, there might be a use-case where ..."
No need to guess. If you don't handle it and someone has that particular use case, they'll let you know.
> Publishing a SOAP message to a set of interested BPEL processes
> ---------------------------------------------------------------
>
> Key: ODE-364
> URL: https://issues.apache.org/jira/browse/ODE-364
> Project: ODE
> Issue Type: New Feature
> Components: BPEL Runtime
> Affects Versions: 1.2
> Environment: Platform-Independent
> Reporter: Karthick Sankarachary
> Fix For: 1.2
>
> Attachments: patch.txt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
> This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
> In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
> In general, there are two paths that need to be considered:
> a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
> b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
> During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
> Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ODE-364) Publising a SOAP message to a set of
interested BPEL processes
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Karthick Sankarachary updated ODE-364:
--------------------------------------
Attachment: patch.txt
Diff of Publish-Subscribe Feature.
> Publising a SOAP message to a set of interested BPEL processes
> --------------------------------------------------------------
>
> Key: ODE-364
> URL: https://issues.apache.org/jira/browse/ODE-364
> Project: ODE
> Issue Type: New Feature
> Components: BPEL Runtime
> Affects Versions: 1.2
> Environment: Platform-Independent
> Reporter: Karthick Sankarachary
> Fix For: 1.2
>
> Attachments: patch.txt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
> This issue speaks as to how to implement such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
> In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
> In general, there were two paths that need to be considered:
> a) Out-Of-Process invocation of the shared service: This follows the path defined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
> b) In-Process invocation of the shared service: This follows the path defined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
> During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process deregisters from it. Care must be taken though, to remove any older versions of processes in the server's map.
> Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ODE-364) Publishing a SOAP message to
a set of interested BPEL processes
Posted by "Karthick Sankarachary (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ODE-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12622801#action_12622801 ]
karthick edited comment on ODE-364 at 8/14/08 9:04 PM:
--------------------------------------------------------------------
The revised patch now implements the pub-sub mechanism as initially described, modulo the following rules:
a) A service may be shared by multiple processes, only if their individual deployments explicitly allow it, as shown below:
<deploy ...> ...
<provide ...>
<service ...>
<enableSharing/>
</provide> ...
</deploy>
b) Further, if the port type implemented by a service comprises operations that are request-response in nature, then sharing is disabled, even if their individual deployments say otherwise.
was (Author: karthick):
A revised patch that implements the pub-sub mechanism as initially described, modulo the following rules:
a) A service may be shared by multiple processes, only if their individual deployments explicitly allow it, as shown below:
<deploy ...> ...
<provide ...>
<service ...>
<enableSharing/>
</provide> ...
</deploy>
b) Further, if the port type implemented by a service comprises operations that are request-response in nature, then sharing is disabled, even if their individual deployments say otherwise.
> Publishing a SOAP message to a set of interested BPEL processes
> ---------------------------------------------------------------
>
> Key: ODE-364
> URL: https://issues.apache.org/jira/browse/ODE-364
> Project: ODE
> Issue Type: New Feature
> Components: BPEL Runtime
> Affects Versions: 1.2
> Environment: Platform-Independent
> Reporter: Karthick Sankarachary
> Fix For: 1.2
>
> Attachments: patch.txt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> By default, a SOAP request is targeted at a specific BPEL process in ODE. At times, though, one might want to publish the request simultaneously to multiple BPEL processes, especially if the invocations are one-way.
> This issue describes an implementation of such a feature in the BPEL runtime, in a way that is agnostic of the integration layer and transport bindings.
> In order to facilitate message publishing, processes must have a way to subscribe to messages. While there are many ways to register subscriptions, we chose a implicit mechanism of subscription, wherein no new deployment artifacts are required. In our approach, if two or more processes provide the same (i.e., shared) service, messages targeted at the endpoint of that service will essentially fan out to each of those (subscribing) processes.
> In general, there are two paths that need to be considered:
> a) Out-Of-Process invocation of the shared service: This follows the path outlined in the BpelServer.createMessageExchange() method. For shared services, we create a new kind of Brokered MEX that clones and pushes the message to each of the "subscribing" process.
> b) In-Process invocation of the shared service: This follows the path outlined in the BpelProcess.invokePartner() method, which bypasses the MEXs and creates the MEXDAOs directly. Again, we clone and push the message to each "subscribing" process.
> During registration, services will now be associated with a list of processes that provide it, which could potentially be of any size. The endpoint is physically activated with the integration layer when the first process registers on it, and is physically deactivated when the last process de-registers from it. Care must be taken though, to remove any older versions of processes in the server's map.
> Also, in order to handle two-way pub-subs gracefully, we take the response from one of the processes and return that to the end-consumer. Ideally, the design-time tooling should take care to prevent pub-sub across any services whose operations are not one-way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.