[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]