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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic message

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


Subject: FW: [ebxml-cppa] Re: [ebxml-iic] Simple trading partner configura tionfor ebMS


Title: FW: [ebxml-cppa] Re: [ebxml-iic] Simple trading partner configuration for ebMS

FYI

-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: Monday, August 26, 2002 1:52 PM
To: Matthew MacKenzie
Cc: Dale Moberg; Cppalist (E-mail); ebxml-iic@lists.oasis-open.org
Subject: Re: [ebxml-cppa] Re: [ebxml-iic] Simple trading partner
configuration for ebMS

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





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