Re: [ebxml-mktg-sc] META ebXML report

[Sang Shin <sang.shin@sun.com>]

Yader, Mark (GXS) wrote:
> Don't shoot me, but I think the analogy of ebXML and WS to the OSI and 
> Internet protocols is probably going to come true. ebXML's technical 
> architecture and roadmap for e-business is great, but the world may not 
> be ready for its "heavy" implementation in terms of complex standards 
> (like the OSI standards.....X.400, X.500, etc).

Mark,

Thanks for your thought.  (If we have to shoot you,
we probably have to shoot thousands if not millions. :-))
My thoughts on comparing ebXML to OSI are as following:

-OSI failed due to several reasons, one of which is lack of
  vendor support.  As we all know, it is all chicken and egg.
  No products no users, no products and no users.  This is
  the area something can be done differently in ebXML, however.
  That is why vendor products, adoption and real-life success stories
  are extremely critical to the eventual success of ebXML
  especially at this stage of the game. (I admit that we
  have a long way to go.)

-Another reason OSI failed was in fact the specs were so
  complex (trying to be everything to everyone) and
  vaguely defined, nobody expected any reasonable level
  of interoperability.  As networking protocol standards,
  this is a recipe of failure.  Again, in ebXML, we
  have several interoperability efforts going on right now
  making sure vendor implementations interoperate. I
  think this is very important difference of ebXML from
  OSI.

-When OSI is being devised, there was a viable and working
  alternative, TCP/IP.  Many people debate whether the Web services
  of today can be in fact a viable alternative to ebXML
  in the area of electronic business framework. My personal
  opinion is that Web services of today (SOAP over SSL)
  simply do not provide the features needed for business
  transactions.

-In terms of complexity of ebXML, ebXML has never been
  positioned for lightweight operations in the same sensse
  that Message Oriented Middleware (MOM) have never
  been positioned as lightweight operations.  Yet,
  "highly reliable, highly secure" business transactions
  still require the presence of MOM in many business
  organizations.  Now in my opinion, ebXML is trying
  to extend scope of MOM into the internet scale in
  a standard and more comprehensive fashion.

-Another aspect regarding complexity.  In my opinion,
  complexity of any technology becomes an issue only
  when the complexity gets exposed to end users. An
  example is our phone network.  Internally, I am sure
  it is very complext but as an end user, it is so
  simple to use the phone.  In fact, all the complexity
  at the backend must be required to make my end
  user experience simple and straight-forward.  Now,
  I would like to use same logic here for ebXML.  As long
  as the complexity resides in vendor implementations,
  it should not an issue.  In fact, the complexity
  of the implementation should be the value that
  ebXML provides compared to, let's say, Web services
  of today.  For example, if you are trying to send
  $1M purchase order document to your business partner
  in a secure and "once and only once" reliabile
  fashion, the web services applications have to
  handle all these "security" and "reliability" logic
  in their code, which also cannot provide interoperability
  since everybody implements things differently.

-ebXML implementations can take many forms.  In fact,
  this is the area where vendors can compete.
  One simple scenario we talked about as one way to
  allow SMEs to participate in ebXML based electronic
  business framework is "Java applet" or "plug-in"
  that can be downloadable from business partner's
  website during runtime, yet captures all the functionalities
  that are defined in pre-defined CPA.  The SME
  does not even know s/he is doing ebXML.  It is
  all hidden in the implementation.  The key point is
  complexity can be hidden in the implementation.

Thanks.

-Sang

> 
> On a related subject, I'd like your opinion. While I have been pushing 
> ebXML and WS on my company, they continue to ask me: So what do you 
> think is the next "killer app" in B2B that will require these new 
> technologies. After thinking about this, I came up with the following 
> run-on sentence filled with techie acronyms: Peer-To-Peer (Distributed) 
> Business Process Management and Document Orchestration based on the 
> Semantic Web, XML Documents and Web Services.
> 
> My question is: Does this sound like Star Wars or does it make any sense ?
> 
> Your opinions appreciated.
> 
> Regards.......Mark
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Carol Geyer [mailto:carol.geyer@oasis-open.org]
> Sent: Tuesday, February 04, 2003 11:13 AM
> To: ebxml-mktg-sc@lists.ebxml.org
> Subject: [ebxml-mktg-sc] META ebXML report
> 
> 
> CONFIDENTIAL: ebXML JMT Steering Committee
> 
> Attached is a preview version of a META Group research piece on ebXML.
> It will be followed shortly by a longer paper that
> will go into more detail. The author has requested comments and feedback
> from OASIS, as the research is ongoing and there is still debate within
> META about the position expressed.
> 
> Patrick and I will be responding to META later this week. If anyone from
> the JMT SC would like to review and send me comments on the attached, I
> will forward them to META and use them in our discussions.
> 
> Many thanks,
> Carol
> 


-- 
---------------------------------------------
Sang Shin                       sang.shin@sun.com
Strategic Market Development    (781) 442-0531(Work)
Sun Microsystems, Inc.          (781) 993-1136(Fax)

http://www.plurb.com/webservices/index.html#Bio
http://www.plurb.com/misc/te/SangSchedule.html
(Life is worth living... with Passion!)
---------------------------------------------