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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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


Subject: RE: Xtreme Ease-of-Implementation


Cory,

Nothing in my proposal should be interpreted as requiring
monolothic implementation or disallowing off-the-shelf
components.  

Thanks for the opportunity to clarify,
Bob Haugen

-----Original Message-----
From:	Cory Casanave [SMTP:cory-c@dataaccess.com]
Sent:	Monday, December 04, 2000 10:19 AM
To:	Bob Haugen; 'ebXML-BP@llists.ebxml.org'
Subject:	RE: Xtreme Ease-of-Implementation

Bob,
Thanks for starting this - I think how this is all to be used is a valuable
perspective.  I certainly agree with your perspective that this needs to be
very ease to use and almost instant to put in place. I have some different
ideas but have not figured out if they are substantially different or not.
The basic mindset difference is one of a component technology as opposed to
a "collaboration protocol package" which sounds somewhat monolithic (but may
not be).

I would hope that "packages" of this sort would not have to come from "the
big guy" but may come as off-the-shelf components in an open marketplace,
allowing "the small guy" to deal with any big guy.  This would, of course,
also allow any big guy to supply such a component suite.

Which brings me to the second part, that a "collaboration protocol package"
should not be one thing but a suite of components that address various
business and technical requirements, allowing the user to build on or
substitute components as they need to support their business processes or
integrate with their information system.  These components should follow the
business functionality "units" (E.G. Commercial transaction to collaboration
protocol) as seen in the modeling.  This should all be tied together with
high-level component tooling that allows diverse implementations of standard
protocols.

We should also seek to separate the business componentry from the technical
componentry, so that the business functionality can be used for multiple
middlewares, not just EbXml (I love it, but lets recognize the diverse
nature of the world).

This kind of component tooling and marketplace would serve the big guy and
small guy alike, invigorating the acceptance of electronic business.

Regards,
Cory



[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