RE: ebXML and RosettaNet

["David Connelly (OAGI)" <dconnelly@openapplications.org>]

We are pleased with the syntax neutral CC philosophy.

It gives organizations such as the OAGI the opportunity to work
with ebXML towards more convergence.

We at the OAGI intend to try to be good citizens to the best
of our ability.  We will work to connect our OAGIS language to
ebXML CC language, perhaps when we go to XML Schema.

We have a track record of "just working", and we are striving to
protect people's investments as we have proven with our BizTalk and
RN framework adoption, our direction to XML Schema, our UML work,
our Sub-Scenario work, and now our adoption of the ebXML T&R, BPM,
CCA, and CCP bodies of work.

We will continue to work with the CC team and try to do the right
thing to protect our constituency as well as be good citizens of the
larger community.

David

-----Original Message-----
From: Blantz, Mary Kay [mailto:mblantz@netfish.com]
Sent: Tuesday, March 27, 2001 10:39 AM
To: 'Jim Clark'; Kanaskie, Kurt A (Kurt)
Cc: ebxml-bp@lists.ebxml.org; Erik.J.Leckner@seagate.com;
JohnY@Edifecs.com; Krishna Sankar; David M. Connelly (E-mail)
Subject: RE: ebXML and RosettaNet


I think that OAGI is also very pleased with the syntax neutral Core
Component philosophy, and the use of UIDs.  I've CC'd David, just in
case he's not on this list and would like to comment.

Mary Kay

-----Original Message-----
From: Jim Clark [mailto:jdc-icot@lcc.net]
Sent: Tuesday, March 27, 2001 7:40 AM
To: Kanaskie, Kurt A (Kurt)
Cc: ebxml-bp@lists.ebxml.org; Erik.J.Leckner@seagate.com;
JohnY@Edifecs.com; Krishna Sankar
Subject: Re: ebXML and RosettaNet




"Kanaskie, Kurt A (Kurt)" wrote:

> All,
>
> This is an interesting thread and I would like to add my comments, hopes
and
> dreams.
>
> 1. We don't want multiple standards that we have to
> bridge/translate/interoperate between. We want a best of breed convergence
> (dream).

Or maybe not so much of a dream. I have been working this very issue for the
last 10 years amongst various standards orgs and believe that we are closer
than
ever before. With the adoption of Protocol Neutral Modeling by the ITU,
UN/CEFACT, TMForum, RosettaNet, OMG, ETSI, and others it is very likely. As
an
example, the modeling approach and architecture that we introduced at
RosettaNet
can be found in the M.3020 which defines the PNM approach for the ITU. This
same
architecture is now an integral part of the UMM which specifies the
specification approach for the UN/CEFACT. Some of the architecture is being
fed
back into the TMForum. We may not be there but we are heading in the right
direction.

>
> 2. My primary motive for working with ebXML, RosettaNet and OAGI is to
> achieve convergence in that they leverage each others strengths. OAGI has
> defined a broadly scoped set of messages that have been proven in the
field,
> RosettaNet has defined B2B process definitions that have also been proven,
> and ebXML is defining (among other things) horizontal infrastructure
> standards than many different groups can use.

>
> 3. It has been my understanding through various contacts that RosettaNet
> wants to get out of the infrastructure level specification and message
> definition business. They want to focus on what they do best, process
> definitions. Therefore I expect (hope) RosettaNet will endorse ebXML and
> begin to define their processes in ebXML syntax and transport their
messages
> using ebXML.

Yes, This would make a lot of sense. I think of TRP as RNIF on steroids. The
reason for this is that most of the engineers that developed RNIF were also
on
the TRP team. (A mighty fine piece of work). However, I would expect that
their
specs would stop where they do now with the FSV, which is Protocol Neutral.
There would then exist a mapping specification (production rules) to map the
PIP
Spec into the BP schema. In this way the PIPS can be used in other industry
segments like the ITU and TMForum. Also, by architecturing it this way, we
show
an example that other forums can follow for the same purpose.

>
> 4. OAGI has stated all along that they only do messages. They have already
> endorsed ebXML and are planning to support the TRP and the BP
specification.
> They may have other plans, but these I know for a fact.
>
> >From my perspective ebXML is a unifying force not another standard that
> customers need to deal with.

I couldn't agree with you more. As I indicated earlier, we coming closer and
closer and ebXML has been a catalyst just for that.

Jim Clark

>
>
> Kind regards,
> ________________________________________________________________
> Kurt Kanaskie
> Lucent Technologies
> kkanaskie@lucent.com
> (610) 712-3096
>
>  -----Original Message-----
> From:   Jim Clark [mailto:jdc-icot@lcc.net]
> Sent:   Monday, March 26, 2001 10:12 AM
> To:     Krishna Sankar
> Cc:     Erik.J.Leckner@seagate.com; JohnY@Edifecs.com;
> ebxml-bp@lists.ebxml.org
> Subject:        Re: ebXML and RosettaNet
>
>  << File: Card for Jim Clark >> Krishna,
>
> Your observation here is well stated. The issue of 'using' RNet Pips
> (version 1.1 and/or 2.0)
> in an ebXML framework or visa versa is not as simple as has been related
so
> far. The issue of
> use/reuse can be expressed in terms of compatibility (syntactically or
> semantically), in
> terms of inter operability, and/or in terms of inter exchangeability. How
> one determines
> the/a  level of compliance has not been well defined within ebXML. My
> expectation is that
> once all of the specs have settled down and we have consensus, we will be
> able to provide
> this definition.
>
> Best regards,
> Jim Clark
>
> Krishna Sankar wrote:
>
> > Hi all,
> >
> >         Let me add my thoughts to the mix.
> >
> >         1.      RN and ebXML can be interchangeable (i.e. you can
execute
> a Business
> > process via RN or ebXML, if one has defined the BPs) but *not*
> interoperable
> > without a bridge. (Jim's first paragraph explains this) i.e.
semantically
> > Yes, syntactically NO. (Of course, I am a little liberal with the words
> > "syntax" and "semantics")
> >
> >         2.      We all (could) agree that the payloads might be the
same,
> but the
> > difference is in the transport and most probably transformations would
be
> > required at the header, envelope and other similar structures.
> >
> >         3.      If we envision a bridge between "compatible" standards
> (i.e. standards
> > in the same space) how do we fill the missing elements ? Most probably
> > default values specific to the particular Business Process and
> organization.
> >
> >         3.      A related issue is the security. One can transport an
> encrypted payload
> > across the different standards, but if the whole message is signed, the
> > bridge would not be able to sign the envelopes for the sender ;-0
> >
> >         4.      A mapping between the standards definitely is useful,
but
> I do not think
> > an interoperability specification *between* standards is ebXML's
> > responsibility. As the standards are evolving at a fast rate, no
standard
> > can publish an interoperability "bridge" with others in it's own space.
Of
> > course, the standards need to say how they will operate with the ones
they
> > depend on - like the XML DSIG, XMLEncryption et al.
> >
> >                 With due respect to all other standards, I also cannot
see
> ebXML as a (or
> > THE) super "B2B" standard
> >
> >         5.      Organizations would need to support multiple standards
> (hopefully a few)
> > between their customers, partners and suppliers. i.e. if someone talks
> ebXML
> > to an organization, the organization will need an ebXML engine and
> similarly
> > would need a RosettaNet engine to talk to partners who talk only
> RosettaNet.
> > Most probably the architecture would include an abstraction layer (like
a
> > middleware) to mask this difference from the backend services.
> >
> >                 I am for a light weight XML infrastructure which can
> support DTDs,
> > choreographies and Business Processes from various vertical and
horizontal
> > standards. May be that is where Erik's convergence can be achieved. Till
> now
> > we had the firmware/hardware transport (TCP et al) and may be it is time
> for
> > an upper layer software transport. BTW, there are more initiatives in
this
> > space including BizTalk (to some extent) and the XMLP. SOAP, of course,
is
> a
> > candidate here (at a lower level in the stack) as ebXML and XMLP are
based
> > on SOAP
> >
> >                 But like Erik pointed out, talking ebXML to a partner
who
> has only
> > RosettaNet infrastructure, wouldn't be possible. My question here is, do
> we
> > need interoperability at this level ? Do ebXML and RosettaNet and
BizTalk
> > and XMLP need to talk to each other ? And is it a reality to expect them
> to
> > do so ?
> >
> > cheers
> >
> > |-----Original Message-----
> > |From: Erik.J.Leckner@seagate.com [mailto:Erik.J.Leckner@seagate.com]
> > |Sent: Saturday, March 24, 2001 2:42 PM
> > |To: jdc-icot@lcc.net
> > |Cc: JohnY@Edifecs.com; Erik.J.Leckner@seagate.com;
> > |ebxml-bp@lists.ebxml.org
> > |Subject: Re: ebXML and RosettaNet
> > |Importance: High
> > |
> > |
> > |
> > |
> > |
> > |
> > |All,
> > |
> > |For clarification purposes, I would like to summarise the
> > |conclusion from this discussion:
> > |
> > |   An ebXML-based service cannot deliver RNet PIPs without
> > |transformation from RNIF or UMM to BP.
> > |   This makes defining interworking ('interoperability') between
> > |the two services/architectures somewhat of a daunting task.
> > |
> > |   Question: Is it in ebXML's scope to interwork with all or a
> > |select set of existing electronic business exchange industry
> > |           standards, such as RosettaNet? If it is all, then
> > |obviously ebXML can not focus on one set of standards to interwork.
> > |             ebXML would then act as the convergence point for all
> > |B2B standards .
> > |
> > |   John stated that 'Only a RosettaNet offical will be able to
> > |express their policy with regard to use of their formats outside of the
> > |   RN group.' This sounds like ebXML might need to address this
> > |topic with the possibility of defining interworking gateways or
'bridges'
> > |   between various industry standards, such as RosettaNet.
> > |Otherwise, this topic might always come up in the future when an
> > |organization
> > |   must define their own mapping/bridge between the two standards,
> > |if they choose to support multiple standards, such as ebXML and
> > |   RosettaNet.
> > |
> > |   Question: Should ebXML define the specification of
> > |interoperability mechanisms to enable multi-standard communication
> > |to take place,
> > |             If so, the work would have to be based on a set of
> > |scenarios, such as this:
> > |
> > |          1. ebXML to RosettNet
> > |          2. RosettaNet to ebXML
> > |          3. ebXML to 'standard x'
> > |          4. 'standard x' to ebXML
> > |               ...
> > |
> > |Best Regards,
> > |Erik J Leckner
> > |Director, Technical Architecture & Standards
> > |Seagate Technology, LLC
> > |
> > |
> > |
> > |
> > |
> > |Jim Clark <jdc-icot@lcc.net> on 03/24/2001 09:28:25 AM
> > |
> > |To:   John Yunker <JohnY@Edifecs.com>
> > |cc:   Erik.J.Leckner@seagate.com, ebxml-bp@lists.ebxml.org
> > |
> > |Subject:  Re: ebXML and RosettaNet
> > |
> > |
> > |Gentlemen,
> > |
> > |I would like to add my 2 cents worth. Like John I have been involved in
> > |both
> > |efforts.
> > |
> > |First, I fully concur with John's assessment, however, I would like to
> > |expand on
> > |a few issues.
> > |
> > |In that there are some structural differences between a ebXML document
> and
> > |a
> > |RNet document, I do not believe that they are interexchangeable as is.
> > |ebXML has
> > |added some elements and moved some others. If a process requires some
of
> > |these
> > |new elements, one will not be able to use a RNet Doc without adding
this
> > |info.
> > |If one were to use a ebXML compliant document in an RNet
implementation,
> it
> > |may
> > |require some restructuring. (not a difficult problem). Conclusion: use
> RNet
> > |in
> > |ebXML - maybe; use ebXML in RNet - most likely; so it may be best to
> model
> > |or
> > |define documents in ebXML so that the effort to use in both places is
> > |minimal.
> > |
> > |RNet PIPs- Along with the divergence in goals has been a divergence in
> > |perspectives. This shows up in divergence in the BP Specification
Schema
> > |from
> > |the UMM MetaModel. Any process definition that is built on the UMM
> > |Metamodel or
> > |the RNIF1.0 or RNIF2.0 will be directly interchangeable. RNIF was built
> on
> > |the
> > |UMM Architecture and is a subset of the UMM.  Any process definition
> built
> > |on
> > |the BP Specification Schema will need transformation or production
rules
> to
> > |map
> > |from the BP Schema to RNIF or UMM. It is too early to determine, but I
do
> > |not
> > |believe that this transformation can be done without lose of semantics
> > |between
> > |the two representations.
> > |
> > |We may be close to interoperability but not interchangeability.
> > |
> > |Jim Clark
> > |Dir of Industry Solutions
> > |E2open
> > |936.264.3366
> > |
> > |John Yunker wrote:
> > |
> > |> Erik,
> > |>
> > |> I have participated in groups defining both the RosettaNet and ebXML
> > |> architecture. These comments are my own opinion and are not binding
on
> > |> anyone in either organization.
> > |>
> > |> ebXML messaging infrastructure meets the requirements for executing
> > |> RosettaNet PIPs. Several key members of the RNIF 2.0 team are also
> > |members
> > |> of ebXML TRP, TPA, and BP.
> > |>
> > |> Also, the meta-metamodel upon which the specifications are based is
> > |common
> > |> between RosettaNet and ebXML, and has become part of the UN/CEFACT
TMWG
> > |UMM.
> > |>
> > |> That said, there is no formal alignment at a specification level
> between
> > |the
> > |> two groups... In fact there is a divergence of primary goal between
the
> > |two
> > |> groups. ebXML goal is to be horizontal enabler, and is currently
> > |embracing
> > |> many busines message groups, with wide latitude for individual
members
> > |use
> > |> of formats. RosettaNet goal is interoperability between members, and
> > |> strongly constrains the element level content in their messages.
> > |>
> > |> It is very likely that RosettaNet messages will be executable within
> the
> > |> ebXML context, although there will probably not be strong
restrictions
> on
> > |> message use, which begs the question "is it really RosettaNet, or
just
> a
> > |> borrowing of their layouts". Only a RosettaNet offical will be able
to
> > |> express their policy with regard to use of their formats outside of
the
> > |RN
> > |> group.
> > |> Your question includes the phrase "ebXML defines similar
specifications
> > |for
> > |> industries such as disk-drive designers/manufacturers". This is as
far
> as
> > |I
> > |> can tell a non-issue, since ebXML will not be developing
specifications
> > |for
> > |> specific industries. It is highly likely that the task of creating
> > |> specifications (when existing ones are not simply "adopted for use")
> will
> > |> fall to a group such as X12, OAG, or UN/CEFACT. This is a current
area
> of
> > |> discussion that you should become involved in through BP/CC.
> > |> My observations only,
> > |> John
> > |>
> > |> -----Original Message-----
> > |> From: Erik.J.Leckner@seagate.com [mailto:Erik.J.Leckner@seagate.com]
> > |> Sent: Friday, March 23, 2001 1:55 PM
> > |> To: ebxml-bp@lists.ebxml.org
> > |> Subject: ebXML and RosettaNet
> > |> Importance: High
> > |>
> > |> Hi,
> > |>
> > |> Could anyone please answer the following question?
> > |>
> > |> Will ebXML's components be a replacement for RosettaNet PIP documents
> > |> transferred in b2b
> > |> exchanges or will ebxml support RosettaNet PIPs, as is? I would like
to
> > |> know whether or not
> > |> this will change as ebXML defines similar specifications for
industries
> > |> such as disk-drive designers/manufacturers (computer hardware, etc.).
> > |>
> > |> Best Regards,
> > |> Erik J Leckner
> > |> Seagate Technology, LLC
> > |> San Jose, CA
> > |> Director, Technical Architecture & Standards
> > |>
> > |> ------------------------------------------------------------------
> > |> To unsubscribe from this elist send a message with the single word
> > |> "unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org
> > |>
> > |> ------------------------------------------------------------------
> > |> To unsubscribe from this elist send a message with the single word
> > |> "unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org
> > |
> > |(See attached file: jdc-icot.vcf)
> > |
> > |
> > |