ince the initial marketing drive behind Web services, developers have been trying to understand what they are and how they can use them. For the most part developers now understand what Web services are and have even worked through tutorials on how to implement them. The issue now is how to use Web services for business purposes. While there are numerous organizations that are more than happy to point out what Web services can be used for, developers are left to figure out how to use them.
Are Web services simply another presentation tier for their existing applications or are they entirely new applications in and of themselves? Can developers rely on third-party Web services for mission critical applications? These questions and more become quite important when developers get past the hype and down to business with Web services.
Having built several production Web services applications I can attest to the fact that while Web services are pretty straightforward to build, there is an incredible amount of infrastructure required to build production quality web services. Issues like security, scalability, and quality of service (QoS) come to mind. These aren't new issues that developers have never seen before. Most of us learned how to deal with each and every one of these issues during the "dotcom" years, as we built massively scalable Web applications.
No vendor in the Java market can touch the ease of implementation that Visual Studio.NET has, but security and scalability seem awfully more important.
|
|
The problem is that we did a lot of group learning. We observed the experiences of our peers and tried to learn from them. As a result, security, scalability, and QoS aren't even considered important problems for web applications anymore because everyone knows how to solve them. But this is not the case with Web services; because there are so few implementations to date, we have to go back and relearn security, scalablity, and QoS with the unique parameters of Web services in mind.
I decided to take a look at the market to determine if any vendors were addressing the infrastructure problems with Web services. I took a look at vendors in both the .NET and Java spaces to determine what, if anything, they provided to help developers build production-quality Web services. What I found may surprise you.
Maturity Matters
I'd like to start with .NET, simply because many developers first learned of Web services from Microsoft as part of .NET. Interestingly enough, Visual Studio.NET is simply the fastest way to implement a Web service today. The developer simply has to create a class and add a Web service attribute to each method the developer would like to make available. It is literally that simple.
Some questions come to mind with this technique, though. If you don't want a method available to anyone in the world, how do you authenticate consumers of said method? Or more importantly, if you do want the method available to everyone in the world, how are you going to scale it to handle everyone in the world? Microsoft doesn't appear to have any answer to these questions. If you want security and scalability with Web services in .NET, you best figure it out on your own.
If we take a look at Web services from a Java point-of-view though, things look a little different. While Java was, arguably, late to the Web services market, unlike .NET, it was already a mature platform. The entire infrastructure available in J2EE implementations is also available to Java Web services developers. J2EE already addresses the issues of security and scalability. Experienced J2EE developers can easily leverage the existing APIs to provide robust Web services. No vendor in the Java market can touch the ease of implementation that Visual Studio.NET has, but security and scalability seem awfully more important.
Which leaves me with one more issue, QoS. I think QoS is going to be a huge issue for Web services. If you are a business that is relying on a third-party Web service, how do you verify that the Web service will be available when your business needs it? What kind of uptime can you expect from a provider's Web service? What kind of latency can you expect from a provider's Web service? The flip side is important too: What kind of uptime and latency can your Web service guarantee?
Out of all the vendors I looked at, only one, Sun Microsystems, seems to be addressing security, scalability, and QoS with a vision named SunOne. Admittedly, the SunOne Web site seems to be nothing but marketing. Briefly, SunOne has three components:a collection of existing Java APIs that are relevant to Web services, professional services, and a recommendation to do the entire implementation on top of Solaris. SunOne offers an architecture document describing what Java APIs are available to solve specific implementation issues with Web services. They are also developing a set of design patterns and best practices, so that developers can learn from their implementation experience. Further, using their SunTone certification process, Sun can certify the quality of Web service providers.
SunOne is extremely comprehensive, bundling products like iPlanet and Solaris, professional services, certification services, and Sun hardware. While Web service implementers may shy away from SunOne because of all the bundling, it is nice to see a vendor that addresses the full complement of Web services issues.
Other vendors should take note: Web services developers will require just as much software and hardware infrastructure to build production-quality Web services as they do to build Web applications. It is time to get past the hype and to start addressing the real issues.
|
Matt Liotta started his development career at the age of 12 by building C applications for faculty at Emory University. A former employee of DevX, he has worked at several technology companies in Atlanta and San Francisco. Matt is now an independent consultant and speaker at industry conferences. You can reach him at mliotta@iname.com.
|
