RE: [ebxml-cppa] Use of "action" to link to actual java processor

["David RR Webber \(XML\)" <david@drrw.info>]

Sacha,

 

I guess the trend is toward pluggable devices - and the ebMS just is one such.  As we integrate more into the BPSS / ebMS layer - then we see that the BSI layer between these is more exposed.  The BPSS wants to have more control and steering over the ebMS.  Signals is one obvious area.  And now the BPSS has ability to define context variables - then the CPA may need to react differently knowing the BPSS scenario and state of an interaction.  Sure - these are again parameters that can be inspected and java code written to react to those without putting it in the CPA necessarily.

 

In our case - its a simple need to be able to provide a partner with the ebMS device - and just have them quickly configure it.  The less configuration files they have to fiddle with the better!  We're trying to get to one-stop-shopping - where they can change just a few things to get at the major configuration.  We'll work on having just one config file and the CPA!

 

Thanks,

 

DW

-------- Original Message --------
Subject: RE: [ebxml-cppa] Use of "action" to link to actual java
processor
From: Sacha Schlegel <sschlegel@cyclonecommerce.com>
Date: Tue, April 11, 2006 2:58 pm
To: "David RR Webber (XML)" <david@drrw.info>
Cc: ebxml-cppa@lists.oasis-open.org

David

On Tue, 2006-04-11 at 11:43 -0700, David RR Webber (XML) wrote:
> Sacha,
>  
> OK - good clarification - yes - we need that behaviour of action to
> validate if that partner is allowed to perform that action with us!
> So I cannot trample on that!
>  
> I was hoping to avoid having yet-another-configuration-file that
> associates between the payload types and the data handler - would be
> nice if that was somehow something the CPA allowed.

I understand but then again ebXML is just what is happening between the
two B's in B2B. How each B does handle the payload is the B's decision.
If you want to give B a hint by setting it in the CPA ... yes but I
think that is not so nice.

>  
> I guess if you want to use web services a la Hermes 2 - you can set a
> delivery channel to pipe the XML content into from the ebXML delivery
> frontend.. but that's another whole discussion.
>
> Then again I could overload this parameter - make it both what is in
> the ebMS header action - and - with say a prefix - like {exec_} use
> that to call the equivalent handler... e.g. call
> (exec_my_data_handler);

Actually my take is that the messaging system (ebMS) should set in the
ebMS message action whatever was set in the agreed CPA in the first
place, if the parties use CPA's.


Sacha

>  
> OK - this is then de-referenced nicely.  Does that sound more useable?
>  
> Thanks, DW
>
>
>         -------- Original Message --------
>         Subject: Re: [ebxml-cppa] Use of "action" to link to actual
>         java
>         processor
>         From: Sacha Schlegel <sschlegel@cyclonecommerce.com>
>         Date: Tue, April 11, 2006 2:31 pm
>         To: "David RR Webber (XML)" <david@drrw.info>
>         Cc: ebxml-cppa@lists.oasis-open.org
>        
>         Hi David
>        
>         In 8.4.12.1 "action attribute" of the 2.0 CPPA spec:
>         ---
>        
>         The value of the REQUIRED action attribute is a string that
>         identifies
>         the business document
>         exchange to be associated with the DeliveryChannel identified
>         by the
>         ChannelId sub-elements.
>         The value of the action attribute SHALL be used as the value
>         of the
>         Action element in the
>         ebXML Message Header[ebMS] or a similar element in the Message
>         Header of
>         an alternative
>         message service. The purpose of the action attribute is to
>         provide a
>         mapping between the
>         hierarchical naming associated with a Business
>         Process/Application and
>         the Action element in
>         the ebXML Message Header[ebMS]. This mapping MAY be
>         implemented by using
>         the
>         ActionContext element. See NOTE in Section 8.4.4 regarding
>         alternative
>         Business
>         Collaboration descriptions.
>         Business signals, when sent individually (i.e., not bundled
>         with
>         response documents in
>         synchronous reply mode), SHALL use the values
>         ReceiptAcknowledgment,
>         AcceptanceAcknowledgment, or Exception as the value of their
>         action
>         attribute. In addition, they
>         SHOULD specify a Service that is the same as the Service used
>         for the
>         original message.
>        
>          NOTE: In general, the action name chosen by the two Parties
>         to
>         represent a particular
>          requesting business activity or responding business activity
>         in the
>         context of a Binary
>          Collaboration that makes use of nested BinaryCollaborations
>         MAY not be
>         identical.
>          Therefore, when composing two CPPs to form a CPA, it is
>         necessary to
>         make use of
>          information from the associated ActionContext (see Section
>         8.4.16) in
>         order to determine
>          if two different action names from the two CPPs actually
>         represent the
>         same
>          ActionContext. When business transactions are not reused in
>         different
>         contexts, it is
>          recommended that the names of the requesting business
>         activity and
>         responding business
>          activity be used as action names.
>        
>         ---
>        
>         So I would not choose to set the action to something that is
>         particular
>         to one party but have the value clearly come from the
>         referenced Process
>         Specification. The formula I used for the UBP was (XPath):
>        
>         conncat( $RequestingOrRespondingName, '
>         ', //ebBP:BusinessDocument[@nameID=
>         $BusinessDocumentReference]/@name)
>        
>         where $RequestingOrRespondingName is coming from the
>         BusinessTransactionActivity of that BusinessCollaboration and
>         the second
>         part is name of the business document.
>        
>         I understand what you are trying to do but ... cant you have
>         that
>         mapping outside of the CPA?
>        
>         Of course you are free to use your Java method reference, as
>         long as
>         both parties agree to it.
>        
>         Regards
>        
>         Sacha
>        
>         On Tue, 2006-04-11 at 10:14 -0700, David RR Webber (XML)
>         wrote:
>         > Team,
>         >  
>         > I'm doing integration right now using Hermes - and I wanted
>         to have a
>         > way of controlling the processing of message types directly
>         from the
>         > CPA - to the java handler that processes the content.
>         >  
>         > It occurs to me I could extend the use of the tp:action
>         attribute in
>         > the action binding to be the actual name of the java handler
>         - since
>         > its just text anyway - the the two can be equivalent - e.g.
>         human
>         > readable - machine executable.
>         >  
>         > What do people think here?  Is this total blasphemy - or is
>         this
>         > acceptable extension?  Or is there a better way of doing
>         this
>         > elsewhere in the CPA?
>         >  
>         > Given that the CPA is private this is something that two
>         participants
>         > can share - and especially if they are sharing open source
>         such as
>         > Hermes.
>         >  
>         > Thanks, DW
>         >  
>         > Encl: example CPA fragment -
>         >  
>         >       <tp:CanSend>
>         >           <tp:ThisPartyActionBinding tp:id="companyA_ABID1"
>         >             tp:action="Purchase_Order_Request_Action()"
>         >             tp:packageId="CompanyA_Packaging">
>         >             <tp:ChannelId>asyncChannelA1</tp:ChannelId>
>         >           </tp:ThisPartyActionBinding>
>         >           <tp:OtherPartyActionBinding>
>         >             companyB_ABID1
>         >           </tp:OtherPartyActionBinding>
>         >         </tp:CanSend>
>         >         <tp:CanReceive>
>         >           <tp:ThisPartyActionBinding tp:id="companyA_ABID7"
>         >             tp:action="Purchase_Order_Confirmation_Action()"
>         >             tp:packageId="CompanyA_Packaging">
>         >           ...
>         >         </tp:CanReceive>
>         >
>         >
>         ---------------------------------------------------------------------
>         > To unsubscribe from this mail list, you must leave the OASIS
>         TC that
>         > generates this mail. You may a link to this group and all
>         your TCs in
>         > OASIS at:
>         >
>         https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php