ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karthick Sankarachary (JIRA)" <j...@apache.org>
Subject [jira] Updated: (ODE-450) Expose Deployment Properties In BPEL Process
Date Fri, 12 Dec 2008 00:35:44 GMT

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

Karthick Sankarachary updated ODE-450:

    Attachment: expose-process-properties-for-trunk.patch

> 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
>         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
> 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>
>     <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.

View raw message