RE: [ebxml-cppa] Fwd: RE: [ebxml-dev] Is ebXML already a valid alternative for EDI ?

["steve capell" <steve.capell@redwahoo.com>]

Marty,

I think the problem with CPPA negotiation is one of semantics embedded in
the CPPs.  There are so many things that have to match up including
transports, trust domains, protocols, versions, collaboration roles,
information semantics, etc.  The source CPPs would have to be very well
formed indeed to be sure you capture and correctly interpret all that stuff.
Most real CPPs I have seen don't cut the mustard.

My feeling is that you need a higher level framework such as UMM that
carries the source semantics for collaboration and transaction patterns plus
CCTS as a framework for information alignment.  When your deployment
scenarios are generated from these semantically constrained models then you
have a chance of computing alignment between partyA and partyB.

Which begs the question - if you are going to generate deployment schema
from models which, in turn, are based on patterns then there is going to be
common collaboration scenarios that are fairly easily deployed as template
CPAs.  It takes only a few minor changes to turn a template CPA into a
deployment CPA and you have a much higher chance of it leading to successful
collaborative transactions than the scenario where you grab two independent
CPPs and try to compute a CPA.

SO if you want to make the concept of an end point MSI and BSI being
automatically configured from BPSS and CPA then I'd suggest you would be
better focussing on standardising some patterns and rules for generating
template CPAs from UMM models and then some further (simple) rules for
generating deployment CPAs from templates.  Strikes me as a much simpler and
more reliable starting point than computing CPA from CPPS that have no
higher level constraints.

The UMM Model -> Template CPA -> deployment CPA (via simple hosted
negotiation) -> MSI/BSI actions is what we have implemented here and it
seems to work well enough.

Regards,

Steve



-----Original Message-----
From: Martin Sachs [mailto:msachs@cyclonecommerce.com] 
Sent: Tuesday, 8 February 2005 3:00 PM
To: ebxml-cppa
Subject: [ebxml-cppa] Fwd: RE: [ebxml-dev] Is ebXML already a valid
alternative for EDI ?

For those who aren't connected to ebxml-dev, please see the references to 
CPPA and Negotiation below. People are certainly convinced of the value of 
CPPA. It is also recognized that CPPA negotiation is one of the foundations 
of CPPA. How can we move negotiation forward to live up to this promise?

REgards,
Marty

>Mailing-List: contact ebxml-dev-help@lists.ebxml.org; run by ezmlm
>X-No-Archive: yes
>List-Post: <mailto:ebxml-dev@lists.ebxml.org>
>List-Help: <mailto:ebxml-dev-help@lists.ebxml.org>
>List-Unsubscribe: <mailto:ebxml-dev-unsubscribe@lists.ebxml.org>
>List-Subscribe: <mailto:ebxml-dev-subscribe@lists.ebxml.org>
>Delivered-To: mailing list ebxml-dev@lists.ebxml.org
>From: "steve capell" <steve.capell@redwahoo.com>
>To: "'Chiusano Joseph'" <chiusano_joseph@bah.com>,
>         "'Duane Nickull'" <dnickull@adobe.com>,
>         "'CANON Stephane'" <Stephane.CANON@swift.com>
>Cc: <ebxml-dev@lists.ebxml.org>
>Date: Tue, 8 Feb 2005 14:46:11 +1100
>X-Mailer: Microsoft Office Outlook, Build 11.0.6353
>Thread-Index: AcUNfvJLRt3GYIyIRDKEmW37xs2P4AADl9ogAABqzAA=
>X-Qmail-Scanner-Message-ID: <110783437951021240@hermes>
>X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on
>         hermes.oasis-open.org
>X-Spam-Status: No, hits=2.7 required=7.0 tests=EXCUSE_16,TW_BX,TW_EB
>         autolearn=no version=2.64
>X-Spam-Level: **
>Subject: RE: [ebxml-dev] Is ebXML already a valid alternative for EDI ?
>X-XWall-Excl: white-list maillist
>X-OriginalArrivalTime: 08 Feb 2005 03:47:51.0773 (UTC) 
>FILETIME=[F6D800D0:01C50D90]
>X-NAS-Bayes: #0: 0; #1: 1
>X-NAS-Classification: 0
>X-NAS-MessageID: 4071
>X-NAS-Validation: {6C6C0D95-D959-4B50-8369-95681D6D69E6}
>
>I could be wrong but I suspect that Stephane's question was a little
broader
>than whether there is a suitable XML format to replace EDI as an
information
>carrying structure.
>
>If the question was "We have been doing e-Business for some time using EDI
>messages and VANs for transport but we are evaluating alternative
e-Business
>frameworks that might help us address a larger community of medium and
>smaller businesses that cannot easily support EDI infrastructure costs but
>still require the quality of service that is needed for financial
>transactions.  We are wondering whether the ebXML architecture might
provide
>such a framework?"
>
>Then the answer is an emphatic YES.
>
>However I'd recommend that SWIFT look at the entire architecture from UMM
>model to message envelope.  It is only by applying the entire architecture
>that genuine scalability emerges.  Just using the messaging protocol is
fine
>but without a CPA to configure it you could (almost) equally well use RNIF
>or even EDIINT - and you still need technical staff to do configuration.
>But then a CPA without a negotiation protocol to derive it from either a
CPA
>template or two CPPs is a technical challenge that most small businesses
>also wont manage.  But then you need a means to automate the generation of
a
>template CPA (and BPSS) from a set of business patterns in UMM - and also a
>runtime engine that can perform the BPSS BSI function.  And finally you
>store all these objects in a registry so that they are discoverable - then
>when you do all that (and only when you do all that), e-Business really is
>as easy as getting in your car and driving away.  Fortunately as a
standards
>body like SWIFT you don't necessarily have to understand or build all this
>stuff - just know how to identify / certify / recommend products that do it
>for you.
>
>Regards,
>
>Steve Capell
>
>
>
>This email message and any accompanying attachments may contain information
>that is confidential and is subject to legal privilege. If you are not the
>intended recipient, do not read, use, disseminate, distribute or copy this
>message or attachments. If you have received this message in error, please
>notify the sender immediately, and delete this message. Any views expressed
>in this message are those of the individual sender, except where the sender
>expressly, and with authority, states them to be the views of Red Wahoo
Pty.
>Ltd.
>
>
>
>Before opening any attachments, please check them for viruses and defects.
>We do not accept any liability for loss or damage which may arise from your
>receipt of this e-mail.
>
>-----Original Message-----
>From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
>Sent: Tuesday, 8 February 2005 2:24 PM
>To: Duane Nickull; CANON Stephane
>Cc: ebxml-dev@lists.ebxml.org
>Subject: RE: [ebxml-dev] Is ebXML already a valid alternative for EDI ?
>
>Adding to Duane's response, specifically his comment about data formats:
>
>In that regard, an XML-based vocabulary such as OASIS UBL would be
>closer to an alternative for EDI (or one may say it *is* an
>alternative), for the transactions that are currently covered by UBL.
>
>Kind Regards,
>Joseph Chiusano
>Booz Allen Hamilton
>Strategy and Technology Consultants to the World
>
>
> > -----Original Message-----
> > From: Duane Nickull [mailto:dnickull@adobe.com]
> > Sent: Monday, February 07, 2005 8:38 PM
> > To: CANON Stephane
> > Cc: ebxml-dev@lists.ebxml.org
> > Subject: Re: [ebxml-dev] Is ebXML already a valid alternative
> > for EDI ?
> >
> > Stephane:
> >
> > The answer is no (sort of).  EDI is a data format and ebXML
> > is an infrastructure so they are not really comparable.
> >
> > EDI can be used within ebXML exchanges.  ebXML was designed
> > (especially the messaging component) to replace the
> > functionality of the VAN's although in reality this has
> > probably not happened that much.  VAN's could conceivably use
> > ebXML to add value to their customers and also lower their costs.
> >
> > Duane
> >
> > CANON Stephane wrote:
> >
> > > Hello,
> > >
> > > Five years ago, I used to work in the EDI business. The
> > technology we
> > > were using at that time was X400 or GE  / IBM Vans and Edifact. We
> > > were also proposing "Web-Edi" to our smaller business partners.
> > > What are the real alternatives for Corporates in EDI ? Is
> > ebXml one of
> > > those ?
> > >
> > > Thanks,
> > >
> > >
> > > Stephane Canon
> > > Lead Standards Specialist
> > > S.W.I.F.T.
> > > Tel: +32 2 655.30.89.
> > > Mobile: +32 475 43.23.85.
> > > Fax: +32 2 655.45.52.
> > > S.W.I.F.T. s.c.r.l.
> > >
> > > This e-mail and any attachments thereto may contain
> > information which
> > > is confidential and/or proprietary and are intended for the
> > sole use
> > > of the recipient(s) named above. It is not intended to create or
> > > affect any contractual arrangements between the parties. If
> > you have
> > > received this e-mail in error, please immediately notify the sender
> > > and delete the mail. Thank you for your co-operation.
> > >
> > >
> >
> >
> > --
> > ***********
> > Senior Standards Strategist - Adobe Systems, Inc. -
> > http://www.adobe.com Vice Chair - UN/CEFACT Bureau Plenary -
> > http://www.unece.org/cefact/ Adobe Enterprise Developer
> > Resources  - http://www.adobe.com/enterprise/developer/main.html
> > ***********
> >
> >
>
>---
>[This E-mail scanned for viruses by IntaServe - MailGuardian Service at
>http://www.intaserve.com]

*************************************
Martin Sachs
standards architect
Cyclone Commerce
msachs@cyclonecommerce.com 



To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/ebxml-cppa/members/leave_workgr
oup.php.


---
[This E-mail scanned for viruses by IntaServe - MailGuardian Service at
http://www.intaserve.com]