OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [ebxml-dev] ebXML specifications interdendancies

[resending, sorry if this is a duplicate]
 think it is too soon to comment on what typically will be implemented by
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  near term, 
 I would expect some products to offer ebXML messaging solutions,
and they will work at a secure transport level. I would think  the  
first encounter with products may be  with  these tools, 
if  customers  are interested
in  the  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 , 
 from the other offerings/components.    I would expect  that MSHes
with CPPA functionality enabled would be interested in using
registries, for example; then they could actually benefit
at configuration and runtime from being able to retrieve objects
like BPSSes and CPA-templates and CPPs and Core components.
CPPA functionality would, IMO, be an enhancement to ebMS transport
tools. There could be standalone CPPA composition, editing, and
negotiation support tools someday. But at present, the main
point of having CPAs is in automating ebMS configuration.
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 CPP s . 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  some 
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  may be   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  with the
market for ebXML products. Eventually customers
will find what is of value, and whether component
based approaches, vast single-vendor integrative frameworks,
neither, or both, are the best ways to bundle the
Dale Moberg
-----Original Message-----
From: Anarkat, Dipan [mailto:DAnarkat@uc-council.org]
Sent: Tuesday, December 04, 2001 2:37 PM
To: Dale Moberg
Subject: RE: [ebxml-dev] ebXML specifications interdendancies

   Thanks a lot. That really betters my understanding.
This means that typically vendors would implement all modules in the ebXML stack , right ?
+ Dipan
-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Tuesday, December 04, 2001 3:59 PM
To: Anarkat, Dipan; ebxml-dev@lists.ebxml.org
Subject: RE: [ebxml-dev] ebXML specifications interdendancies

Some comments in line.
-----Original Message-----
From: Anarkat, Dipan [mailto:DAnarkat@uc-council.org]
Sent: Tuesday, December 04, 2001 12:17 PM
To: ebxml-dev@lists.ebxml.org
Subject: [ebxml-dev] ebXML specifications interdendancies

 "  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
    "  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. 
Dipan Anarkat
EC Systems Analyst
Uniform Code Council, Inc.
Tel: (609)-620-4509

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC