|
I
think it is too soon to comment on what typically will be implemented
by
vendors.
Within
Oasis, work continues on adding some supporting
specifications
within
groups. Work also continues to enhance alignment so that
when
all aspects are implemented, there can be some added
benefit.
Clearly the ebMS spec provides fairly basic functionality for moving
business
data
interoperably and securely over the internet. In the short term,
I
would
expect some products to offer ebXML messaging solutions,
and
they will work at a secure transport level. I would think end
users
first
encounter with products may be these tools, if they are
interested
in
actual movement of data.
Other
products may offer BPSS editing/composition tools. These
could
be
used for business analyst documentation independently of
actually
being
"used" by runtimes. Possibly these tools are already being
used.
Registry products (servers or client side) might exist
independently.
CPPA
functionality would, IMO, be an enhancement to ebMS
transport
tools.
But to make the CPPA spec more useful, work on negotiation
continues
to
define the actual messages and processes used in CPA
negotiation
from
templates or CPPs. The ebXML registry will define a
retrieval
mechanism for CPA templates or CPPS. A UDDI
WSDL-defined
service could be defined to provide similar functionality, but
is
still
a future as an official spec.
I
think that the major pieces of the ebXML framework were
completed
at the
end of the ebXML initiative. A lot of residual pieces will
enhance
the alignment of the components if and when they get used
together.
I hope
this addresses your question. There is room here, IMO, for
components to work now in a standalone mode. There is room
moving
forward for people to produce a suite of components, already
integrated.
I am
not a product marketing expert, however, so I will let
others
predict what products will dominate and when. At the
moment,
some
analysts are attempting to create the trough of
disillusionment,
right
on schedule, so we will have to weather those outbursts
before
we know what is really going on.
Dale
Moberg
Dale,
Thanks a lot. That really betters my
understanding.
This
means that typically vendors would implement all modules in the ebXML stack ,
right ?
+
Dipan
Some
comments in line.
" Hi,
"
I am trying to assess the functional
interdependancies b/w the diferent systems in the ebXML stack from an
implementation standpoint, used in an e-business
framework.
"
As we know, the ebCPPA spec does specify how a CPA is negotiated between 2
trading partners.
DaleMoberg> Negotiation is currently
being specified in the OASIS ebxml-cppa TC. There was
no
normative definition at the CPPA 1.0
level. There was a lot of information about how to use CPA
templates
or even to compose CPPs to arrive at
CPAs, but you were on your own in exchanging these
documents.
" I also understood from a
couple of vendors that the CPA instance XML has to be loaded into the internal
database (any form) of the MSH. It really doesnt matter how the CPA is
negotiated or for that matter even if it is in XML form.
DaleMoberg> Typically for MSHes that
support CPAs, importing a CPA and using it to populate the
MSH's
configuration "database" would be an
operation that would be done, obviously. Just how much of the information
is
actually used might vary. Minimally you
will need to get the URLs of the other side. You might pull
out
other information.The software might
then need to ask a user for some other information. You could
pull
out certificates, trust anchors,
signature formats and conventions, and a whole lot of
stuff.
" All that is required
is a conclusion representing the CPA that can be in any format, as long as it
can be loaded into the internal database of the MSH as provided by the
vendor.
DaleMoberg> If you are talking about
what a MSH could get away with, it need not
serialize any information it uses in
configuration.
That is, you could use property sheets
or wizards or whatever to
let a user do the configuration. Most
implementations will
have this capability unless they are
telepathic. What importing a
CPA allows is drastically reducing what
the user has
to configure, what choices on security
(etc) are forced on users,
how to get certificates loaded, and so
on. The CPA and CPP are
standardized
XML schemas used to define ways to
exchange information expressed
in XML that is used for
configuration. They also have signatures
so
that you trust the information, and
hooks to other potentially useful
information.
" This means that an
ebMS compliant MSH has also to be compliant with the
ebCPPA. "
DaleMoberg> It
means that an ebMS compliant MSH has to be configurable as a ebMS
MSH.
Compliance
with ebCPPA means that XML inputs or outputs conform to the schemas
that
have been defined. Since the ebMS is not required to
serialize its configuration information
in
any format, it does not have to conform to the ebCPPA compliance clause. I
think you
are
trying to find some dependency here, when both groups have been reasonably
careful
to
explain how to use specifications together and separately. It would be far
more useful
to
consider what you gain and lose by not using certain ebXML modules rather than
trying
to
see how little you can get away with. You will have to configure the software
somehow.
You
can invest in automating the process for a community or you can let them
struggle
and
set it up themselves (with consultants).
" Also since
the ebCPP and ebCPA instances identify the Business Processes
in an ebBPSS instance, it means that the ebMS compliant MSH will also
have to be compliant with the ebBPSS if it has perform the intended function
of being able to validate and process ebMS TR&P messages . "
DaleMoberg> No. No real use needs to
be made of the information about Business Processes, even if
there
is a pointer to it. Otherwise, a dummy
BPSS can be set up in 15 minutes or so if you really want to
make
certain the pointer resolved.I will even
send you one.
" This
means that the ebMS TR&P cannot be used independantly for TR&P and
forces you to use ebCPPA and ebBPSS. "
DaleMoberg> No. If a web page has
links on it, does that mean you cannot view the page without clicking on the
links?
You are really reaching here to find a
dependency, when you should just be asking yourself: what is the value
of
using this? Could there be some ROI if
we used this? And so on. What is the point ot these questions
really?
"As such, even though an
agreement may not be required between trading partners , we still need a bare
bones 'void agreement' .
Is my understanding right, or am I missing a point here !? "
DaleMoberg> No and
Yes.
|