NETTING IT OUT

There's more than hype to the Web Services evolution. We're on the threshold of a more productive era in the development and deployment of applications. A new category of application assembly platform has emerged that makes it relatively easy for corporate developers to embrace many of the best practices that have been used for over 10 years by professional systems engineers in the distributed object computing field.

This new breed of application assembly environments lets developers turn components into Web Services and lets them assemble applications by combining Web Services. These Web Services assembly platforms let corporate developers use business rules and business events to determine the workflow of an application based on its context. And, because the assembly components are Web Services, each of which has already been optimized for the Net, these Web Services-assembled applications can be automatically deployed across the Internet.

But, as with any new category of products, there are key capabilities you'll want to examine carefully. The most important issues to consider are the development expertise and background of your corporate developers and the deployment environment you expect to be using. Since most businesses are embracing both Microsoft's .Net environment and the J2EE world for Web Services, ideally, the application assembly platform you select should support both environments equally well.

HOT NEW CATEGORY: WEB SERVICES DEVELOPMENT AND ASSEMBLY

We're going to see a variety of companies positioning themselves as Web Services application development environments and assembly platforms over the next 18 months. It's too early to call the winner in this space. But we can provide a few guidelines you should use in evaluating these alternatives.

A Web Services Application Development Environment is a complete Integrated Development Environment (IDE) with all the tools that a team of developers would need to design, develop, test, debug, assemble, and maintain a set of object components, Web Services, and Web Services-based applications.

A Web Services Assembly Platform assumes that developers are using some other IDE to design, develop, and test software components. A Web Services assembly platform should enable a small team of business analysts and developers to assemble Web Services from previously-created components and previously-wrapped application functionality.

We are particularly intrigued by the advent of this latter category of Web Services assembly platforms. They address a new need in the marketplace, and it's a need that is going to get much larger, not smaller: how to mix and match Web Services in order to quickly assemble robust net-Native applications.

ASSEMBLING WEB SERVICES INTO APPLICATIONS IS NOT A NEW TECHNIQUE

First, of course, you probably already know that assembling applications as collections of loosely-coupled services is not a new idea. It's the approach that savvy technology architects have been using for years.

Second, using business rules to separate out application logic from both the presentation of the application and the data it processes is also not new. The only variations on this theme we've seen of late have to do with the ease with which programmers can do their part of the process-designing and testing robust business rules-and business people can do their part-modifying business rules on the fly by changing the parametric values that trigger the rules.

Third, Web Services are created in a variety of ways. Many of the capabilities that are referred to today as Web Services are simply existing application functionality (like a transaction monitor or an order entry system) with published Web Services Description Language (WSDL) interfaces that can be registered in a Universal Description Discovery and Integration (UDDI) directory, communicating via XML and Simple Object Access Protocol (SOAP).

So what's the excitement about? It's simply this: We're finally reaching a point in application assembly platforms where some of the best practices that good architects have been using for years are now being commercialized into development frameworks and platforms that mere mortals can use. As one cynical architect explained, "They keep mediocre developers from hurting themselves and the rest of the world." In fact, you'd be hard pressed to find a new application being developed commercially today that isn't developed as a collection of Web Services, usually sitting on top of a Web Services application framework. That means that extending and enhancing these newer Web Services-based applications should be easier and more straightforward than ever before.

QUESTIONS TO ASK WHEN EVALUATING WEB SERVICES ASSEMBLY PLATFORMS

If you're evaluating an application assembly framework or platform that professional and/or corporate developers might use in-house to develop new applications such as Bowstreet's Business Web Factory, SilverStream's eXtend, or BEA's "Cajun" (WebGain Studio follow-on product), there are a number of important questions you'll want to ask.

These same questions are probably also useful ones to ask when you're evaluating an off-the-shelf packaged application like PeopleSoft 8 or mySAP that is purported to be designed as a set of customizable and extensible Web Services, or when you're assessing an application infrastructure, like BEA's WebLogic or IBM's WebSphere.

* Who are the target customers/users of the platform? Professional developers (J2EE, CORBA), corporate developers, (Visual Basic, Scripting languages, Business Rules), and/or business analysts (business process flow and parameters for business rules)?

* Which development languages and tools should the target customer/user be comfortable with-Java and VisualAge for Java or Forte or VB and VisualStudio.NET?

* Is the runtime environment for the assembled applications primarily J2EE or .Net? Or is it truly ecumenical? (Generally, these environments are either J2EE or .Net-centric but accepting of services created in the other environment.)

* How robust, scalable, and performing are the applications that result from using this environment in a standard manner? (Any application can be tuned for performance-but you need to know how apps will run if "run of the mill" developers work in this environment.)

* How are business rules created and maintained? Who creates them? How are they implemented? How are they tested and staged? Who can modify the parameters? Is there a clear separation of the business logic that business users can alter (e.g., the parameters) and the application logic that developers need to write, test, integrate, and maintain?

* How well does the environment support loose vs. tight coupling? In other words, does a requesting service need to maintain the connection in order to receive a response from another service? Tight coupling can become problematic in a networked world in which intermittent connectivity is the norm. But many applications will need to support both loose and tight couplings.

* How is metadata defined and how accessible is it? What tools exist to enable developers and analysts to adhere to and/or to modify and extend the metadata definitions that are published as part of Web Services?

* How are Web Services managed and re-used?

As the Web Services arena evolves, more questions will arise. In particular, we expect to see a lot of debate and development around application metadata, metadata repositories, and semantics. Today's Web Services assembly tools will only really work for Web Services that are developed by sets of people who agree on terminology and semantics. (When I issue the request, "check price," which price do I get-the published list price, my company's discounted price, or a dealer's price?) As soon as we start trying to link in third-party-created Web Services, the possibilities for ambiguity become so great as to make those linkages unusable. But, as higher level standards emerge for XML schemas and business process metamodels, it will eventually become feasible to assemble applications out of both known and unknown-but-trusted Web Services.

WHERE'S THE BIGGEST OPPORTUNITY?

We see a huge opportunity that is being neglected by most of the players in the burgeoning Web Services assembly arena. What most corporate development shops need is an agnostic platform that will accommodate .Net-created Web Services and J2EE-created Web Services in a relatively seamless and painless manner. The reality in today's corporate world is that most IT and application development and assembly shops use both J2EE and Microsoft .Net. The major advance that Web Services offer is the opportunity to assemble applications out of both J2EE and .Net-created Web Services. Although Web Services standards promise interoperability, you'll find that most of today's players and platforms have a strong pro-Microsoft or pro-J2EE bias. So, as you're investigating alternatives, check to see how well the Web Services Platform you're considering will address the needs of both groups of developers.

We hope that the Web Services industry responds to this wake-up call soon!