SOA Challenges

IBM Rational has identified five unique development challenges for web services, and admits that it can't solve them.

IBM challenge	RV Commentary
Network dependence - Most services rely on networking protocols (TCP/IP and HTTP) that were never designed to support high-speed application-to-application communications.	The use of these protocols leads to a technical preference for a particular style of communication: asynchronous (loosely coupled) pre-processed ("cooked") information rather than raw data This technical preference influences the granularity of service decomposition.
Loosely coupled, tightly bound - Web services define only the interface of an information exchange. This makes both producers and suppliers vulnerable to changes to supporting systems.	One cause of vulnerability is when the design makes assumptions that are not explicit in the interface contract. This calls for a form of design by contract. A second cause of vulnerability is when the service interaction fails to comply with the service contract. This calls for a form of web service management that monitors contractual compliance.
Anonymous usage model - Web service producers may not be able to identify the consumers of their service — or notify them when something has changed.	Advanced syndication protocols such as Atom should be able to support publish/subscribe modes of change management. In any case, we should expect the web service registry to provide a notification service. If all issues are channeled via the producer, then this generates a dependency: if the producer fails to identify a change, then the notification procedure is not properly triggered. However, syndication mechanisms can be deployed in a way that bypasses this dependency: direct notification of issues by consumers can be automatically communicated to other consumers with similar profiles. This leads to a form of federated change management.
Multiple systems and platforms - While Web services are "platform agnostic", the data encoded within them may not be. It's up to the developer to ensure interoperability across heterogeneous environments.	Web service protocols only address certain aspects of interoperability. We need processes to deal with various other aspects of interoperability, including data semantics. A solitary developer can only achieve so much interoperability. Many situations call for complex collaborations, and the responsibility for ensuring interoperability lies with the prevailing form of web service governance.
Evolving standards - Web services standards are continuously evolving to provide robust security, state management, or transaction processing.	Well really! IBM is a major contributor to the emergence of web service standards, and is therefore helping to create the challenging environment with which the web service developer is trying to engage. Why is this a challenge? We handle evolving standards the way we handle other aspects of evolutionary change - by stratification. This is one of the lesser aspects of the true architectural challenge of SOA: to build adaptive geometries through collaborative composition.

I don't think these five are even the greatest challenges for web services, and they are certainly not the greatest challenges for SOA. However, they are interesting challenges, and although there are some useful ideas and experiences around (if you know where to look), they are not (yet) well-known. We shall be spending the early part of 2005 disseminating our approach.