Predicting the Future

As I look at the current state of interoperability and the possibilities and opportunities that exist, a number of areas stand out as critical for enabling true interoperability within organizations. These areas are discussed in the following sections.

Acceptance and Agreement of Standards

Within the area of Web services, the acceptance and agreement of standards is currently ongoing and will likely continue to evolve at a fast pace. In the current market, we can already see widespread participation in the WS-I (Web Services Interoperability) organization. The success of these efforts will drive and promote more standards between more vendors , making interoperability between diverse products more of a reality.

I also welcome the coauthoring of these standards. Although a single vendor can easily announce new specifications, it's reassuring to hear proposals from a consortium of vendors. This type of cooperation not only helps the credibility of the specification, but typically also results in a multiplatform implementation and a quicker rate of adoption.

Vendor Adoption of Standards

As standards become accepted, we'll see tighter coupling with products and services from all vendors. For example, with many samples in this book, we have had to download toolkits, run command-line operations, and in some cases apply manual alterations and fixes to get the code working. Moving forward, I predict these toolkits will become simpler, more integrated, and possibly shipped with both the platform and application servers. The command-line operations will also be replaced by more IDE-aware tasks (for example, the ability to right-click a component, create a Web service, and apply WS-Security and WS-Routing by choosing settings from a dialog box).

Competition at the Implementation Level

A market that is driven by standards will see more and more competition at the implementation level. If solutions demand interoperability, creating and using a proprietary way of data exchange will no longer be an option. As this is the case, I believe vendors will start to compete more at the implementation level making more robust platforms, more robust application servers, and slicker development environments to differentiate themselves .

Architecting Interoperability

The majority of development products today tend to be geared toward a single technology, be it .NET or Java. Typically an IDE will allow components from only one platform to be created. This paradigm has started to changewith many IDEs allowing external Web services to be referenced or multiple projects to be created based on different languagesbut I wonder if at the architectural level this is enough. As a developer, I might want a more complete view of my application. For example, I might want to show the components that have been developed for .NET, the protocols I am using, and how this integrates with my Java/WebSphere MQ implementation.

One key element of this concept would be to support debugging between the two platforms, although I think that's a long way off. The ability to debug a component on .NET, for that component to call a Web service in Java, and for the debugger to attach to that process makes for an interesting set of possibilities.

Management, Operations, and Deployment

Management, operations, and deployment of interoperable solutions is something that needs addressing. Today, the ability to deploy an application that consists of multiple parts is difficult. Take those multiple parts and move them to different platforms, and the problems become exponentially difficult. Once the deployments are configured, you are faced with the question of how to manage the uptime of the application or service, version control, and upgrading of the components.

Within this area, I believe we'll see much more focus on Web services management in the near future. We are already seeing a number of companies creating offerings in this area, and I predict this will not only grow but will encompass the management of .NET and Java Web services in a single product.

Shift to Loosely Coupled Thinking

We've all read about how Web services enable loose coupling from a technology perspective, but I think building interoperable solutions requires a more loosely coupled approach from a thought perspective also. Although current technology allows for a loosely coupled approach, it's still possible to use it to unintentionally build a tightly coupled, RPC-based model.

We need to think more in terms of coarsely grained services within the enterpriseall of which interact with each otherand less about applications that merely fit a purpose or task. If companies adopt this services-based approach, the orchestration of those services will define very flexible and reusable applications.

With this goal, interoperability then becomes much more of an enabling technology, as opposed to something used solely to connect applications together.

Desktop Integration

Finally, many samples in the book have shown standalone clients or a Web- based experience for the user . As mentioned previously, I believe that integration with existing Microsoft Officebased components, operating system components, or both is something that is vastly underused and undervalued.

For example, with Microsoft Office I already have a proven, reliable interface for managing financial data (it's called Excel). Why not leverage the power of this application by using Web services and interoperability to connect with my server-side data. Granted, it might not be as exciting as creating something anew in ASP.NET or an alternative smart client technology. From my experiences of watching users understand and usewith little or no trainingapplications based on the concept of interoperability, I can attest to the amazing positive impact this type of desktop integration has.