[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
+1
*************************************************************************************
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/27/2002 11:16 Subject: Re: [ebxml-cppa] Re: [ebxml-iic] Simple trading partner
AM configuration for 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