OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: FW: Regarding ebBP resuing ebBP packages


I neglected sending this response to the list that may be of interest to
those designing business process libraries covering large message sets.

Still fiddling with the full check in Oxygen of the xinclude bit, but
the rest is OK.

Dale Moberg

-----Original Message-----
From: Dale Moberg 
Sent: Monday, April 23, 2007 10:50 AM
To: 'stephen.green@systml.co.uk'; Sacha Schlegel; Monica J. Martin
Subject: RE: Regarding ebBP resuing ebBP packages

I checked using Oxygen 7.x

(You have to turn on xinclude support. Not on by default.)

Anyhow, here is what seems to work:

1. Put all the signals inside a Package.

2. Put the xinclude for the entire package in a place that packages can
go.
(There are places where packages cannot be inserted. For example, before


<xsd:element ref="Documentation" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element ref="AttributeSubstitution" minOccurs="0"
maxOccurs="unbounded"/>

<xsd:element ref="ExternalRoles" minOccurs="0"/>

<xsd:element ref="Signal" minOccurs="0" maxOccurs="unbounded"/>

<xsd:element ref="Variable" minOccurs="0" maxOccurs="unbounded"/>) 

So check that if you use the above elements "at the front" of the
ProcessSpecification, that you have the xinclude instruction, after
these elements. 

The upshot is that signals when included in a package and inserted will
not occur in the same spot as when they are just in the
ProcessSpecification at toplevel.


3. Reference the signals by id as needed. Remember IDREFs can jump right
into a package and make connection to the intended xml node. 

-----Original Message-----
From: stephen.green@systml.co.uk [mailto:stephen.green@systml.co.uk] 
Sent: Monday, April 23, 2007 10:24 AM
To: Dale Moberg; Sacha Schlegel; Monica J. Martin
Subject: RE: Regarding ebBP resuing ebBP packages

Hi All,

I'd got the impression that it might not be possible to
include signals since I thought that signals couldn't
be children or descendants of 'Package'. Is that not a
problem then? I'll try to recollect whther there were
other issues too.

All the best

Steve


Quoting Dale Moberg <dmoberg@us.axway.com>:

> Sacha S. writes:
>
> I had another look at the ebBP Steve has done ... the one listed on
the
> ebBP site (and attached to this email) demonstrating the use of
reusing
> ebBP packages.
>
> I think we could put all ebBP signals into a separate package
(separate
> file) for reuse.
>
> Dale>> I think a sample signals package file for the default signals
> should be included in one of the zip files.
>
> Whether all signals will be used in the target package is probably no
> big issue,
> This would eliminate the copying Steve mentioned in the comment. I
would
> need to double check the scoping rules but I guess it would be OK.
>
> Dale>> I think we recommended (possibly required) that imports import
> entire packages. So place the xi:include instructions where packages
can
> be inserted.
>
>  The BusinessDocuments
> we could also xinlcude ... I would think with something like
> <xi:include href=...
> xpointer="xpointer(/ProcessSpecification/BusinessDocument) we would
get
> all BusinessDocuments from the included ProcessSpecification.
>
> Dale>> Well, we were going to insert xml chunks by complete packages.
> The motive for doing this was, I think, that there would be less
> likelihood of garbage inserts. Also recall that tooling has been slow
to
> support the xpointer scheme itself. Using the "element" scheme inside
> the xpointer syntax might be more widely supported. That means that
you
> might consider pointing at a specific Package element in your xpath...
>
> What I realise is that in the new (custom) business collaboration we
do
> not reuse the business collaborations but just the business
transactions
> from the included packages.
>
> Dale>> Not sure why we could not reuse business collaborations? Put
them
> into a package, xinclude them, and then reference them within a
> CollaborationActivity. Why would that not work for your use cases? You
> will need to rebind the Role values, of course. But that is part of
the
> CollaborationActivity functionality.
>
>
>
> Would it make sense to reuse complete Business Collaborations and to
> reference them like a business transaction activity in a business
> collaboration?
>
> Dale>> I am not sure I understand. CollaborationActivity should be a
> supported way to do this.
>
> This would mean that the ToLink element inside the Start element as
well
>
> as the FromLink, ToLink of Transition (and other constructs using
those
> Linking elements) would need to allow the reference of business
> collaborations
> instead of simply business transaction activities. A business
> collaboration
> will always have a final state (success or failure) so we can use
those
> states for transitions to further Business Collaborations or BTA's.
Such
> a
> reference to a business collaboration would need need Performs
elements.
>
> Is this completely off? Against some common understanding of ebBP?
>
> Dale>> Check on the CollaborationActivity. See whether it has enough
> functionality to do what you are envisioning. I may not understand the
> problem you are facing correctly so please follow up if there needs to
> be something else done. There is a lot of support for reuse and
library
> design in version 2.0.
>
> Regards
>
> Sacha
>
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]