RE: [ebxml-dev] Re: ebXML doubts - Project Requirements

[Ronald van Kuijk <rvkuijk@abz.nl>]

Title: RE: [ebxml-dev] Re: ebXML doubts - Project Requirements

I couldn't agree more. These are exactely the reasons why we choose ebMS. While we were drawing up the requirements and put them next to ebMS, they fitted almost perfectly. There were a few things we had to extend ebMS with (yes, ebMS allows extensions through the use of namespaces) for backwards compatibility with a legacy x.400 system.

> -----Oorspronkelijk bericht-----
> Van: Richard Moon [mailto:richardjmoon@hotmail.com]
> Verzonden: zaterdag 4 januari 2003 23:21
> Aan: goffinf@hotmail.com
> CC: ebxml-dev@lists.ebxml.org
> Onderwerp: [ebxml-dev] Re: ebXML doubts - Project Requirements
>
>
> Fraser,
>
> I would suggest focusing attention on the project
> requirements and how ebMS
> extends the capabilities of SOAP in order to meet those requirements.
>
> Highlight the fact that you are in agreement regarding the
> use of SOAP with
> Attachments (SWA) and then go on to discuss how SOAP was
> designed to be
> simple and extensible so that it could be enhanced to provide
> the full
> functionality required by real-world B2B projects.  Position
> ebMS as an
> extension of SWA that will address specific project requirements with
> respect to reliable messaging and security.
>
> If there are requirements pertaining to message acknowledgement,
> retransmission and timeout, message persistency,
> non-repudiation, error
> notification, authentication, authorization etc. you should
> be able to
> describe them in business terms and talk about how ebMS meets those
> requirements.  If the project does not have such requirements
> then maybe
> ebMS is overkill and SWA by itself will suffice.  You need
> requirements that
> justify the acquisition, deployment and operation of the ebMS Message
> Service Handler(s).
>
> It should be made clear that ebMS does not involve any
> substantially new
> technology, it simply brings together common standards such
> as XML, SOAP and
> digital signatures.  Also, ebMS is an independent
> component/specification
> that does not entail having to adopt any other pieces of the ebXML
> framework.  The conversation should not be complicated by
> discussions about
> ebBPSS, ebCPPA etc, unless these components would be suitable for the
> project.  It's not about ebXML versus Web Services, it's
> about evaluating
> the use of ebMS as an extension of SOAP in order to meet the
> requirements of
> the project in the most timely and cost effective manner.
>
> Richard J. Moon
> Crescent Business
>
> >From: Fraser Goffin <goffinf@hotmail.com>
> >To: jgovernor@red-monk.com
> >CC: ebxml-dev@lists.ebxml.org
> >Subject: RE: [ebxml-dev] Re: ebXML doubts
> >Date: Fri, 03 Jan 2003 13:22:45 +0000
> >
> >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
> >
> >
> >----------------------------------------------------------------
> >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 new MSN 8: smart spam protection and 2 months FREE* 
> http://join.msn.com/?page=features/junkmail
>
>
> ----------------------------------------------------------------
> 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>
>