SOA Standards: Defining Common Standards

On your first SOA project, your choice of infrastructure and technologies may not have been a critical success factor. However, as your initiative moves from project level to enterprise level, sharing common SOA standards across projects becomes a critical success factor – if your services don't "speak the same language", then service reuse will be difficult and costly. This can lead to failure of your overall SOA initiative.

The first level of defining standards is deciding on the application interoperability standards – how will services talk together. This list typically includes XML, SOAP, HTTP, and UDDI. Beyond these base standards, you need to consider your security strategy. Note that, as much as possible, you should be choosing standards not products. Over time you will have many different applications and services talking together. Some will be built in-house on your current application platforms, some will be built in-house on future application platforms (you may, for example, choose to switch your application server vendor at some point in the future), and still others will be part of commercial, off-the-shelf applications. In many cases, the consumer application will not be built on the same technology platform as the service provider application. You need to make sure that your choices for service communication don't constrain your ability to add new applications to your SOA "network". As such, choosing open standards that are supported by a broad range of vendors is critical to the long term success of your SOA.

Note that there are two dramatically different types of open standards: API standards (such as JMS, JDBC, and ODBC) and interoperability standards (such as TCP/IP, HTTP, and XML). While API standards are important, they still have several key constraints: they are platform specific (for example, JMS only applies to Java not .NET) and they are vendor specific (an application that supports MQ Series cannot talk directly to an application that supports TIBCO even though both applications may be written using JMS).

You would need yet another layer of infrastructure (e.g. messaging adapters) to try to get them to talk together. In contrast, with interoperability standards, the consumer and service provider applications, even when written on dramatically different platforms, can talk to one another provided both support the same interoperability standards. Be careful to choose interoperability standards that have the widest adoption to avoid constraining your choice of platforms.

Once you've chosen the common application interoperability standards for your organization, the next set of standards you need to consider involve security and management. A unified security architecture is critical as you will have many cross-application interactions and if each application has a different security model, it can lead to security holes and increased costs for managing and maintaining your SOA environment. Similarly, a unified management strategy will enable you to get a big picture view of your SOA across projects – a view from the perspective of the business processes it supports, not the silos that make it up. This will allow you to more effectively control the SOA, ensuring reliability and robustness. Remember, you can no longer rely on the security and management built into any one platform. For the same reason you need common standards for interoperability, SOAs are heterogeneous by definition but management and security must span the SOA.

In summary, choosing and deploying services based on common standards throughout your SOA is critical. Relevant standards include those associated with interoperability, security and management. An appropriate eye on standards up front will allow you to more effectively control your SOA, enhancing reliability in the future.

For More Information about SOA Standards

Take care to implement SOA standards throughout your SOA migration. Don't fall prey to the "worst practices" described in this free white paper, SOA Best Practices – Not!