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: AW: AW: [ebxml-dev] gorilla hair vs. beach balls


This would be my proposal on the core document structure for an ebXML
business whitepaper. As far as my experience goes, this is what I need
to tell business people (and also what I am allowed to tell:-).

I am not sure, whether the business whitepaper should contain a
technical perspective at all. In my experience the complexity of the
technology of the standard is most adequate to threaten your business
audience away;-)

Best Regards,

ebXML Business Whitepaper

1. Introduction
What is ebXML, what-for is ebXML, how does it work (basically) and
especially how do all the pieces fit together.

1.1 The ebXML Genesis
How and why was ebXML born and "raised". "Who" is ebXML? (This chapter
would give an idea of the business "reliability" of ebXML also of the
meaning and the business environment. (Can I trust in ebXML still be
there in a year from today?))

2. e(bXML) Business
How does ebXML fit for modern e-business facts and tendencies, what are
the advantages and disadvantages. 

2.1 ebXML and B2B (EDI)
What are the reasons for ebXML in the B2B arena, how does it fit for EDI
purposes, what can I save and what can I win using ebXML in my B2B

2.2 ebXML and B2C
What are the reasons for ebXML in the B2C arena, how does it fit for
end-customer relations, what can I save and what can I win using ebXML
in my B2C scenarios.

2.3 A new boy is in town
I am not that sure about the header (:-) but I guess we need a chapter
to discuss the relations from ebXML to the well-known and/or hype topics
like WebServices, BizTalk (if we are allowed to?)

3. The road toward ebXML
What is it, what I (really) need to make ebXML (from a business
perspective) productive. What are the obligatory, what are the
acceptable and what are the "tolerable" steps to undertake. What are the
deliverables, what is the impact and the opportunities.

4. ebXML in Practice
"Real" world examples, maybe user stories. I would suggest one for B2B
and one for B2C. I also would recommend to point out the existence (or
possibility) of "migration" paths and milestones thus this is for an
ebXML implementation in already present B2B and B2C environments


-----Ursprüngliche Nachricht-----
Von: mconde@mindspring.com [mailto:mconde@mindspring.com]
Gesendet: Mittwoch, 19. Juni 2002 12:40
An: Frank. Christopher
Cc: gummi@dimonsoftware.com; ebxml-dev
Betreff: Re: AW: [ebxml-dev] gorilla hair vs. beach balls

Hi folks.

I agree on the need for a "practical" paper. Here at the CDC (Centers
for Disease Control) we are using ebXML as the messaging layer for
moving public health surveillance data around.

I often see a lot of confusion concerning why use ebXML verses just a
web service or simple XML over HTTP. I have only seen one ot two weak
papers on this.

The paper should discuss some real examples on how the standard
executes. Also move into a technical section to explain how all of us
have implemented the "moving" standard to make it stable. For example we
employ strong authentication and accomidate many types of access

Someone take a crack at the doc structure and I too would be interested
in contributing.

Mark Conde
Technical Architect
On Wed, 19 Jun 2002 12:20:30 +0200 "Frank. Christopher"
<C.Frank@seeburger.de> wrote:


You are right.

I did a few lectures (presentations) for customers and co-workers on
ebXML for both business and technical perspective (what is more my scope
I confess). But if I can be of service, I am willing to participate.

Best Regards,

-----Ursprüngliche Nachricht-----
Von: gummi@dimonsoftware.com [mailto:gummi@dimonsoftware.com]
Gesendet: Mittwoch, 19. Juni 2002 11:43
An: ebxml-dev
Betreff: RE: [ebxml-dev] gorilla hair vs. beach balls

We all seem to agree that a business white paper is needed
for ebXML, so why don't we just write it?
I'm willing to contribute text, if anyone is interested in
doing collaborated work on this.

More work, less talk :-)

(I totally agree that too few business people know what ebXML
is, what the benefits are and why they are to use ebXML,
which they often haven't heard about, instead of BizTalk, which
they all know about, or some other method for their ebiz)

Gummi Haf

Gudmundur Hafsteinsson - gummi@dimonsoftware.com
Dimon Software - www.dimonsoftware.com

"... 'cause that's what tiggers do the best!" - Tigger

|        |          Adrian Robinson    |
|        |          <adrian.robinson@ge|
|        |          nie.co.uk>         |
|        |                             |
|        |          19.06.2002 08:31   |
|        |                             |
  |       To:     ebxml-dev <ebxml-dev@lists.ebxml.org>
  |       cc:
  |       Subject:     RE: [ebxml-dev] gorilla hair vs. beach balls

Me too!

I have a growing number of clients that have all heard of ebXML but
that it is a data structure standard and are more than happy to
it - until I explain that this part of the project hasn't even got off
ground yet. The next question I get is "So what is it?".  If I had a
that I could pass on to these business minds, the least it would do is
sustain their interest.

By the way, does anyone know when we will see something of the data
structure standards - if at all?

Thanks in advance,

-----Original Message-----
From: Dieter E. Jenz [mailto:dejenz@jenzundpartner.de]
Sent: 19 June 2002 08:59
To: ebxml-dev
Subject: Re: [ebxml-dev] gorilla hair vs. beach balls

I wholeheartedly agree. In my view, there is a definitive need for a
paper targeted at business people. A requirements document is just not
enough, since, among other things, it doesn't speak business people's
language. For example, I cannot see what a manager of a Chamber of
Commerce & Trade or an industry consortium, who would be ideally suited
to relay the message to numeous business people, could gain from a
requirements document or a technical architecture document.

Business collaboration is a strategic issue and has to do with aligning
IT with business. Therefore, a paper needs to unfold how ebXML fits in
with the business environment and talk about a clear-cut ROI

To me, the biggest obstacle at this time seems to be that few business
people seem to know about ebXML at all. This, at least, is my experience
from talking to business people. While commercial software vendors are
committed to spending two or three times more money for marketing &
sales than for R&D, the ebXML marketing effort seems to be minimal.



Dieter E. Jenz
Jenz & Partner GmbH
Hainstr. 40a
63526 Erlensee, Germany
Phone: +49-6183-9100-11
Email: dejenz@jenzundpartner.de

Martin W Sachs wrote:

 > Jacques,
 > I think that the point is that you need different words and
 > different styles of presentation to business people and to
 > Right now, all we have in the way of overall descriptions of ebXML
 > the Requirements document and the ebXML Architecture document. Both
 > those speak to members of the ebXML teams but are good neither for
 > business people nor for developers.
 > Regards,
 > Marty

 > Martin W. Sachs
 > IBM T. J. Watson Research Center
 > P. O. B. 704
 > Yorktown Hts, NY 10598
 > 914-784-7287; IBM tie line 863-7287
 > Notes address: Martin W Sachs/Watson/IBM
 > Internet address: mwsachs @ us.ibm.com

 > Jean-Jacques Dubray <jjd@eigner.com>
 >                         *Jean-Jacques Dubray <jjd@eigner.com>*
 >                         06/18/2002 12:21 AM
 > To: "'Adam Sroka'" <AdamS@rewardsplus.com>,
 > "'ebXML-dev List (E-mail)'" <ebxml-dev@lists.ebxml.org>
 > cc:
 > Subject: RE: [ebxml-dev] gorilla hair vs. beach balls
 > You must be a developer right? JMS ain't ebXML and as you probably
 > missed it: guaranteed message delivery at the transport level has
 > nothing to do with guaranteed processing of your messaging by the
 > receiving application (essential for synchronization of the business
 > state), and "business transaction" means that we both agree that we
 > succeeded or failed in synchronizing our state. Could you do business
 > in an environment where someone could claim that you made this
 > commitment while the other one refuses to accept it and no-one has
 > ways to prove it? Those are not big words, they are real business
 > concepts that every business person understand on a snap. I even
 > that a developer could not care less, for him/her a call is a call,
 > should succeed otherwise it is a bug, or maybe you try the call until
 > it succeeds.
 > JJ-
 > -----Original Message-----*
 > From:* Adam Sroka [mailto:AdamS@rewardsplus.com] *
 > Sent:* Monday, June 17, 2002 3:59 PM*
 > To:* ebXML-dev List (E-mail)*
 > Subject:* RE: [ebxml-dev] gorilla hair vs. beach balls
 > I agree, pronouncing big words is a great way to get business people
 > to agree with you - mostly because they don't know what they mean but
 > are afraid to admit it ;-) Once you leave the room, though, they
 > even bother to file it away (I believe the cliche "In one ear and out
 > the other" is appropriate here.) In the end, whether the project goes
 > or not will have very little to do with these words.
 > I tried to sell a JMS project a few months ago and was very surprised
 > at how little weight words like "guaranteed messaging," and
 > "transaction" carried with that audience. In the end, the solution
 > they chose ignored these principles entirely, not because the
 > didn't need them, but because I did an inadequate job of selling
 > That is my experience, and, of course, yours may vary.
 > Regards,
 > Adam
 >             -----Original Message-----*
 >             From:* Jean-Jacques Dubray [mailto:jjd@eigner.com]*
 >             Sent:* 17 June, 2002 15:44*
 >             To:* 'Adam Sroka'; 'ebXML List (E-mail)'; 'ebXML-dev List
 >             (E-mail)'*
 >             Subject:* RE: [ebxml-dev] gorilla hair vs. beach balls
 >             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
 >             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,
 >             those same conversations it has become apparent to me
 >             if I asked for a definition of "web services" from each
 >             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
 >             and pointless metaphors would have to be created such
 >             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
 >             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
 >             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
 >             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
 >             the executive
 >             becomes lost in the details and stops caring. Does ebXML
 >             "define" more than
 >             web services? Absolutely. Does this make it easier to
 >             as a concept?
 >             Absolutely not.
 >             ebXML simply lacks an "elevator speech" that is
 >             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
 >             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
 >             Or are we saying that on no basis can there ever be any
 >             competition
 >             between an "web services" product or and "ebxml
 >             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
 >             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 -
 >             >
 >             >
 >             > 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_>

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>

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>

[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