[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC