FW: extending ebXML scope to app-to-app integration within enterp rises

["Paul R. Levine" <plevine@telcordia.com>]

I agree that B2B is not A2A for transport routing and packaging.  My proposed
A2A comments were totally with regard to the requirements, analysis, and data
protocol (i.e., XML) design workflows in developing a business process model.
I'm sure there are major differences between B2B and A2A when it comes to the
communication infrastructure, as pointed out  by David Burdett.

Regards,

Paul Levine
---------------------- Forwarded by Paul R. Levine/Telcordia on 03/24/2000 02:23
PM ---------------------------


David Burdett <david.burdett@commerceone.com> on 03/24/2000 01:10:21 PM

To:   "'ebXML-BP@lists.oasis-open.org'" <ebXML-BP@lists.oasis-open.org>
cc:    (bcc: Paul R. Levine/Telcordia)
Subject:  FW: extending ebXML scope to app-to-app integration within enterp
      rises




I'm the Editor of the Transport Routing and Packaging Group. Nikola sent me
this email about A2A. Since this overlaps with some of the work we are doing
I've provided some comments.

Please let me know if you have any questions.

Regards

David Burdett

Advanced Technology, CommerceOne
4400 Rosewood Drive 3rd Fl, Bldg 4, Pleasanton, CA 94588, USA
Tel: +1 (925) 520 4422 or +1 (650) 623 2888;
mailto:david.burdett@commerceone.com; Web: http://www.commerceone.com


-----Original Message-----
From: David Burdett
Sent: Friday, March 24, 2000 9:29 AM
To: 'Nikola Stojanovic'; ebXML Transport (E-mail)
Subject: RE: extending ebXML scope to app-to-app integration within
enterp rises


Nikola

Here are my comments - please pass on to the BP group if you think it helps.
I've split them up under four headings:
1. B2B is not A2A
2. Trusting your Trading Partners
3. The Internet is Unreliable and
4. The Ever-changing Internet

David

B2B IS NOT A2A
Tony says ...

>>>When a "B2B context" message hits an enterprise boundary "MAGIC" doesn't
happen. A handler has to hand off the message to an "internal" application.
If this is not actually some piece of an ERP suite - it most certainly will
engage such a suite [or an analogous Legacy app] before the transaction is
completed.<<<

I disagree.

Although sometimes the data will be handled off to an existing ERP, this is
not always the case. Remember that one of the objectives of ebXML is to
bring the benefits of eCommerce to the "S" in "SME" who probably has nothing
more than a web browser as their client yet needs to be able to render an
XML document into a readable format - probably using nothing more than a
style sheet - before processing it and then producing a response by filling
in a form that creates another XML document to send back.

What I think this means is that, as far as the Transport Routing and
Packaging group is concerned, that we cannot make ANY assumptions about the
technology that will be accepting or generating a message. We especially
cannot assume that there is necessarily an ERP system at the other end. What
we really are doing is B2B (i.e. any business to any business) and not
*just* application to application.

Tony also says >>>
>>>In our view, for web based interactions involving large to medium
organizations: E2E = B2B + A2A + A2F [where A2F is the link to factory floor
applications].   As Khwaja pointed out, there is "...tremendous value in
having a single foundation for EAI+IAI+B2B"<<<

While unification of approach is a laudable aim, I don't think it is
practical. This is because of some of the fundamental differences between
linking separate businesses over the internet and linking the individual
applications within a business.

TRUSTING YOUR TRADING PARTNERS
The most fundamental difference is a question of trust.

If a second application receives a request to carry out a service from a
first application where both are in the same business then, implicitly, the
second application knows that it should carry out the request since:
*    the communication link is trusted - no one has an incentive to
tamper with the data
*    the two applications have been tested together and know that they
are compatible,
*    the sender can be trusted - it's from the same organization, and
therefore
*    the request is authentic and authorized and should be acted on

This is the opposite to the Internet where:
*    the communication link can be hacked into
*    the applications have probably never been tested together - you can
never check for interoperability of every application with every other as it
doesn't scale

... and therefore ...
*    you need to check the validity of the structure of the message, and
the trustworthiness of the sender and therefore
*    the service request is authentic and authorized

This means that for B2B (rather than A2A) you have to have an
*interoperable* mechanism for:
*    validating the authenticity of a request - this involves using
digital signatures
*    checking and reporting on errors

Also remember, that in order to address the "S" in "SME" this should work
equally well over SMTP as for HTTP.

THE INTERNET IS UNRELIABLE
If two applications are part of the same business and one of the
applications fails, then there is likely (hopefully?) a well developed
recovery plan that enables the failed application to re-start and normal
business processing to resume. On the Internet failure can be caused by
other reasons:
*    a message was lost on an intermediate server on the net
*    the response to a message was lost in a similar, as well as
*    the application processing the message failed or lost the message.

If you are the sender of a message then you need to have a standard
interoperable way of recovering from the failed message which is realizable
just by sending more messages. This approach is different from the one you
would adopt within an enterprise.

THE EVER-CHANGING INTERNET
Having a single foundation for EAI, IAI and B2B is also unrealistic due to
the ever-changing nature of the Internet. We have to assume that businesses
will want the freedom to develop new services whenever they want and make
them available over the internet so that they can support co-operative
business processes with their partners. Secondly, having developed one
service they will want to revise it in a way which is not constrained by
their partners development and implementation timescales.

What this means is that trading partners need to be able to discover what
services and processes a business supports and then adapt their solutions,
ultimately dynamically, to support them. The corollary of this is that we
cannot necessarily make any assumptions about any data received from a third
party that it will be compatible with previous versions of data that has
been sent.

CONCLUSION
A2A technology and standards such as that developed by the OAG is very
important and valuable - especially when systems can be "tightly coupled"
and the source and destination are clearly understood.

But the unreliable, everchanging Internet and the need to communicate with
"small" enterprises that have no "application" mean that a much more
"loosely coupled" approach is required.

In my view B2B is not A2A.

Regards

David


-----Original Message-----
From: Nikola Stojanovic [mailto:nstojano@cjds.com]
Sent: Thursday, March 23, 2000 1:48 PM
To: ebXML Transport (E-mail)
Subject: Fw: extending ebXML scope to app-to-app integration within
enterprises


FYI!
I find this thread very relevant to TR&P's current work (("handler" <=>
service) <=> Integration System ...). Someone might like to comment back to
BP group?
Nikola

----- Original Message -----
From: "A.J. (Tony) Blazej" <blazej@ibm.net>
To: "Paul R. Levine" <plevine@telcordia.com>
Cc: <ebXML-BP@lists.oasis-open.org>
Sent: Thursday, March 23, 2000 3:59 PM
Subject: extending ebXML scope to app-to-app integration within enterprises


Some comments an the relevance of A2A to ebXML

It has been our experience in the OAG that one cannot separate B2B issues
from fundamental A2A interoperability problems.  When a "B2B context"
message hits an enterprise boundary "MAGIC" doesn't happen. A handler
has to hand off the message to an "internal" application.  If this is not
actually some piece of an ERP suite - it most certainly will engage such
a suite [or an analogous Legacy app] before the transaction is completed.
The solution methodology invoked by the "handler" can and should be the
same as is used for traditional EAI within the enterprise.  This is an area
in
which the OAG has pioneered and developed a proven solution in the course
of the last 5 years.

In our view, for web based interactions involving large to medium
organizations: E2E = B2B + A2A + A2F [where A2F is the link to factory
floor applications].   As Khwaja pointed out, there is "...tremendous
value in having a single foundation for EAI+IAI+B2B".

Bob Miller so eloquently commented: "ebXML is not about providing
specific solutions, it is about providing an XML-based foundation upon
which such solutions can be built. That foundation is as applicable to
the internal app-to-app problem as it is to the external app-to-app
problem we call B2B"

As long as "...[ebXML] does not duplicate what the OAG is doing, but
develops a specification for business process definition (BPDS) within
which the OAG business process definition will fit" remains the focus
of ebXML - then we are working together to define a pervasive solution.

We in the OAG would love to exploit such a "solution" to do what we do
best - design the CONTENT OF MESSAGES which will ride within an
ebXML "envelope" traversing ebXML compliant frameworks.

I do share Bob's concern that we resist scope creep. As someone else
observed "...ebXML will be complicated enough".

Cheers,
     Tony

A.J. (Tony) Blazej
Director of Industry Programs
Open Applications Group, Inc.
203-966-7388
ablazej@openapplications.org