HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

Exposing the Services

Depending on who you talk to, the response you get when you mention the words "Web" and "services" in the same sentence can vary from a big smile to an amazingly serious frown. It's easy to develop an application or Web site that uses the Amazon API and the Google API to great effect. From where I stand there hasn't been much movement since, although personal Web publishing has taken to the Blogger API with some interesting results. Syndic8 also has a nice API to expose the collection of news feeds it has, as does Meerkat. Once again the community is reduced to a select few using a good quality tool. I'd be interested to find out the usage of these APIs, so if anyone could help me out, please e-mail me.

Don't get me wrong, I know there are lots of Web services out there. Look at XMethods' Web site to get a very long list of active services. The question is, how many of those would you use on a day-to-day basis? I have no need to search and find Icelandic addresses or social security numbers.

One thing a lot of the mainstream companies seem to suffer from is a lack of completion from search to sale. If I want to get details on a flight from London to New York, I can do so quite easily via a Web service. Booking a ticket still takes a phone call or me logging on to a Web site to finalize the sale. The whole thing could be wrapped up in three or four steps (including payment). There should also be an amount of intelligence wrapped in - if I can't fly from London Heathrow to New York, the Web service should be suggesting alternative airports that can. Most of this functionality is down to the server side. What I have noticed is a standard blank response to the most basic of requests. The majority of humans don't make requests in that way; software shouldn't either.

I've been thinking about Web services a lot recently. I've been talking to a company that provides an excellent service and we've worked closely over the last six months on resolving some request for information that would make my life easier. To their credit they came up with the goods very quickly. Then I started talking about how Web services could improve their software model. At present everything, with a few exceptions, is done via their Web site. The software I had written bypassed the Web site but still used HTTP. The implementation was okay but not what I would like to put my name against for the rest of my days.

What now for Web services? Amazon looks like it is taking the whole thing seriously enough. Jeff Barr, the Web services evangelist, defines four sets of users: buyers, sellers, site owners, and developers. They are working hard to make their API as robust as possible so developers can craft some quality software. With Google, however, I can't quite put my finger on it. They released the API (a month after I had spent a lot of time scraping URLs for an IRC bot plugin) that worked very well for doing searches, spelling suggestions, and taking data from the cache. There's still no word on an API for the comparison shopping engine, translation services, or the excellent news services. Has the Google API stagnated? I do hope not.

What can the Java community do to help? In fact we can do quite a lot. Our point of focus though has to be the end user, not the developer. Well-thought-out designs, processes, and responses need to be addressed for Web services to work in the real world. Programming Web services is a simple process; programming robust ones isn't. Just because users can't see what's going on with our Web service code, doesn't give us license to be sloppy developers. Aim for the highest quality every time. Test it, unit test it, and stress test as many times as you can. Don't just write the service, write the client code too, in a number of languages. Be a help to these people, and realize that offering a bunch of WSDL files may not be the way to attract users.

Web services are still young, but they have a lot of potential to expose your services to other clients and users. Development still has to come from the community, and I think we can do it.

JDJ News
What do you think about the new layout? My plan, as you may have noticed from the topics in this month's section, is to concentrate on a fairly pragmatic approach - the information you need presented to you in the easiest way possible. This is not easy to ask or deliver but I am working on it. Over the next few months you'll see articles on refactoring, more beginners tutorials, and also one-page articles covering just what you need to know to get the job done.

The Web site will offer more content as well, plus lively discussions about various topics. Don't forget, if you have a RSS reader, you can link to our feeds, and it covers various sections. This will give you the news on your desktop (still visit the site once in a while though, please).

About The Author
Jason Bell is a technical architect for a business intelligence company in England. He is also involved in a number of open source projects and reads the API docs. [email protected]

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.