Re: [ebxml-dev] gorilla hair vs. beach balls

[Stefano POGLIANI <stefano.pogliani@sun.com>]

...and shared business process and agreement between partners!

As soon as we think to any activity we do during the day and which 
involves money (go and buy some bread, for instance), we start to think 
to common, shared sequences and to explicit/implicit contracts and to 
the other concepts that JJ mentions.

In order to do eBusiness with w/s, one should add what ebXML already 
added. :-)
Thus, I guess, explaining how to use w/s in an ebusiness situation would 
be as "challenging" as introducing ebXML.

/stefano

Jean-Jacques Dubray wrote:

> I can assure you that it takes no more than 50 seconds to explain the 
> differences between ebXML and web services at any business people from 
> CEO to business analysts. You just have to pronounce a few words: 
> non-repudiation, guaranteed message processing by the receiving 
> application, in addition to guaranteed message delivery, transactional 
> protocol, ...
>
> I would argue that it takes much more than an hour to explain 
> developers why web services are not enough.
>
> My 2 cents and real life experience.
>
> JJ-
>
> -----Original Message-----
> From: Adam Sroka [mailto:AdamS@rewardsplus.com]
> Sent: Monday, June 17, 2002 3:23 PM
> To: ebXML List (E-mail); ebXML-dev List (E-mail)
> Subject: RE: [ebxml-dev] gorilla hair vs. beach balls
>
> I agree with Scott's assessment below, but with one caveat: I don't 
> think that web services are that much easier to define or to describe 
> to a non-technical person than ebXML is. Rather, I think that web 
> services have been sold very well by some very influential salesmen. I 
> have used the term "web services" to sell projects within my own 
> organization, because it has become one of those buzzwords that causes 
> the ears to perk up on pointed haired bosses with titles that start 
> with "C." However, in those same conversations it has become apparent 
> to me that if I asked for a definition of "web services" from each of 
> them the answers would all be different and none would be right.
>
> In order for ebXML to have the same momentum that web services have it 
> would have to be sold by the right people, articles would have to 
> appear in all the boring business magazines that pointy haired bosses 
> like to read, and pointless metaphors would have to be created such 
> that they could be abused in boardrooms everywhere. I don't know that 
> that will ever happen. It is unfortunate, too, because ebXML would 
> certainly do a lot more for most organizations than web services 
> would. Don't get me wrong, web services are great, but in terms of the 
> real value they add to a business I don't think they're all they're 
> cracked up to be.
>
> I have attempted to sell ebXML to business folks, on occasion, and the 
> best explanation that I was able to get across was something like: 
> "It's like EDI, but with XML and web services." Obviously this is a 
> description that anyone on this list (Myself included) could tear 
> apart in a second, but it makes sense to the audience, and is close 
> enough to the truth to keep me from feeling dirty ;-) The problem with 
> this explanation is that it is hard to see where the added value comes 
> from. That, IMO, is why ebXML is hard to sell, because in order to 
> understand what makes it great you have to get under the hood, and the 
> moment you do the pointy haired bosses start snoring.
>
> Thanks,
> Adam
>
> -----Original Message-----
> From: Beach, Scott [mailto:Scott.Beach@goodrich.com]
> Sent: 14 June, 2002 13:25
> To: 'colin adam'; 'Duane Nickull'; 'Jean-Jacques Dubray'
> Cc: 'ebxml org'; 'ebtwg-bps@lists.ebtwg.org'
> Subject: RE: [ebxml-dev] gorilla hair vs. beach balls
>
> The crux of the issue... IT managers "think" they understand the 
> concept of
> web services (whether true or not). Major mainstream vendors are pushing
> web services(IBM,BEA,Microsoft, etc) as the future of web 
> interactions, not
> ebXML (not that the two play exactly the same role anyway). I've yet 
> to see
> anyone capable of explaining ebXML to an IT executive without taking 
> an hour
> and taking the conversation to such a technical level that the executive
> becomes lost in the details and stops caring. Does ebXML "define" more 
> than
> web services? Absolutely. Does this make it easier to sell as a concept?
> Absolutely not.
>
> ebXML simply lacks an "elevator speech" that is compelling to IT 
> executives.
> Web services doesn't suffer from this same marketing paralysis. Another
> case where better technologically doesn't correlate to more successful.
>
> -----Original Message-----
> From: colin adam [mailto:colin.adam@webservices.org]
> Sent: Friday, June 14, 2002 1:17 PM
> To: 'Duane Nickull'; 'Jean-Jacques Dubray'
> Cc: 'ebxml org'; ebtwg-bps@lists.ebtwg.org
> Subject: RE: [ebxml-dev] gorilla hair vs. beach balls
>
> Duane,
>
> Interesting choice of title for a news posting. Please give me a chance
> to respond before you jump to conclusions.
>
> Anyway, I think we misunderstand each other. I see web services vs ebXML
> as asking this question...
>
> Does a person who wants to set up a b2b exchange think about a web
> services based solution or an ebXML solution. I can see projects where
> one of the other would be more suitable. But I would certainly consider
> both in some circumstances. On the ground I think this is happening.
>
> But before you get annoyed at this statement please consider how we both
> define web services. I use it as a term to refer to soap, wsdl, uddi and
> all products broadly based on those protocols also. The ws-i.org I would
> say is a "web services group" etc.. blue titan's mission critical
> network products is a "web services product"...
>
> Generally since ebXML uses standards above the core three, I see them as
> a separate entity. Connected but separate. I would call a ebxml product
> an "ebXML product", not a "web services" product. This is just my
> opinion and I believe the general community opinion.
>
> From what I see there seems to be a general split in the industry
> between "web services" products (things that use the protocols above)
> and those that use ebXML. A web services product is for example an IDE
> that lets you create web services like VS .Net etc..
>
> So, the wrongs and rights of a poll that uses these terms is a
> discussion, but is that the discussion we are having here..
>
> Or are we saying that on no basis can there ever be any competition
> between an "web services" product or and "ebxml product"...
>
> Finally, please understand webservices.org is my own private website,
> run off my own server, previously was a blog for my interests in soap
> but has recently attracted some sponsors to help with running costs, and
> I have no connections via jobs to any companies involved with web
> services and have never worked for web services journal.
>
> I work hard on my site, and ask that you only take a few moments to
> consider my views and perspective. (this goes to all the flames I seem
> to have received this afternoon also).
>
> Regards
> colin
>
>> -----Original Message-----
>> From: Duane Nickull [mailto:duane@xmlglobal.com]
>> Sent: 14 June 2002 17:38
>> To: Jean-Jacques Dubray
>> Cc: 'ebxml org'; ebtwg-bps@lists.ebtwg.org
>> Subject: [ebxml-dev] gorilla hair vs. beach balls
>>
>>
>> Jean-Jacques Dubray wrote:
>> >
>> > Webservices.org is running a poll about ebXML vs WS. Cast you
> opinion.
>> >
>> > http://www.webservices.org/index.php/poll/result/27
>> >>>>>>>>>>>>>>
>>
>>
>> I can't believe someone actually started a poll on this subject.
>>
>> I posted the following:
>>
>> This poll is seriously flawed. Let me set the record straight on a few
>> thing.
>>
>> A Web service is paramount to an interface to a programmatic function.
>> Since most OO programming
>> today uses the concept of classes, most code that exists has an
>> interface to send information our and
>> receive a return type back from the class. Web Services abstracts the
>> communication to a
>> programmatic class one step further by communicating to the class by
>> using XML over SOAP (which is
>> really HTTP with some XML extensions).
>>
>> ebXML, on the other hand, is an infrastructure that facilitates
>> interoperability between electronic
>> business users. ebXML will probably be largely implemented using OO
>> techniques and methodologies. It is
>> therefore quite conceivable that ebXML could easily be implemented as
> a
>> set of web services, although
>> it is probably not logical to do so with the current state of WS
> (WSDL)
>> given lack of thread tracking,
>> reliable messaging and security. There is alos an added burden of
>> network lag for each call to a logical
>> piece of work.
>>
>> This poll is seriously flawed and will probably hurt both WS and
> ebXML.
>> I would urge it to be taken down.
>>
>> Maybe replace it with a poll of gorilla hair vs. beach balls - a
> similar
>> comparative study.
>>
>> Duane Nickull
>>
>>
>> --
>> VP Strategic Relations,
>> Technologies Evangelist
>> XML Global Technologies
>> ****************************
>> ebXML software downloads - http://www.xmlglobal.com/prod/
>>
>> ----------------------------------------------------------------
>> The ebxml-dev list is sponsored by OASIS.
>> To subscribe or unsubscribe from this elist use the subscription
>> manager: <http://lists.ebxml.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> The ebxml-dev list is sponsored by OASIS.
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.ebxml.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> The ebxml-dev list is sponsored by OASIS.
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.ebxml.org/ob/adm.pl>
>

-- 
------------------------------------------------------------------------

Stefano Pogliani
Senior Integration Architect
XML Web Services & Industry Initiatives
SUN Microsystems

%
GSM :
(+33).608.43.12.21
(
Phone :
(+33).450.20.10.25
+
Email :
stefano.pogliani@sun.com <mailto:stefano.pogliani@sun.com>