Interoperability is the ability of two or more systems to work with each other. In the loosely coupled environment of a service-oriented architecture (SOA), separate resources don't have to know how each of them work, but they do need to interoperate with each other by having enough common ground to exchange messages without error or misunderstanding.

Adopting SOA is a lot like gardening. It takes time, skill, a lot of hard work, and the process can be messy and even a bit frustrating at times. I know you've probably heard tons of different analogies that attempt to put SOA and governance into everyday terms and I'm sure that growing the SOA 'garden' through governance won?t be the last.

While EDI transactions account for most worldwide commercial activity, XML-based alternatives are beginning to gain traction. According to Forrester Research, stateful XML, stateless XML, and even flat file exchanges are all projected to grow at a faster rate than EDI over the next few years. The firm predicts stateful XML transactions will be required for a growing number of B2B process-oriented transactions and are projected to exceed the growth of EDI transactions over the next five years.

If you read this column and listen to my podcasts, you know that I call SOA what SOA is - an architectural pattern. In many instances, SOA is a vital component of healthy enterprise architecture. Indeed, I've provided some keynote talks around this very topic at about half-a-dozen enterprise architecture conferences to date. However, generally speaking, the enterprise architects out there still don't 'get' SOA, and they continue to do a poor-to-average job of creating enterprise architectures that...well...support their enterprise.

Composite applications are made up of discreet services that have been tried and proven reliable, but building an orchestration that incorporates services that come from several sources, some of them outside of the company, could introduce testing hazards beyond just bad output. For example, let's say that your business has a process that includes activities to run a credit check with an external credit agency or to schedule a package delivery with an external shipping service.

Not all services are created equal. It would be great if implementing SOA were simply a matter of applying a standard design pattern to all services. Once IT had identified and codified an optimal design standard, services could be stamped out in assembly-line fashion until the IT landscape had been transformed. Unfortunately, we don't live in a cookie-cutter service Utopia.

The way business applications are evolving, enterprises are learning to accept and embrace the notion of applications that they neither control nor host. Now enterprises are leveraging applications that run a business through the Internet platform. As these applications become core to many businesses, so does the need to incorporate these applications into the enterprise's existing infrastructure and make them work together.

We've all experienced the thrill of acquiring a new product only to have it diminished when it's not as easy to use as expected. You rip open the box ready to start playing with your new gizmo and 20 minutes later you're stuck on the phone with tech support because the instruction book was incomprehensible.

To mark a new standard in the SOA space, I create a Google Alert and sift through the pile of links returned to get the scope of its maturation. I'm currently tracking over 60 standards, starting with SOAP and XML (XML happened way before Google was cool).

Last month an alliance of leading vendors announced progress on specifications to define a language-neutral programming model for application development in SOA environments. They call this specification Open SOA Collaboration. In essence, they are proposing a new standard to create and manage IT, making the process of integrating different third-party SOA technologies 'less onerous,' they say. Or, we can call this a standard way of delivering services, making it easier to work and play well together.

It can be difficult for developers, architects, and managers to keep up with new software packages and releases. This can be especially true with fast moving technologies like Web services. This article provides an overview of the main technologies that comprise the Java Web Services Developer Pack (Java WSDP). For more in-depth knowledge of the WSDP, simply download it and walk through the examples or complete the Java Web Services Tutorial. In an effort to standardize XML and Web services-related technologies, Sun Microsystems has developed implementations of popular standards and published them under the umbrella title of the WSDP. The toolkit's stated purpose is to simplify the development, testing, and deployment of secure and interoperable Web services. Version 1.5 is the latest release of the WSDP and contains many updates to existing technologies, new features, and a collection of bug fixes. This article will examine the main technologies provided in the WSDP and review their purpose and status.

There is an old saying among standards wonks: 'The most wonderful thing about standards is that there are so many of them.' And this truism is more applicable today than ever before. There are so many WS-* specifications, I've started referring to them as WS-Vertigo.

It is sometimes beneficial to stop what you're doing, take a look around, and see where you've come from and where you are going. This regrouping is taking place right now across the software industry and is focused on the problem space of Web service description, discovery, and integration. At a high level, this article briefly discusses the progress made to date at solving the problem, describes the benefits and shortcomings of current technology, and presents a vision of the possible future of Web services infrastructure.

Agile and adaptive business processes and supporting IT infrastructure are the holy grail of enterprise applications. The industry is heading in the right direction to start delivering on this promise.

The current slate of Web services standards has evolved into a mature set of very useful API's and into service-oriented architectures, or SOAs. Enterprise integration, however, includes many requirements that are not met by SOAs alone. A movement is under way to augment Web services with a new set of standards that address the other side of integration - Event Driven Architectures, or EDAs.

There's a common misconception that Business Process Execution Language for Web Services (BPEL) is useful only if all of your systems are Web services. This article describes how Web Services Invocation Framework (WSIF) enables BPEL to orchestrate nearly any legacy system as if it were a Web service - without having to explicitly wrap or publish it as one.

Implementing industry standards for business processes can do far more than provide a common protocol for operations. Once commodity information or documents are standardized, it makes sense to look at what common actions need to be taken on that data or document - and standardize those as well.

There is a need for container-managed support for local invocations among colocated Web services. This feature would be similar to EJB local invocations in the J2EE world.

Business is becoming increasingly virtual and decentralized, while real-time management of relationships with employees, contractors, partners, suppliers, and customers is becoming ever more crucial. Even within a single company, applications may reside on different platforms, in separate departmental security domains, in legacy databases derived from prior acquisitions, or (thanks to outsourcing) in separate companies.

UDDI (Universal Description, Discovery, and Integration) is fast becoming a standard for storing business processes available on the Web. Although UDDI is capable of storing many different types of data, for the purposes of this article I'll focus on how UDDI can be used to register Web services, thereby making them available for application-level consumption.

In recent years the application server has greatly evolved, expanding the set of core services provided by the infrastructure. The current Java platform supports XML data handling, scalability, load balancing, and other capabilities that allow application-level services to be developed more easily and deployed more reliably. This progression must now address developers' latest concerns regarding security, distributed transactions, and reliable messaging because applications no longer stand alone - they're deployed into a technology ecosystem that can span departmental and organizational boundaries.

As enterprises build a critical mass of Web services, they need some way of keeping track of those services. UDDI is an ideal store for such information. Using UDDI's built-in abstractions of business services, binding templates, and tModels referring to interface specifications, UDDI can be used to manage all of the addresses and protocols and formats of those services.

Web portal software has emerged as one of the most important components of software enterprises over the last few years. That success has carried with it the challenge of how to integrate disparate software services into the portal - services that can live across multiple platforms, operating systems, and networks.

In July 2003 a consortium of Web services vendors released the Web services Composite Application Framework (WS-CAF) to the community. WS-CAF is comprised of three specifications that together provide a means of reliably composing individual Web services into larger aggregate applications.

When dealing with application integration, as you know by now, we are dealing with much complexity. The notion of ontologies helps the application integration architect prepare generalizations that make the problem domain more understandable.

There has been much debate lately on what exactly WSDL's purpose is, and much of that debate has focused on whether WSDL is an interface definition language (IDL), or whether WSDL is better used to specify message-level contracts (without any associated operational semantics).

Over the past couple of years, several technology vendors have defined a comprehensive set of specifications that, when complete, will provide an infrastructure for enterprise-class Web services interoperability. The names of these specifications generally begin with 'WS-', so the group of them is sometimes referred to as WS* (pronounced 'WS Splat').

As more enterprises move toward an e-business strategy, the communication and integration of disparate, heterogeneous applications and systems is key. Businesses must be able to securely connect and communicate with customers and trading partners alike.

Web services has the potential to solve some of the most difficult technology and integration problems that have plagued IT departments for decades. Isolated systems, redundant code, extended development cycles, and vendor dependence have essentially been accepted as inherent side effects of enterprise computing.

Web services hold the promise to revolutionize the way architects build systems and how software is delivered and sold. While the full realization of these advances will take years to play out, most of these benefits are rooted in technologies that are available today. This article will look at what can be achieved today using Web services technologies to prepare yourself to take advantage of Web services as the standards and tools mature.

In the past two years, we have witnessed an explosion of Web services and XML communication technologies. While WSDL , SOAP, and UDDI have become the accepted bases of Web services, there are even more standards in the making.

Web services has the potential to transform e-business into a plug-and-play affair. Not only will Web services simplify how businesses interconnect, they will also enable businesses to find each other.