SOA Challenges from IBM

 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. 

Autonomous Services

Comments on ServerSide article by Stuart Charlton 

"XML Web Services are actually a specific case of the larger trend of leveraging extensible metadata as a means to make software more flexible and re-usable." 

This is only a partial characterization. Web services exemplify several interesting trends apart from this one, and have a range of other beneficial outcomes besides software flexibility and reuse. 

But Charlton's focus on leveraging extensible metadata is useful, and raises some important questions about process and order. The value of extensibility depends on who does the extending, and how. Uncontrolled and ungoverned extensibility leads to XML chaos, and does not contribute to the reuse agenda. 

 "[Do not assume] that the developer of one service has any authority to change the implementation another service. [Assume] that in any distributed system, each participating service is autonomous, allowing each to evolve independently of the other." 

This injunction is valid, but doesn't go far enough. With installed software components, the developer may have no right to change the code, but usually has the right to stick with the code she's got – for example, to decline or defer version upgrades. With services, she may have no authority to prevent changes in implementation, and may not even have the right to be notified of such changes, since the service providers may assume (not always correctly) that internal changes will not affect the external characteristics of the service. 

"XML represents a new data model that differs significantly from the traditional programming models of relations and objects."

XML is a notation that allows relational, object and other styles of data model to be expressed. However, XML's preferred style of data model is a tree structure: the traditional hierarchical data model, on which DL/1 and IMS/DB were based. Older developers may like to think of XML as DL/1 on acid. 

Charlton ends his article by recommending different styles of data model for different categories of data. This is useful practical advice for developers, but leaves open the architectural question of joined-up data: how to manage business adaptability and data integrity across these different styles.