"Berin Loritsch" <[EMAIL PROTECTED]> wrote:
> Geoff Soutter wrote:
> >
> > Isn't Web Services basically just the EDI concept with a trendy new
name?
[snip]
> This is true to a large extent. There are two key differences though:
the
> information is in a standard format (XML) which only requires a generic
parser
> to read
Hmm. EDI used "standard" formats defined by ANSI X.12 and EDIFACT. Simple
line based things which were easy to write to with COBOL. XML is a better
fit for the business language of the day in this case, Java, but it's not
really any more "standard".
> and the addition of automatic discovery of services.
IMHO, this is the part that is likely to not work. Getting applications to
discover each other and talk together effectively without prior planning is
_hard_ for anything thats not trivial.
> Another key
> difference is the emphasis on ubiquity.
Yes, seems to me this one of the main difference (apart from the "marketing"
aspects). This comes from using a public, "free" network rather than
private, fee based network to transmit the data.
Also, Web services can work in real time because computers have so much more
grunt these days. EDI is all message based.
> I doubt Web Services will replace traditional EDI soon, but there are some
> neat things that the Web Services approach allows you which EDI does not
(at
> least my _very_limited_ understanding of EDI). The first thing is UDDI
for
> automatic publication and registration of services offered. EDI typically
> is set up on a company by company basis involving humans. This approach
> cannot scale to the extent that Web Services claims to (i.e. like HTML web
sites).
UDDI is cool, but it's going to be very hard to make it work without humans.
You have to deal with the different applications at each end which have
different internal data structures, and yet use a common format that both
understand. UDDI itself is not that hard, but getting apps to agree on a
common format which everyone can use and which meets everyones business
needs is impossible.
Just take a look at the format for an EDIFACT Purchase Order document to see
what I mean. It's _way_ complex, and most people only implement a fraction
of it. Thus you need humans to agree which parts are going to be used, and
what the contents actually mean in a business sense.
> The second is the standard markup definition used for data exchange. By
using
> XML, a company can choose the XML parser based on performance and load
criteria
> (something that EDI can't offer alot of choice in).
There are many companies offering EDI parsers that can deal with the
standard X.12 and EDIFACT syntaxes.
> Web Services is the next big idea for a smart web where things just
"work".
> One way I can see this take off is in a "smart kitchen". Imagine if you
will
> the kitchen of the future where the refrigerators and cupboards keep track
of
> inventory and order groceries to be delivered on a "Just in Time" basis.
This
> of course would be first adopted by professional establishments, and then
find
> their way into everyday homes. The scenario outlined above also buys into
the
> embedded market in what they preach. It is a "realizable dream" in that
it
> can be done with today's technology--the business side of things has to be
worked
> out though.
>
> Web Services do have potential beyond what EDI preaches--and it is in
small services
> that can be combined into a larger service. This is in contrast to one
large transaction
> with one party. The interesting twist to Web Services is that you can
change the
> players that make up compound service without affecting the logic of the
service.
Aha. To me, these fall under the umbrella of 'trivial' apps. It's not hard
to define an interface for a light switch that everyone is happy with. A
refrigerator might be a bit harder :-).
Seems to me that companies like IBM, etc, that are backing web services are
marketing it like a next-gen EDI rather than like the JINI style stuff you
descibe above.
Don't get me wrong, I think EDI and Web services are great. Web Services may
go some way to make EDI style implementations easier, but they underlying
problems remain the same. As Chuck D. so eloquently said: Don't believe the
hype!
Cheers
Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
