Ok. Cool. People are doing it. Now: what benefits does it really bring?

Kenshi
Wednesday, April 30, 2003

For Our Company they used to have VB 2 Tier-ed client-server apps talking to mainframe CICS & DB2 - fat clients.

Web services eliminates the need for the fat clients. All of the business logic resides in back end or middle tier = easy deploys. The front ends are thin - presenation only.

They used to have a lot of problems with VB talking to CICS programs - rep_text files would have to be updated every time there was a change. Pain to keep building and rolling out to the clients (100's of them).

KenB
Wednesday, April 30, 2003

I did a Java <-> .NET integration using Apache Axis.

Worked pretty well. Any issues were less the web services and more the implementation of said services.

Definitely added a lot of complexity to the whole thing, what with all the generated stub files and whatnot.

Matt Christensen
Wednesday, April 30, 2003

Web services also allow you much greater choice in which fat client technology you use, if you choose to go that route.

Once you start getting into some of the newer WS-specs you start solving more complex problems such as transport-neutral addressing and routing, reliable messaging, federation, and so on. These problems have all been solved before, but the possibility of a standardized, cross-platform, cross-technology solution is very exciting. The WS-specs are the part of web services that have the most draw for me in a single-platform, single-technology scenario, simply for the plumbing that it automates.

ODN
Wednesday, April 30, 2003

I don't really get some of these ideas about web services. Why do you want to broadcast to people that you have a web service available? Why do I want to depend on someone I don't know to provide functionality to my application?

If you control both sides, you know what services you want, so why announce them? Why even make them "web services?"

What's a good example of an application not knowing what web service it wants to deal with, and consulting the directory to find one?

Of course, many of my applications talk to each other via HTTP and XML. I just call it talking, not a "web service."

Scotty
Wednesday, April 30, 2003

I'll give you an example:

News Headlines, Quotes of the Day, Weather etc etc

KenB
Wednesday, April 30, 2003

"What's a good example of an application not knowing what web service it wants to deal with, and consulting the directory to find one?"

in bioinformatics there are tons of databases out there that do the same thing, sort of. so you could have a single client that finds the least busy BLAST search engine and submit your query there.

choppy
Wednesday, April 30, 2003

Okay, so people have web services that offer headlines, weather, and the output of fortune.

Someone else writes a client that uses the directory to find services of this type and show them to the user. This is fun and all, but doesn't help me solve any problems I have.

The bioinformatics idea sounds like a better use, but does the directory really work that way? I don't know what these "blast" search services are, but it seems like I would already know that some search servocess, and I just query them myself instead of scanning the big web services directory. Of course, if these search engines are something that come and go all the time, then it might be good to have a directory I can query.

Maybe a good use of web services would be shopping... Every online retailer announces their web service for searching products. I have a generic shopping client that grabs all of these services and lets me query them.

I also don't understand this directory thing. When I played with VS.NET it allowed me to search for web services. Who controls this, Microsoft? Will we have to rely on one big directory run by Microsoft in order to do business using web services?

Scotty
Wednesday, April 30, 2003

"Will we have to rely on one big directory run by Microsoft in order to do business using web services?"

No, you will have to rely on one big directory run by Google, until Google is purchased by Microsoft. ;-)

The directory would be very helpful in bioinformatics, university research groups release new types of search engines all the time (find SNPs, find hot retrotransposons, etc) and usually no one else knows they exist. if each search engine automatically advertised itself, someone could build a search clearinghouse site that allowed you to locate the tools you want to use. Of course, having fancy new XML repository infrastructure is not necessary, you could do everything just by sending email to a mailing list advertising your service, but presumably the auto-advertising stuff makes this easier.

choppy
Wednesday, April 30, 2003

Am I a retrotransposon? I like kitschy lounge music, transportation, and spoons.

Scotty
Wednesday, April 30, 2003

I've participated in the development of a reservation system on the old MS platform (ASP/VB6/C++) where the VB business objects hosted in COM+ were 'wrapped' in SOAP. ASP (B2C interface) used the SOAP client.
The advantage was that the same web services were used by other systems (B2B). Another cool advantage of using SOAP was that load balancing of the business layer could be done with simple load balancer, as opposed to MS Application Center (for COM+ load balancing). Debuging was a bliss (one could see every SOAP request, and the SOAP toolkit had a very simple yet useful trace tool)..
Disadvantage - speed.

Alexander Chalucov (www.alexlechuck.com)
Wednesday, April 30, 2003

Have worked on two web services projects in the last year.

The first one used GLUE (SOAP framework from The Mind Electric) to wrap up a "legacy" database. On top of that we wrote a servlet based web app, but anything could talk to our wrapper.

Second one used Oracle SOAP (based on Apache SOAP) and was called by a J2EE layer which was frequently, in turn, called by a .NET layer - all using SOAP.

It works. It's not rocket science.

My pet peeve is people inappropriately sending XML within the SOAP message where it's not necessary - i.e. adding an unnecessary layer of XML. Both projects I worked on did this, one because it was appropriate, the other because someone was confused about the fact that SOAP uses XML (I think they thought it meant your parameters had to be XML documents or something).

Walter Rumsby
Wednesday, April 30, 2003

It'll never happen but generic parts of any kind (lets say tire vendors)

Daniel Shchyokin
Wednesday, April 30, 2003

While we're on the subject, does anyone know of a real-time sports score service? I searched through http://www.xmethods.com/ and couldn't find anything. Not real sure where to look after that.

I figure if I find something that I'm really interested in, I'll be more motivated to dig into this stuff a little deeper.

Chris

Chris Guest
Wednesday, April 30, 2003

It's an easy way to do distributed processing. Or setting up proxies

Wednesday, April 30, 2003

Amazon's XML services is probably the largest user-base of a web service.

For people finding it hard to see the "why" of web services, my favorite explanation was from James Gosling, along the lines of...

Some sites and systems already get information off the web by screen scraping, parsing the Html, and ripping the information they want. Web services can be seen as a formalisation of this. A contract between a business and clients to share and inter-operate with data.

With a published XML spec as to what's being served, there's no ambiguities of the Html format changing etc etc.

Web services will never be something that end users demand, but a business oriented way to arrive at solutions and systems which rely on external information, quicker and in a more predictable and reliable fashion.

well... that's the way I see it. :)

Arron Bates
Thursday, May 1, 2003

Web services have a very positive offshoot: they made plain old client-server architecture trendy again, so you don't have to write web applications when desktop apps are a much better solution.