David
[snip]
Dale
Moberg>
What would
converge really mean here? An interesting question and
here are some
ideas to maybe move the discussion forward a bit:
I think WSDL and CPPA documents (especially CPA
template documents)
are analogous functionally.
WSDL does some things not currently
found
in
CPPA and the converse is likewise true. I think there may be
other
profile/configuration formats emerging in the WSxx
camp,
and when that happens, we can see which formats
can do
what things. CPPA is being built out to
handle
PKI agreements, as well as transports,
packaging, and agreements about the
business signals for nonrepudiation and so
on.
So
far, it would not be a huge complication for software
to be able to make use of either format for
configuration,
depending on whether the software was being
configured for
a "web
service" or a "collaboration" mode.
That
is, the underlying technologies are fairly
similar
(SOAP-centric, HTTP-mainly, and so
on)
WSDL
can better handle specifying RPC style parameter list
exchanges
by
means of its Port and Binding constructs. (The only CPPA analog
here
is the
Action and ActionBinding constructs, but these do not get
expanded into inputs and outputs, as the WS-IDL
analogy motivates.)
CPA is
geared for exchange of larger record sets, possibly including
multiple kinds of data
(addresses, parts list, prices, billing terms, etc) and
to handle the signals
and
more elaborate security options of collaborations. It lets the
schemas
(in
the packaging elements) point to specifics about the data being
transported.
Currently, CPPA lets a MSH be entirely open
to
talk to any BSI on the local side, (as does ebXML
as a whole)
and
only provides service and action values which, along with
the
To,
From, MessageId, ConversationId etc values , can be
used
in discriminating the local entry point(s), and
the local entry point(s) access
implementation (JMS queues, file system and directory,
pipes, IPC, RPC,
RMI,
ORB, DCOM, etc, etc). It might be nice to document BSI
interface
details, but it would _not_ be something that fits the
current intent of the CPPA.
(which
is to promote configuration of both sides in a b2b collaboration
so
that
they have interoperable implementations). It is not exactly your
trading
partnet's concern how you hook up you communications to
your back end apps.
It
would be unfortunate if there was an incredible proliferation
of
configuration and
interface discovery formats,
but it
may not be inappropriate to have a couple
of specialized, customized formats geared to
different configuration
and
discovery problems. Sometimes merging distinct sets of functions into
a big
kitchen-sink style schema just results in
something
too
complex to wade through, and the learning curve of figuring
out
which part is used for what purpose is just not worth
bothering with enduring, and so the
approach fails to catch on.
I do
not know whether it is important for CPPA notations to
provide
any
support for RPC like parameter lists, or for enhanced
representations of the local service interface points.
Certainly
the
current focus of CPPA is on the b2b
communication/security/datatype
configuration, and not on the integration to the
local application.
Similarly, I am not certain whether WSDL needs to get
involved in
describing capabilities and prerequisites for digital
enveloping,
non
repudiation of receipt, reliable messaging, and so on.
But I
agree that it is worthwhile being aware
of the
danger of creating useless reduplications.
And, this may be an area in which a merged
approach will work also,
depending on future developments in Oasis and
W3C.
Certainly one potential direction for CPPA is extending
its
notations to actively support other BP flow notations
beyond BPSS,
and
other TRP options than those found in ebMS, and
possibly
a WSDL
(or parts thereof) could be pointed at and those
references
would replace ebMS specifics found under the
current ebXMLBinding tag.
So
"merging" might take several different forms quite different
from
subsuming one schema inside another, and reducing by
one
the
number of acronyms we have to track.
So, I do definitely think that
convergence is possible, but it might
follow several
divergent paths. I don't myself see which
convergence-track results in the
most "synergistic" outcome, but I
agree we should be alert to the dangers of
proliferation and keep an eye
open for re-use options. I hope to participate in
the web services group
dealing with WSDL when it gets going, and I would enjoy
hearing
how other people image that
the convergence/integration
might have beneficial outcomes.
Dale Moberg
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC