There's an old expression - "When all you have is a hammer,
everything looks like a nail." There's a wealth of applicable comment
in this expression. It's an admonition to see the bigger picture as
well as a suggestion that to be a true craftsman, one must have the
right tools.
This month our focus is on tools and automation for Web services.
That seems very apropos for the idea of needing a variety of tools,
each appropriate to the task at hand. As with craftsmanship, Web
service development requires the developer to know what is the right
thing to do, and the right tool to do it with.
Knowing what is the right approach is often a matter of trial and
error, of learning what will work and what will not. In the world of
Web services, one of the key areas for concern is the definition of
the APIs that will be exposed as WSDL and UDDI entries. As we
present a Web service interface to the world, we must frequently
wrestle with the level of granularity that we expose as a result. Too
little granularity and we run the risk of confusing our service
consumers by not providing enough specificity for the service to be
easily understandable (and therefore consumable). Too much
granularity and we run the risk of shutting down the network with
excessive communications.
Best practices garnered from other distributed computer paradigms
such as CORBA, J2EE, and COM are of some assistance in this matter.
As we examine the patterns and paradigms adopted in each of these
platforms and note the successes and failures, we can draw analogies
to our own Web services implementations, which are often implemented
on one of these platforms. Just as in J2EE, we can make our services
very granular, but we would expect to incur a significant performance
penalty for doing so.
So best practices is one tool in our toolbox. Another is automation
tools. No one should ever have to write WSDL. It just should not be a
task to be done by hand. Like Web-page design, once you understand
the underlying structure and concepts, there's no need to code HTML
in Notepad when you can use something like Dreamweaver.
Similarly, tools are being developed that make it easier to create,
run, and consume Web services, tools that take away the tedium of
writing WSDL by hand and automate the process. In the Microsoft camp,
this area is filled nicely by Visual Studio .NET and augmented by
some serious .NET development at Borland. In the J2EE world, BEA and
IBM are producing toolkits that enable you to write Web services with
very few lines of code, using a wire-together approach rather than a
pure coding paradigm. EAI vendors such as webMethods are also
producing development platforms.
Additionally, the concept of orchestration and management is
receiving due attention. As Web
services move from trial or proof-of-concept approaches to full
implementation, the need for management becomes ever clearer.
Companies such as Actional are developing approaches to meet this
need.
But even further, as we start to see a wealth of Web services we
realize that coordination of processes and atomicity of transactions
are also critical. The WS-I and OASIS, as well as vendors such as HP,
are trying to define both transaction standards and a standard model
for description of the orchestration process in the hope of
standardizing the approach and qualifying the need. It's always
difficult to prove the necessity of orchestration systems - you can
typically hardwire the code in less time. But the ability to make
on-the-fly changes and the opportunity to finally have the business
achieve the definition rather than having the IT department code it
has significant value. What's missing is a strong case for ROI on
this technology, but it will arrive shortly.
So we can see that we need more than a hammer and nails - we need a
whole Web services toolbox. This issue highlights some of those
tools. Enjoy, and don't use a screwdriver to pound in a nail - it
doesn't work well.
Author Bio
Sean Rhody is the
editor-in-chief of Web Services Journal. He
is a respected industry expert and a consultant with a leading
Internet service company.
Sean@sys-con.com
All Rights Reserved
Copyright © 2004 SYS-CON Media, Inc.
E-mail:
info@sys-con.com