RE: WSFL, IBM, and WSDL

["Matola, Tod" <Tod_Matola@stercomm.com>]

Hello,

 I'd also like to point out that with P2P running so fast (changing the way
we see the world) that line between client and server is getting alittle
gray. I think that most of these systems will do both function so that a
conversation about transactions will happen. Maybe the differentiation is
more about persistence or how much a "server"/"client" is willing keep (or
QOS). 

Cheers Tod.

-----Original Message-----
From: Abid Farooqui [mailto:farooqui@tampabay.rr.com]
Sent: Monday, June 11, 2001 8:39 PM
To: ebxml-dev@lists.ebxml.org
Subject: Re: WSFL, IBM, and WSDL


Wow ... six million dollar man, I think I know that show but I am going to
leave it vague here lest I show my age :).
I always envisioned making ebxml based platform that is client/server based.
Server resides with the big guy who hundread or thousands of trading
partners where as the client resides on each one of his smaller trading
partners who don't necessorily need a heavy weight server but would like to
do business with this and perhaps a couple of other big guys. The client
side should be cheap (it has to be or there is no difference between this
and EDI besides technology). Also expensive membership VAN pipes are not
required.
Abid Farooqui


----- Original Message -----
From: "David Lyon" <djlyon@one.net.au>
To: <ebxml-dev@lists.ebxml.org>
Sent: Monday, June 11, 2001 6:24 PM
Subject: Re: WSFL, IBM, and WSDL


Rémy,

I'm very sure that low-cost applications will happen, for if it doesn't
ebXML will be dead.

This doesn't mean that the price of consulting will go down or that high-end
solutions will be any cheaper, but having a low entry cost to smaller
participants for ebXML is extremely important.

One of the biggest problems faced by EDI was cost. Not only cost of
installation but the costs of operation.

Now that hardware and software development costs have dropped so
significantly since the days of EDI, it's about time that the same happened
with business messaging platforms like ebXML. Nobody does badly if the size
of the market for such products suddenly increases by a factor of say, 10.

The true home of ebXML should be on the PDA or wristwatch where people can
actually use the technology. Not in airconditioned computer rooms filled
with techno-geeks.

These days, most plumbers (in developed countries) can afford 3G access in
their delivery vans.

So why not make ebXML the software platform of choice for such people.

As they used to say on the show 'The 6 Million dollar man', "We have the
technology"

David

----- Original Message -----
From: Rémy Marchand <rm-edi@worldnet.fr>
To: Abid Farooqui <farooqui@tampabay.rr.com>; Bob Haugen
<linkage@interaccess.com>; <ebxml-dev@lists.ebxml.org>
Sent: Monday, June 11, 2001 9:44 PM
Subject: Re: WSFL, IBM, and WSDL


> I totally support Abid.
>
> We need on the shelf and low cost solutions, even if they are implementing
> only a subset of the detailed implementations.
>
>
> ----- Original Message -----
> From: "Abid Farooqui" <farooqui@tampabay.rr.com>
> To: "Bob Haugen" <linkage@interaccess.com>; <ebxml-dev@lists.ebxml.org>
> Sent: Saturday, June 09, 2001 4:20 AM
> Subject: Re: WSFL, IBM, and WSDL
>
>
> > Dear Bob,
> > If you read the thread about WFSL completely you will realize that I was
> > just answering someone's question about the differences between WSDL and
> > WFSL and nothing really to do with ebxml.
> >
> > My other point about automating business document processing between
> vastly
> > different market verticals like high tech electronics and HR. The point
I
> am
> > trying to make was that if a PO specification for electronics industry
and
> > HR for example is very different then implementation will be harder than
> if
> > they all followed the same standard for a PO. ebXML has pushed this to
the
> > verticals to decide for themselves which gives us the same kind of
> scenario
> > as with todays EDIFACT, X12 and the list goes on. I don't see any
> > discussion, analysis or even an attempt to solve this in any paper.
> > I will say though that ebXML documentation is too high level without
> enough
> > concrete examples and there is no logical order recommended to read it
in
> > (too many white papers that are not useful for development). Also some
of
> it
> > seems to documentation for the sake of documentation. As a developer who
> > wants to implement an ebxml server and who has not been involved in it
for
> > the last 18 or so months, I have not been able to find the head or the
> tail
> > for ebxml specification. There is no reference implementation or toolkit
> > either which would help. High level specification is all dandy but the
> proof
> > is in the pudding. In this respect web services seem to be way ahead of
> > ebxml even though there are some problems there that need to be
addressed.
> I
> > do think that the documentation can be better organized, summarized and
> > needs to be more to the point for developers. May be there needs to be a
> > developer's guide that touches it all just enough for a developer to
look
> at
> > and understand. Developers really don't need or care about the business
> > case, white papers etc.
> > Sincerely,
> > Abid Farooqui
> >
> > ----- Original Message -----
> > From: "Bob Haugen" <linkage@interaccess.com>
> > To: "'Abid Farooqui'" <farooqui@tampabay.rr.com>;
> > <ebxml-dev@lists.ebxml.org>
> > Sent: Friday, June 08, 2001 7:32 AM
> > Subject: RE: WSFL, IBM, and WSDL
> >
> >
> > > <Abid Farooqui> (collected from three messages)
> > > Anyway, even if we go with the approach you suggest, let me ask this.
> > > How are you planning to automate business processes across vastly
> > different
> > > verticals without the kind of pain that is involved in doing so today.
> > > Because if we still have to go through all that kind of stuff, we can
> just
> > > put ebXML and all other SME solutions on the shelf and just stick with
> how
> > > things are today.
> > >
> > > Oh I also forgot to mention about WFSL ... it kind of also tells you
in
> > what
> > > order to call different methods of a web service. If you have a
shopping
> > > cart service with methods like "getCart", "addItem", "checkOut" etc.
It
> > will
> > > not make sense to try to checkOut before at least calling "getCart"
> right?
> > > These things are kind of missing from WSDL. Although they can be
easily
> > > added there. They did not have to come up with a new thing for all the
> > > features that are in WFSL. There is a very good article talking about
> some
> > > problems within WSDL in the June/July issue of XML magazine
> > >
> >
>
http://www.xmlmag.com/upload/free/features/xml/2001/06jun01/ab0103/ab0103.as
> > p
> > > </Abid Farooqui>
> > >
> > > Abid, which ebXML documents have you studied?
> > > For example, have you studied the business process documents?
> > > They're the ones with Business Process as the project team on page
> > > http://www.ebxml.org/specs/index.htm
> > >
> > > The ebXML answers to the above problems and questions are in those
> > > documents.  I'd be interested to know if your questions indicate that
> > > you have not read those documents, or you have read them but the
> > > answers are presented too obscurely.
> > >
> > > Thanks,
> > > Bob Haugen
> >
> >
> > ------------------------------------------------------------------
> > The ebxml-dev list is sponsored by OASIS.
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org
> >
>
>
> ------------------------------------------------------------------
> The ebxml-dev list is sponsored by OASIS.
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org
>


------------------------------------------------------------------
The ebxml-dev list is sponsored by OASIS.
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org


------------------------------------------------------------------
The ebxml-dev list is sponsored by OASIS.
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org