I'm not talking about the format in which data is transferred (e.g SOAP or POX or JSON). I talking about the business specific semantics used to represent the data. Just because two people speak English does not mean they can communicate. They must have a vocabulary they both understand. Have you ever listened to a NASCAR post race interview? I'm pretty sure that's English but I have no idea what they are talking about.
The same is true when developing services.
Web Services are officially the flavor of the month. Every project now at the very least involves a web service API and many utilize web services as their only business tier API. While this is a topic in of itself, as it relates to the topic at hand, this is root of the problem.
A recent post by Jeff Schneider points out this issue and leaves little hope for the traction it is getting. The desire and push to develop services has lead almost everyone to do their leaping before their looking. It is these same people who will eventually proclaim SOA just another passing fancy even though they did little to make it a success.
Of course in order to do this properly, an enterprise needs to provide its teams with the appropriate tools and resources in which it can be accomplished.
To name a few:
- A centralized object repository
- Tools for navigating and extending existing objects (both internally and externally managed schemas)
- A versioning solution
- An environment for hosting and referencing all internal schemas (e.g. http://schemas.mycompany.com)
- Governance around the use and proliferation of namespaces and objects (I'm talking to you EAs)
I am currently evaluating a solution I hope will offer all of these things so I will let you know what I find. Stay tuned...
