RE: [ebxml-dev] Re: ebXML doubts

[Fraser Goffin <goffinf@hotmail.com>]

James,

I don't see these as mutually exclusive, neither am I naive enough not to 
'arrive prepared' to deal with others who would use FUD and cast 
unsubstantiated aspersions around to undermine a valid argument (i.e. sway 
the undecided voter through fear/cost/etc..). I would hope that in debate 
everyone would act professionally (even as grown-ups) but sadly that isn't 
always the case, and motivations are very often obscure.

So all I'm asking for is some objective and dis-passionate facts to suggest 
why [for example] ebXML MS :-

- isn't an over engineered, too complex solution
- is a ratified and supported standard
- does have wide industry and technology vendor support
- does have 'off the shelf' reference implementations available
- does look to re-use rather than re-invent other standards/protocols
- isn't in conflict with SOAP, WSDL, UDDI, et al
- doesn't undermine interop
- does encourage good message design
- etc ..

I like the idea of providing 'use cases' which whilst demonstrating what 
ebXML provides, allow others to comment on how they could be met via 
alternate means.

I don't mind in the least identifying ebXML short-falls, but I do want to be 
able to support my own enthuiasm.

I'll give you a 'for instance' that might help to illustrate :-

at a recent technical review session (at which those technically competant 
to discuss details are typically excluded - so are represented by project 
managers carrying with them recommendations from their designers - I don't 
make the rules) in response to my reps' proposal that ebXML MS be adopted as 
a standard protocol, a rep from another company responded with - 'I support 
this proposal'. Under further scrutiny however, this member had to admit 
that they had no idea why, they had just been told to by their technicians 
back at base. You can imagine what ensued from the other members who either 
remained to be convinced or were already against. If I'm not allowed to 
attend, I want to be confident that my rep at least has some (yes ammunition 
if you like) to make a strong and well founded case. If its still not 
accepted, well at least this is slightly less difficult to swallow than 
having him/her return with a 'sorry ebXML didn't make it' and the reasons 
were FUD.

Fraser





>From: "James Governor" <jgovernor@red-monk.com>
>To: "Fraser Goffin" <goffinf@hotmail.com>
>Subject: RE: [ebxml-dev] Re: ebXML doubts
>Date: Fri, 3 Jan 2003 05:46:34 -0600
>
>Ammo--Anything objective and dispassionate?
>
>James Governor
>RedMonk
>(+44) 207 254 7371
>
>
>-----Original Message-----
>From: Fraser Goffin [mailto:goffinf@hotmail.com]
>Sent: 02 January 2003 21:06
>To: susy@sun.com
>Cc: ebxml-dev@lists.ebxml.org
>Subject: [ebxml-dev] Re: ebXML doubts
>
>Susan,
>
>I have been evangelising the use of ebXML MS for about 2 years within my
>own
>organisation. Last year Dick Brooks and Ian Jones were kind enough to
>come
>along and present to a reasonably large group of internal IT and
>business
>user staff.
>
>I may not have explained it all that well in my initial note but I have
>prepared a number of rebuttal statement that I suggest demonstrate the
>arguments put forward are not well thought through. Nonetheless as I'm
>sure
>you're already aware, convincing others that adoption of ebXML is a
>sound
>decision is not all that easy. As I said, the principle arguments are
>usually a) too complex, b) never heard of it - therefore not mainstream
>-
>therefore no 'out of the box interop', c) it's not GXA (or WSE in the
>latest
>terminolgy). Also of course many texts (and implementations) focus on
>relatively trivial messaging patterns.
>
>I have taken to presenting use cases and asking how these will be met by
>
>alternatives. What often comes back are similar ideas to ebXML MS but
>using
>proprietary headers and sometimes SOAP Body elements. I then move on to
>talk
>about tenets like :-
>
>- Re-invent as little as possible
>- Re-use as much as possible
>
>and about how interop is based in agreement of protocol standards
>(although
>I would have to agree that interop for all practical purposes is as much
>
>about the consistent implementation of such standards in mainstream
>toolkits
>- and although there are implementations of ebXML MS around they are not
>as
>high profile as Websphere and .Net - of course its not that hard to
>build an
>ebXML MS implementation - I have one in VB6 which we are using in
>production).
>
>Inerop is a two way street though. I am just as interested in getting
>ebXML
>positioned alongside the WS-xx specs (even though some people seem to
>regard
>these as 'standards already !), and if that means ebXML has to be less
>brass-necked about some areas then so be it. I may not like the politics
>of
>some organisations, but if they give me what I want, I'll take it every
>time
>and twice on Sundays - and so will my business customers (IT is a
>practical
>profession). One thing I would like to see is ebXML MS allow the use of
>DIME/WS-Attachments as well as SwA/Multi-part MIME for example. I'd like
>to
>be able to say, Microsoft doesn't support ebXML MS - so what ! (indeed I
>
>have made this point a number of times and don't restrict it just to
>Microsoft (IBM are also not hugely encouraging).
>
>Anyway, to cut a long reply short, I think what I am looking for is some
>new
>ammo. The people involved have heard my arguments me ad'nausism so I was
>
>hoping that you guys could provide me a few objective and dispasssionate
>
>hard to refute facts.
>
>How about it ?
>
>Regards
>
>Fraser.
>
>
>
> >From: Susan Struble <susy@sun.com>
> >To: goffinf@hotmail.com
> >Subject: ebXML doubts
> >Date: Thu, 02 Jan 2003 12:00:36 -0800
> >
>
>
>_________________________________________________________________
>The new MSN 8: smart spam protection and 2 months FREE*
>http://join.msn.com/?page=features/junkmail


_________________________________________________________________
MSN 8: advanced junk mail protection and 2 months FREE*. 
http://join.msn.com/?page=features/junkmail