No Subject

[Rik Drummond <rvd2@worldnet.att.net>]

-----Original Message-----
From: Narsu, Uttam [mailto:UNarsu@gigaweb.com]
Sent: Thursday, February 22, 2001 9:42 AM
To: 'cgeyer7@home.com'
Cc: Gilpin, Mike
Subject: RE: ebXML Integrates SOAP Into Messaging Services Spec


Hi Carol,

This is great news. I have a few questions on this if you don't mind.

1. The W3C wasn't mentioned in the press release. But I presume that you
will be working with the W3C XML Protocol activity which is charged with
standardizing SOAP? What I'm concerned about is that if you use the 1.1
and
SOAP with attachments spec as base documents, if they evolve in the
context
of W3C's activity beyond what ebXML specifies in May (a likely
assumption),
what will ebXML do to maintain compatibility? Will your work be fast
tracked
into the W3C's spec? ebXML is slated for May 2001, but XP is not likely
until 2002.
rik> these issues are being worked out. we have formal representation from
ebxml on the xp wg. we are hoping that the additional functionality that
ebxml brings to soap, such as reliable messaging, will be included in the xp
final recommendations, because i don't think that rpc functionality is
enough for most business to use xp as a transport protocol if we don't.



1a.  It has been suggested that an interesting metaphor for these
standards
is the following:

    smtp, http, etc ---->ebXML
    TCP---->XP, ebxml
     IP---->MIME, xml
Ethernet--->HTTP

The implication is that a future XP can both enable ebXML and ebXML may
depend on XP. Is this a valid scenario?

rik> this is not clear. soap 1.1/ soap with attachments, has three
orthagonal parts: 1) encoding, 2) rpc, and 3) enveloping. ebxml was only
able to use the enveloping part because of the upgrades in functionality in
the envelop structure from soap 1.0 to soap 1.1. our reliable messaging and
security are not supported in soap at this time. if xp uses the
functionality of ebxml transport in the future released version, then your
scenario would be correct. if not then the scenario would not be correct.


2. Has there been any change or warming between Microsoft and ebXML?
Will
BizTalk support ebXML now that SOAP is a common link between the two
specs?

rik> the announcement would not have happened without significant joint
effort between ebxml executives and the microsoft representitives. it is not
clear if biztalk will support ebxml at this time. however, i have begone the
dialogue along thoses lines.



3. What has changed since several months ago when the transport and
routing
group felt SOAP was not ready for prime time (immature was the word
used)?
Was it the recent support for attachments and MIME which made encryption
more feasible and also made it easy to transport arbitrary content
without
base 64 encoding it that sealed the deal?

rik> exactly!



4. Jon Bosak has characterized the distinction between SOAP and ebXML as
being related primarily to quality of service. So there is a continuum
of
services that span the spectrum from those that don't need to be 100%
reliable (an example might be certain types of news-subscription
services)
all the way to trading services (the multi-million dollars transactions
services), which need mission-critical QOS. SOAP would be for the more
simple ones, and ebXML for the more complex ones.

I think he is oversimplifying. Clearly Microsoft has built a
mission-critical architecture (BizTalk) on top of SOAP. So what do you
believe will be the roles for which SOAP and ebXML are best suited?

ebxml offers both reliable and not reliable messaging services, with or
without security. soap 1.1 does not, however biztalk does. ebxml is more
akin to biztalk than soap. ebxml is open, biztalk is owned by a single
company. the market now has two choices, which is always good. microsoft has
historically supported other standards such as "secure edi over internet" a
ietf draft. i would not be surprised if in 12-18 months if they don't
support ebxml also... just my guess.


5. Will the main difference between a SOAP message and an ebXML message
be
that a body in a SOAP message will be a MIME attachment in an ebXML
message?

rik> we have moved all of the ebxml transport functionality to a soap1.1/swa
envelope. this means that existing soap processor may receive and send ebxml
messages. of course they will not know what to do with the ebxml specific
headers and payloads, but they will be able to process it, much in the same
way that smtp can send and receive attachments yet not beable to process
that attachments.

hope that helps, rik



Thanks,
Uttam

-----Original Message-----
From: Carol Geyer [mailto:cgeyer7@home.com]
Sent: Thursday, February 22, 2001 8:43 AM
To: announce@lists.oasis-open.org
Subject: ebXML Integrates SOAP Into Messaging Services Spec


ebXML Integrates SOAP Into Messaging Services Specification

Boston, MA, USA, Geneva, Switzerland; February 22, 2001-UN/CEFACT and
OASIS announced efforts are now underway to integrate SOAP 1.1 and SOAP
with Attachments specifications into the ebXML Messaging Specification.
SOAP (Simple Object Access Protocol) is designed to provide the
underpinnings for messaging requirements. This development by ebXML will
result in an open, widely adopted global standard for reliably
transporting electronic business messages over the Internet.

"The convergence of these two specifications marks a significant step
forward for interoperability," commented Klaus-Dieter Naujok, chair of
ebXML and member of the UN/CEFACT Steering Group. "We're committed-not
only to integrating ebXML Messaging with SOAP-but also to completing
this work in time to meet our original goal of delivering ebXML in May
2001."

"Having the messaging infrastructure of ebXML built on SOAP is a strong
signal that standards convergence is both desired by the industry and
doable," said Dr. Robert S. Sutor of IBM, Vice-Chair of ebXML and a
member of the OASIS Board of Directors. "As ebXML evolves, we will
continue to explore how we can cooperate with others to help develop the
foundational open standards for business on the Internet."

The ebXML Messaging Specification encompasses a set of services and
protocols that allow an electronic business client to request services
from electronic business servers over any application-level transport
protocol, including SMTP, HTTP and others. ebXML defines a
general-purpose message, with a header that supports multiple payloads,
while allowing digital signatures within and among related messages.
Although the header is XML, the body of the message may be XML, MIME or
virtually anything digital.

"By adopting SOAP in their messaging layer, ebXML puts to rest any
worries about interoperability between SOAP and ebXML. This takes
advantage of SOAP's role as a key component of XML-based messaging,"
said Andrew Layman, XML Architect of Microsoft.

"The ebXML Messaging Services Specification retains all the secure,
reliable messaging functionality that has been developed to date,"
explained Rik Drummond of the Drummond Group, ebXML Messaging Services
Project Team Leader. "By incorporating SOAP into ebXML, we streamline
acceptance and reduce the cost of product implementation for all
companies, regardless of their size."

About ebXML
ebXML (www.ebXML.org) is an International Initiative established by
UN/CEFACT and OASIS in late 1999 with a mandate to undertake an 18-month
program of work to research and identify the technical basis upon which
the global implementation of XML (Extensible Markup Language) can be
standardized. The goal of ebXML is to facilitate open trade between
organizations regardless of size by enabling XML to be used in a
consistent manner to exchange electronic business data.

About UN/CEFACT
UN/CEFACT (www.uncefact.org) is the United Nations body whose mandate
covers worldwide policy and technical development in the area of trade
facilitation and electronic business. Headquartered in Geneva, it has
developed and promoted many tools for the facilitation of global
business processes including UN/EDIFACT, the international EDI standard.
Its current work programme includes such topics as Simpl-edi and Object
Oriented EDI and it strongly supports the development and implementation
of open, interoperable global standards and specifications for
electronic business.