More than Code

In enterprise architecture, Web services continue to dominate the discourse in design and implementation.

• By Peter Varhol
• April 15, 2008

Spring is always the time of year when my thoughts turn to Web services. Why spring? Because each year, the Redmond Media Group (publisher of RDN) hosts the Enterprise Architect Summit. We bring enterprise architects, dev managers, senior technical experts and CIOs together in an intimate setting to discuss trends in enterprise architecture, and to exchange lessons and success stories with one another. I'm the program chair for the Enterprise Architect Summit, which will be held this year in Phoenix from Oct. 5-7. I'm looking for speakers and session ideas; send proposals directly to me or sign up on RedmondEvents.com.

In enterprise architecture, Web services continue to dominate the discourse in design and implementation. I've hosted or participated in the Enterprise Architect Summit for five years, and the growth of Web services and the evolution of services-oriented architectures have been the strongest trends during that time. The process of building new services -- and of taking existing apps and turning them into a collection of services -- is likely to take a decade or more.

The hard part isn't the design of the services or the functional code. Services design isn't all that different from designing apps in general. You need a broader perspective, of course, because you must fit together multiple services into a more comprehensive application or process workflow.

Likewise, for the most part, coding services is no different than coding a more traditional app. There's no inherent reason to use a different programming language or dev approach, and the code can be written, compiled and tested using tools you already use for the app-dev lifecycle.

Rapid Change
Where things start to get tricky is when you start building the interfaces. Contradictorily, you might think this is the easiest part of Web services. Data and special instructions are received, and results sent back, in a SOAP package, an XML structure that's a standard part of the Web services architecture.

In many cases, this takes place within the context of enterprise development, so the data and instruction needs are often known by the consumer of the Web service. But there are parts of enterprises that don't communicate with each other to that level of detail, and there are an increasing number of commercial Web services that can be called from the Internet "cloud." In these cases, Web services use the Web Services Description Language (WSDL) to provide this information. WSDL defines services as collections of network endpoints, and can be called by a Web services consumer to determine the data conventions of a specific service.

But calling a Web service gets much more complicated than that. You have security, organizational policies, Web services-integration support and other characteristics that are either defined in WSDL or in the Web services interface itself. All of this is defined in XML, so your first thought might be that it can't be that difficult. But XML is a very exacting structure and the standards landscape is fluid. You'll find multiple versions of several of these standards that need to be supported, for example.

Interface Tools
Testing Web services and their accompanying infrastructures is surprisingly difficult and complex, and because of the nature of the interfaces and XML definitions, it can't be done with your existing development and testing tools. This is where SOAPscope Server from Mindreef comes in. Mindreef spent several years supplying developers with its original SOAPscope SOAP debugger at a nominal price, and then followed up on that tool with a comprehensive team-based approach to Web services quality.

Today, SOAPscope Server is role-based, with separate but complementary offerings for services architects, developers and testers. The centerpiece is SOAPscope Server itself, which ties together the other versions so that team members are sharing test assets and results.

An especially nice feature is the ability to simulate the behavior of the target Web service for your tests. This addresses the problem of not being able to test your interfaces until the service itself is complete. Rather than wait until the last minute, you can pretend that a functional service is on the other side of your SOAP listener, and move forward with interface testing.

From my own experience, it's actually pretty easy to write a simple Web services interface and SOAP listener. But it gets complicated fast, and without security, policy enforcement and a host of other interface standards, your Web service will never make it out of the lab. SOAPscope Server helps you ensure that it does.