OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ubl-dev] Technology heavy-weights consider the future of WS-*


Fraser,   

Cool analysis from your perspective. I believe my stance has always been consistent with your observations here.  I do not try and push technology for technology sake - in fact the reverse - I have often recommended retaining EDI systems where the business ROI does not support rip-and-replace.   

Well the good news is for you - WebSphere 6.1 has native ebXML ebMS support - and as with anything IBM does - it is a solid and capable feature set.
http://ebxmlforum.blogspot.com/2007/03/ibm-adds-native-ebxml-v20-support-to.html   

What I do say is that you have to match the right amount of technology to your business needs.  Clearly ebXML excels at B2B - and can provide the vast majority of needs within that domain - the 80:20 rule applies.  

Similarly REST/WSDL interfaces cover off a great deal of peoples simple realtime integration needs.  And then WS-* is designed by OMG to fulfill DOD levels of security and access control - again DOD and certain other high-security government and commercial applications may require that.   

So - what I see is that implementers have 3 distinct choices based around their business needs.  Now of course technology drivers may intervene - if a large partner already has a solution and is pushing that down stream.  What I have always said is that you need a blend of these technologies - and should not be pushing one to the exclusion of everything else.   

What is pretty clear is that there are simply no technology constraints to ebXML in 2007.  Oracle A/S and IBM Websphere both offer plug-and-go solutions for sites already with those products - and that covers most tier 1 and 2 players.  Then there are 3 solid OSS solutions to choose from - plus proven 3rd party solutions like the Axway/Cyclone solution - and several traditional B2B VANs like bTrade.  And all the key EAI/ESB/ERP players support it too.   

Consequently - when people do implement ebXML for B2B - as Helena Chemicals did with Oracle - then the results are boring and predictable - which is what it should be - no surprises - and a measure of a mature technology!    

So the point I believe is that - no need to risk exotic technology when there is already what you need to hand.  Of course sales and marketing never want the customer to buy boring and obvious!  The latest gizmo is the cache in life and carries the higher commission points and markup.  

In which case I guess you have to insist on ebXML v3 support...   

; -)   

DW

"The way to be is to do" - Confucius (551-472 B.C.)
 

 -------- Original Message --------
Subject: Re: [ubl-dev] Technology heavy-weights consider the future of
WS-*
From: "Fraser Goffin" <goffinf@googlemail.com>
Date: Sun, April 22, 2007 6:46 am
To: "David RR Webber (XML)" <david@drrw.info>,  UBL-Dev
<ubl-dev@lists.oasis-open.org>,  "XML Developers List"
xml-dev@lists.xml.org

David,
 
 the ebXML story is a good one and, IMO, doesn't need to use a 'rubbish
 the
 opposition' tactic to sell itself. I have long been a supporter of
 ebXML and
 *maybe* today it is gaining enough traction to make serious in-roads into
 enterprise computing - maybe.
 
 I work for a very large financial services organisation in the UK. Many
 years ago, when we were first setting out on the 'business services' road
 ebXML was something we looked pretty hard at, and saw much merit
 (pre-ebMS
 2). We 'hounded' IBM for many a month to support ebXML and, although
 there
 were promises to do so, ultimately they did not in any significant way
 (for
 very obvious (and I have to say justifiable) reasons mainly to do with
 the
 existing and expected pervasiveness - aka - how many people were
 asking for
 it - at that time - close to zero).
 
 Later on (perhaps 3 years ago) IBM were contracted to design and build a
 'web services' portal for my industry sector, supported and funded by
 all
 the major players, and I have to tell you they did NOT choose ebXML
 (although I personally lobbied for it) and DID choose some of the WS
 standards. This portal now forms part of the core enterprise
 infrastructure
 for all of the participants (i.e. most of the big high street names in UK
 financial services).
 
 If they are finally getting around to providing support for ebXML, great
 (not clear what the scope will be mind you). One might argue, not before
 time, although like most things in life, many things are to do with
 timing
 rather than technical elegance/superiority.
 
 But of course, keep in mind that IBM ALREADY support most of the core
 aspects of the WS-* stack that you appear keen to deride, and this
 support
 is growing (upcoming releases of IBM integration products will INCREASE
 support for WS-*). It perhaps worth noting also that much of what ebXML
 specifies isn't very different from some of the WS specs, so in some
 regards
 is just a different way of doing the same thing (except that the WS specs
 have more mainstream tooling support).
 
 It is perhaps this WS-* terminology that bothers me most. The article
 that
 you reference points to the fact that the motivation and perhaps some
 of the
 implementation of *some* of the WS standards *are* actually worthwhile
 (albeit in a somewhat begrudging tone).
 
 It also talks about the folly (or sheer waste) of 'rip and replace'
 approaches (at least in the enterprise space) and makes much (rightly) of
 the desire (if not imperative) for organisations to continue to leverage
 their existing IT assets (i.e. mainframe and 'pre SOA' operational
 systems).
 I concur.
 
 In that spirit, I would suggest that for those who *have* chosen
 *carefully*
 from the set of WS standards that *do* provide value and *do* enjoy a
 level
 of consistent support in the technology set that they choose to use, will
 continue to use them in the same way that they will carry on using
 CICS/Cobol despite predictions of its imminent demise. This more recent
 software is no less part of the existing asset base than anything else.
 
 So come on, before you fall into the same trap of retoric as the
 'hype'sters' that you appear to want to blame for failure of WS, or
 whether
 you feel that REST is better, or ebXML, or whatever, I ask you to accept
 that there are many organisations, mine amongst them, that *do* find
 substantial utility and value in what some groups seem to want to
 polarise
 as 'the opposition'..
 
 I don't have much time for the column inches dedicated to scare stories
 about particular vendors dominating various standards efforts. If my
 experience shows me anything, it is that they are all up to it but from a
 practical everyday delivery perspective it doesn't matter all that much.
 Technologies come and go as they always have and we adjust accordingly
 (agile anyone). Long term strategic initiatives are a massively hard sell
 these days, and perhaps rightly so. Most Project Managers I know have
 trouble looking beyond the immediate delivery and the set of problems
 that
 it addresses. Most architects are having a tough time getting funding for
 long term infrastructure spend, and many supposed pundits are already
 planning their meal tickets on the back of the next hype curve. The
 rest of
 us are just getting on with the job.
 
 Fraser.
 
 
 On 09/04/07, David RR Webber (XML) <david@drrw.info> wrote:
 >
 > http://www.dehora.net/journal/2007/04/and_so_it_goes.html
 >
 > I keep carping on this topic - but for once its not just me!
 >
 > ; -)
 >
 > Some "quotable quotes"...
 >
 > Enjoy, DW
 >
 > "The way to be is to do" - Confucius (551-472 B.C.)
 >
 > ---------------------------------------------------------------------
 > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
 > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
 >
 >
 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]