Re: [ebxml-dev] gorilla hair vs. beach balls

[Duane Nickull <duane@xmlglobal.com>]

Thanks Colin.

In future,  I would be great to see an article on your site showing how
ebXML can be implemented as a series of Web services.  There could be
some real value in that, expecially for SME's who may not be able to
afford/maintain software do do things like build CPA's.  

WS do not make sense for using everywhere and IMHO, there needs to be a
business driver before implementing a WS interface.  The logical
components of ebXML for WS candidates are (again - IMHO):

1. Registry  - Farrukh has already done a ton of work in this area and
there is a part of the registry sec dealing with this implementation
issue.

2.  CPA - building a CPA could be a great candidate for someone to
implement as a web service.  THe input could be:

   a/ Company A's CPP
   b/ Company B's CPP
   c/ The roles they wish to assume
   d/ instructions on precedence for multiple choices

3. BIE/document assembler - the input values could be a set of business
contexts (described in a Context rules Message) and a list of Core
Components or BIE's.  The return value could be a fully assembled schema
for the business payload.

4. Transformations - input values are the schema from #3 (above) and a
set of information in another native format (perhaps one of the first 5
temporary payloads).  The return value woudlbe the final business
payload for a step within the business collaboration.

I know I have promised such an article int he past but time has dictated
otherwise. Anyone care to take a swat at this?

Duane
colin adam wrote:
> 
> Duane,
> 
> Ok, I understand now where we differ. I use "web services" not to simply
> mean a programming interface...
> 
> You are reading it as programming interface vs ebXML which of course is
> a silly question, hence your comments.
> 
> We could probably spend a great deal of time on what the term "web
> services" now means. More so these days however it is becoming a general
> term to mean service orientated architectures. Ask someone to explain
> web services and they will talk about two applications working over
> interoperable protocols with contracted services.  This is the
> definition I was using while constructing the poll. This goes beyond a
> programming interface definition, to one which takes in distributed
> message exchanges within an IT architecture
> 
> I accept the view of this group that ebXML and web services (in the
> programming interface definition) can not be compared. They are apples
> and oranges.
> 
> It is all about perspective, and I will bear in mind this discussion in
> future polls. Obviously it is not as simple to say ebXML vs web services
> since people understand this to mean different things. I have now closed
> the poll.
> 
> Thanks for your kind comments on the site. I am always keen to post news
> on ebXML and if anyone has any, please send it to
> submissions@webservices.org
> 
> By the way, I never placed the poll up to gain traffic or start
> something between ws and ebxml. This is in response to the email sent to
> this group that accused me of this.
> 
> Cheers
> colin
> 
> > -----Original Message-----
> > From: Duane Nickull [mailto:duane@xmlglobal.com]
> > Sent: 14 June 2002 18:53
> > To: colin adam
> > Cc: 'Jean-Jacques Dubray'; 'ebxml org'; ebtwg-bps@lists.ebtwg.org
> > Subject: Re: [ebxml-dev] gorilla hair vs. beach balls
> >
> > Colin:
> >
> > Some comments inline:
> >
> > colin adam wrote:
> > > Anyway, I think we misunderstand each other. I see web services vs
> ebXML
> > > as asking this question...
> > >>>>>>>>>>
> >
> > I see your question as "ebXML vs programming interfaces".  I think the
> > misunderstanding is at your end and related to technology.
> >
> > > 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.
> > >>>>>>>>>>
> >
> > Again - apples and oranges..  WS is an interface to a work unit of
> > information processing.  There are nmo constraints on what the IP may
> be
> > doing.
> >
> >
> > > 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"...
> > >>>>>>>>>>
> > UDDI is a directory service which like ebXML,  could be communicated
> to
> > via a web service.  In fact, it is.  UDDI itself is not a protocol for
> > web services.  WSDL is a schema used to describe a web service
> interface
> > including the input parameters and return messages.  SOAP is a
> protocol
> > for communicating with another endpoint using XML over HTTP following
> a
> > simple schema.  I still don;t see what you're trying to say.
> >
> > > Generally since ebXML uses standards above the core three, 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.
> > >>>>>>>>>>
> > Please do not speak for the general community.  It is your opinon.
> >
> > An ebXML Product can be implemented using WS to communicate with it.
> > Maybe what you really meant to ask was "WS .vs java interfaces" since
> > they are really two different ways to communicate with a function.
> Then
> > you could make comparison based on several criteria:
> >
> > abstracts programming language from class?
> > network lag?
> > etc...
> >
> >
> > > >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..
> > >>>>>>>>
> > Let's you create a way of communicating with a piece of code.  It
> > doesn't constrain what that code could do.
> >
> > > Or are we saying that on no basis can there ever be any competition
> > > between an "web services" product or and "ebxml product"...
> > >>>>>>>>>>>>>>
> >
> > You are comparing two different things.....
> >
> > Duane Nickull
> >
> > --
> > VP Strategic Relations,
> > Technologies Evangelist
> > XML Global Technologies
> > ****************************
> > ebXML software downloads - http://www.xmlglobal.com/prod/

-- 
VP Strategic Relations,
Technologies Evangelist
XML Global Technologies
****************************
ebXML software downloads - http://www.xmlglobal.com/prod/