atom feed17 messages in org.ebxml.lists.ebxml-devRE: [ebxml-dev] gorilla hair vs. beac...
FromSent OnAttachments
Beach, ScottJun 14, 2002 10:24 am 
Duane NickullJun 14, 2002 10:56 am 
colin adamJun 14, 2002 12:24 pm 
Rainer VolzJun 14, 2002 12:32 pm 
Duane NickullJun 14, 2002 12:56 pm 
CRAWFORD, MarkJun 17, 2002 4:33 am 
Martin W SachsJun 18, 2002 4:05 pm 
Matt LongJun 18, 2002 4:33 pm 
Michael C. RawlinsJun 18, 2002 5:10 pm 
Martin W SachsJun 18, 2002 5:27 pm 
bhaugenJun 18, 2002 5:45 pm 
BELFORD NeilJun 18, 2002 6:08 pm 
Dieter E. JenzJun 19, 2002 12:59 am 
Jean-Jacques DubrayJun 19, 2002 1:18 am 
Adrian RobinsonJun 19, 2002 1:31 am 
Stefano POGLIANIJun 19, 2002 4:29 am 
Webb, MarkJun 19, 2002 4:30 pm 
Subject:RE: [ebxml-dev] gorilla hair vs. beach balls
From:colin adam (coli@webservices.org)
Date:Jun 14, 2002 12:24:51 pm
List:org.ebxml.lists.ebxml-dev

Duane,

I agree, an article would be great.

Webservices.org will pay a good rate for copyright for the article...if that is an incentive to anyone :)

I suggest the article be peer reviewed in draft via this group.

Regards colin

-----Original Message----- From: Duane Nickull [mailto:dua@xmlglobal.com] Sent: 14 June 2002 19:44 To: colin adam Cc: 'Jean-Jacques Dubray'; 'ebxml org'; ebtw@lists.ebtwg.org Subject: Re: [ebxml-dev] gorilla hair vs. beach balls

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 subm@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:dua@xmlglobal.com] Sent: 14 June 2002 18:53 To: colin adam Cc: 'Jean-Jacques Dubray'; 'ebxml org'; ebtw@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/

---------------------------------------------------------------- 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 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>