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 2009/04/17 22:22:15 UTC

[jira] Closed: (ODE-450) Expose Deployment Properties In BPEL Process

     [ https://issues.apache.org/jira/browse/ODE-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Karthick Sankarachary closed ODE-450.
-------------------------------------


> Expose Deployment Properties In BPEL Process
> --------------------------------------------
>
>                 Key: ODE-450
>                 URL: https://issues.apache.org/jira/browse/ODE-450
>             Project: ODE
>          Issue Type: New Feature
>          Components: BPEL Compilation/Parsing, BPEL Runtime
>    Affects Versions: 1.2
>         Environment: platform-independent
>            Reporter: Karthick Sankarachary
>            Assignee: Karthick Sankarachary
>             Fix For: 1.3.1
>
>         Attachments: expose-process-properties-for-branch.patch, expose-process-properties-for-trunk.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> Often times, one would like to be able to assert some influence over the runtime behavior of a BPEL process even though it is "code-complete". As of now, we externalize certain process properties and wirings in a deployment descriptor known as deploy.xml. However, we stop short of exposing those properties in the BPEL process, which is a known limitation.
> What we need is a mechanism to reference properties, which are defined at deploy-time, directly in the BPEL process. To that end, we define a new extension XPath function that returns the node value corresponding to the qualified name of a process property, as shown below:
>     ode:process-property($name as item() ) as node()
> where $name refers to any schema item that resolves to a QName, and
>              the return node value is the child of the property element with the given name.
> Let us consider a scenario where a BPEL process invokes an external WSDL service, whose location is not know a priori. The best way to handle this is to define the endpoint reference (EPR) of that service at deploy-time as a process property. In the BPEL process itself, we reference the EPR property and assign it dynamically to the partner link corresponding to that service. For example, the snippet of deploy.xml below declares a process called "tns:negotiate", which is given a property called "auctionEpr" whose value is set to a BPEL <service-ref> element.
>     <deploy xmlns="http://www.apache.org/ode/schemas/dd/2007/03"
>                    xmlns:tns="http://ode/bpel/process">
>        <process name="tns:negotiate">
>            <property name="auctionEpr">
>             <sref:service-ref 
>                 xmlns:sref=" http://docs.oasis-open.org/wsbpel/2.0/serviceref"
>                 xmlns:addr="http://example.com/addressing"
>                 xmlns:as="http://example.com/auction/wsdl/auctionService/">
>                 <addr:EndpointReference>
>                     <addr:Address>http://example.com/auction/RegistrationService</addr:Address>
>                     <addr:ServiceName>as:RegistrationService</addr:ServiceName>
>                 </addr:EndpointReference>
>             </sref:service-ref>
>           </property>...
>         </process>
>     </deploy>
> In the BPEL code, the dynamic assignment of the auction service partner link boils down to this statement:
>     <assign>
>          <copy>
>             <from>ode:process-property("auctionEpr")</from>
>             <to partnerLink="auctionRegistrationService" />
>          </copy>
>     </assign>

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.