[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-cppa] Re: [ebxml-iic] Simple trading partner configurationfor ebMS
Marty, The 'what do you leave out' question is precisely the reason I came up with the idea of a) writing my own TPA schema, or b) adding "profiles" to CPP/A. As for profiles, maybe we should start by defining what a couple of them might be. Forget about the minOccurs problems for the moment -- there are ways to work around that. Profile A: Standard CPA (done!) Profile B: Simple ebXML Messaging (ala Simple TPA) Profile B1: Simple ebXML Messaging + multiple delivery channels per party. more?... -Matt On Monday, Aug 26, 2002, at 13:51 America/Vancouver, Martin W Sachs wrote: > > > > > > Someone please post this to ebxml-iic; I have been unable to set up a > subscription as of now. > > Does anyone have one of the CPAs there were used in the 5/01 POC? They > would be pretty minimal though not conformant to CPPA V2. > > The problem with a minimal CPA is, who decides what to leave out? > That's > where you run into differences among customer sets etc. > > You can generate a minimal CPA by taking the CPA example in the CPPA > spec > and leaving out all the packaging and security elements. If you want > it to > specify minimal messaging, also leave out all the child elements of > ebXMLSenderBinding and ebXMLReceiverBinding and set the attributes of > MessagingCharacteristics to turn off all the messaging options. The > resulting CPA will provide for messaging just barely above the level of > functionality of SOAP and with no security. As far as the elements > related > to BPSS are concerned, this example is for PIP3A4. I don't think you > can > get too much simpler than that. The result should be CPPA conformant > thought it might take some tweaking to get it to validate against the > CPPA > schema. > > Regards, > Marty > > *********************************************************************** > ************** > > Martin W. Sachs > IBM T. J. Watson Research Center > P. O. B. 704 > Yorktown Hts, NY 10598 > 914-784-7287; IBM tie line 863-7287 > Notes address: Martin W Sachs/Watson/IBM > Internet address: mwsachs @ us.ibm.com > *********************************************************************** > ************** > > > > Matthew MacKenzie > <matt@xmlglobal. To: Martin W > Sachs/Watson/IBM@IBMUS > com> cc: Dale Moberg > <dmoberg@cyclonecommerce.com>, "Cppalist (E-mail)" > > <ebxml-cppa@lists.oasis-open.org>, ebxml-iic@lists.oasis-open.org > 08/26/2002 04:25 Subject: Re: > [ebxml-cppa] Re: [ebxml-iic] Simple trading partner > PM configuration for ebMS > > > > > > > Marty, > > Do you have a minimal CPA example handy? > > -Matt > > On Monday, Aug 26, 2002, at 05:57 America/Vancouver, Martin W Sachs > wrote: > >> >> >> >> >> >> Matt, >> >> Your suggestion would work. My only concern is that the subset >> schemas >> would not be conformant with the CPPA specification if they omitted >> elements or attributes that have minOccurs greater than zero. >> >> My suggestion for the subset profiles was to define "prototype" CPAs >> that >> omit what is not needed and has minOccurs="0", and have values already >> filled in that are not to be changed. The schema would remain the >> approved >> CPPA schema. Using separate namespaces is a good idea. >> >> These subset CPAs would be CPA templates that also would conform to >> the >> future automated negotiation specification. As with any CPA template, >> the >> subset CPA templates could be described by the automated-negotiation >> Negotiation Descriptor Document to show what elements and attributes >> are >> modifiable. So, doing it the way I described would also be conformant >> with >> the automated negotiation specification when it is approved. This >> would >> also facilitate using a CPA composition tool to compose the subset >> CPAs. >> >> Regards, >> Marty >> >> ********************************************************************** >> * >> ************** >> >> Martin W. Sachs >> IBM T. J. Watson Research Center >> P. O. B. 704 >> Yorktown Hts, NY 10598 >> 914-784-7287; IBM tie line 863-7287 >> Notes address: Martin W Sachs/Watson/IBM >> Internet address: mwsachs @ us.ibm.com >> ********************************************************************** >> * >> ************** >> >> >> >> Matthew MacKenzie >> <matt@xmlglobal. To: Martin W >> Sachs/Watson/IBM@IBMUS >> com> cc: Dale Moberg >> <dmoberg@cyclonecommerce.com>, "Cppalist (E-mail)" >> >> <ebxml-cppa@lists.oasis-open.org>, ebxml-iic@lists.oasis-open.org >> 08/25/2002 10:23 Subject: Re: >> [ebxml-cppa] Re: [ebxml-iic] Simple trading partner >> PM configuration for ebMS >> >> >> >> >> >> >> Marty, >> >> Your comments are right on the money. I don't really want to start >> flooding the world with more standards, but I really want to see a >> simple and short TPA in the spirit of the schema I just sent out. The >> "profile" concept is interesting. I would like to see a set of >> profiles in the form of a few schemas which use the core CPPA schema >> as >> a type library. Each schema would have a slightly different >> namespace, >> so that a CPPA implementation would be able to understand which >> profile >> is in use. >> >> Does that jive with what you were thinking? >> >> Cheers, >> >> Matt >> >> On Sunday, August 25, 2002, at 12:43 PM, Martin W Sachs wrote: >> >>> >>> >>> >>> >>> >>> Matt, >>> >>> Thanks for the proposal. I'm sure that the team will give it serious >>> attention. >>> >>> I have a concerrn that publishing a normative subset schema may >>> confuse >>> more than it will help. It is not clear that only one subset schema >>> would >>> be sufficient. I have the following thoughts. >>> >>> What may be the right subset schema for your customer set is not >>> necessarily the right one for other customer sets. Another approach, >>> which >>> has worked well in other feature-rich standards, is to define one or >>> more >>> "CPPA Profiles" that apply to different customer sets, industry >>> verticals, >>> etc. Such a profile defines those features that enterprises in a >>> given >>> "sub-industry" must support. It can specify values for those >>> elements >>> and >>> attributes are the same in every CPP or CPA in the group and list >>> those >>> features whose cardinality includes minOccurs="0" that are not to be >>> used. >>> Each profile would include CPP and CPA Templates (a prototype of the >>> subset >>> CPP or CPA) that expose the required features and leave out >>> everything >>> not >>> needed whose cardinality includes minOccurs="0". These profiles could >>> be >>> developed by the appropriate industry groupings, coordinating with >>> the >>> CPPA >>> team. The could be published either by the individual groupings or by >>> OASIS >>> as technical reports. With this approach, there is no need to have >>> subset >>> schemas since the subset CPPs and CPAs would validate against the >>> standard >>> CPPA schema. Also, by not omitting CPPA elements and attributes whose >>> cardinality is greater than zero, standard CPA deployment tools and >>> run- >>> time middleware would be able to handle the subset CPAs. >>> >>> A CPP-CPA composition tool could be designed to be tailored for >>> profiles >>> and to show the CPP or CPA author minimal complexity. Its GUI would >>> present to the author only those elements and attributes that require >>> decisions for the selected profile. Elements and attributes of >>> cardinality >>> minOccurs="0" that the profile defines as absent would not be shown >>> to >>> the >>> author. Also, elements and attributes whose values are fixed by the >>> profile would not be shown to the author. The tool could also include >>> a >>> feature to be used for defining new profiles. Profile support should >>> be a >>> good value-added opportunity for CPPA tool vendors. >>> >>> Regards, >>> Marty >>> >>> >>> >>> ********************************************************************* >>> * >>> * >>> ************** >>> >>> Martin W. Sachs >>> IBM T. J. Watson Research Center >>> P. O. B. 704 >>> Yorktown Hts, NY 10598 >>> 914-784-7287; IBM tie line 863-7287 >>> Notes address: Martin W Sachs/Watson/IBM >>> Internet address: mwsachs @ us.ibm.com >>> ********************************************************************* >>> * >>> * >>> ************** >>> >>> >>> >>> Matthew MacKenzie >>> <matt@xmlglobal. To: Dale Moberg >>> <dmoberg@cyclonecommerce.com> >>> com> cc: >>> ebxml-iic@lists.oasis-open.org, "Cppalist (E-mail)" <ebxml- >>> >>> cppa@lists.oasis-open.org> >>> 08/24/2002 12:16 Subject: [ebxml-cppa] >>> Re: [ebxml-iic] Simple trading partner configuration >>> PM for ebMS >>> >>> >>> >>> >>> >>> >>> >>> Dale, >>> >>> Here you go, The schema and a sample is attached. I have to say that >>> this schema came to be out of a perception that CPA is a bit too >>> complex for the average user. My company has fully implemented CPA >>> v2, >>> so the design of CPA isn't really at issue. I've recently had to >>> maintain 24+ CPAs, and I can tell you that it is a serious pain. >>> >>> Maybe this group could consider a Simple CPA schema, which is a >>> subset >>> of the full schema. I believe the docbook guys did this as well to >>> try >>> and make it easier to get users feet wet. 70/30 or even 60/40 is >>> probably the kind of markup reduction I'm thinking of. Maybe schema >>> modularization is the name of the game. You can decide. >>> >>> Regards, >>> >>> Matt >>> >>> >>> >>> >>> >>> >>> >>> On Friday, August 23, 2002, at 06:38 PM, Dale Moberg wrote: >>> >>>> Hi Matt, >>>> >>>> I skimmed the schema you provided. I guess it >>>> is one of the "70/30" optimization gambits. >>>> Anders from OpenEbXML has proposed a similar >>>> lightweight schema within the JSR 157 group. >>>> >>>> As such, I think it might be worthwhile sending >>>> to the ebxml CPPA TC for consideration. It >>>> is especially interesting in that it might promote >>>> adoption of profile/protocol-binding technologies, >>>> because of its minimalisticYetEssential view of >>>> configuring the b2b side of the MSH. >>>> >>>> So the advantage I see is that it is geared for the >>>> ebXML MSH (it may ignore some of the PKI support >>>> the security risk document recommended--I would >>>> think about adding that in, at least optionally). >>>> >>>> A political problem is that it more or less dispenses with the BPSS >>>> hooks (and so becomes choreography/flow/orchestration/process >>>> independent). That may be feasible via the modularity doctrine, >>>> however. >>>> >>>> Would you be willing to cross post the example and schema >>>> to ebXML-CPPA? Maybe a few words in support of a CPA-lite >>>> could accompany the post? >>>> >>>> Thanks, >>>> Dale Moberg >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Matthew MacKenzie [mailto:matt@xmlglobal.com] >>>> Sent: Friday, August 23, 2002 4:07 PM >>>> To: ebxml-iic@lists.oasis-open.org >>>> Subject: [ebxml-iic] Simple trading partner configuration for ebMS >>>> >>>> >>>> Team, >>>> >>>> As we discussed during the F2F today, I've put together a simple CPA >>>> replacement that has the bare minimum configuration information for >>>> 2 >>>> parties. These could be what we use for specifying MSH >>>> configuration >>>> for conformance and interoperability. It also could form a CPA >>>> replacement, which is designed over time to meet vendor needs as per >>>> discussions we had today (Myself, Hatem@IPNet, Jeff@Cyclone). >>>> >>>> If you're interested in this development for use beyond testing, >>>> please >>>> help me out by supplying feedback -- is there anything missing that >>>> a >>>> good MSH needs out of a TPA? >>>> >>>> Regards, >>>> >>>> Matt >>> >>> >>> #### tpa.xsd has been removed from this note on August 25 2002 by >>> Martin W >>> Sachs >>> #### tpaSample.xml has been removed from this note on August 25 2002 >>> by >>> Martin W Sachs >>> >>> >>> >>> ---------------------------------------------------------------- >>> To subscribe or unsubscribe from this elist use the subscription >>> manager: <http://lists.oasis-open.org/ob/adm.pl> >> >> >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC