Resedel - Updated

John Cowan's entry into service definition language Recycled Knowledge: Resedel. Looks good I think as I am better with Schema than RelaxNG. (Update - thanks to trang here is a XML-Schema version of Resedel resedel.xsd)

Biggest question is why translate HTTP-GET et al explicitly into CRUD - expose the URL verb, another layer of abstraction can be confusing.

Service Descriptions - Just the docs?

Couple of interesting posts: Dare Obasanjo aka Carnage4Life - On Replacing WSDL with Something Simpler and Mark Baker- ongoing - SMEX-D.

Both make the point that having an interface language for services should not do very much. From my POV I want primarily a means of getting accurate documentation on the interface (and also providing it to consumers of services). For all its warts Javadoc was a great step forward as it provided a way for developers to provide documentation will minimal effort. Until Javadoc the best examples of standard docs that I had experienced had been man pages, and some Lisp environments.

For services to be propagated widely there is a need to provide documentation that is easily created and kept up to date. Perhaps this is the starting point for a service description?

the simplest thing that can possibly work

Quoderat » Problem-first design - great POV and quote

Service Descriptions - There does not need to be just one

There has been some really good analysis and thinking about service description languages recently by several smart people (Tim Bray:SMEX-D, Norm Walsh:NSDL, Mark Nottingham). Everyone of them makes some excellent suggestions and brings a unique POV. One of the challenges that everyone is assuming is that there needs to be only one service description language. I challenge this assumption and suggest that more than one is actually preferably.
The are a few reasons for wishing there should only be one service description language:

• We have a mind set that is framed by the Web publish-find-bind triangle where we assume that magic happens by everyone automatically discovering services and magically binding to them to solve complex business problems. This implies that there is a many to many relationship between services - all services need (and can) talk to all other services. In the real world this is more like one to a few or few to a few - a slight over design.


• There is the burning desire for protocol independence - between companies there is unlikely to be a placement for HTTP/SSL anytime in the future. As the enterprise architecture is slowly being decomposed into services provided by outside organizations I would suggest having a single transport is more important than have transport/protocol independence. If the transport information is cleanly separated from the message there should be no issue in replacing it with a different transport - a good example is EDI and AS/2
  
• The complexity of integration is not in the communication of messages it is in the integration of the semantics after the message has been received. Currently we are doing several integrations a month with a wide range of systems. The message delivery is not the problem it is the semantic meaning of the messages and this is in a single well defined vertical.


• Tool development has always been a good reason for having a single set of standards that all vendors build. The tools are complex because the service description is complex, and there is a lot of complexity introduced by RPC. If we focus on the message (where the real integration occurs) there are really good tools available, XMLBEANS for Java does a truly great job of providing a binding between XML and Java, similarly XSD for .NET and I am sure there are many others. These tools work on basic schema's and are generic tools - rather than specific more complex tools.

One of the really good aspects of the service description languages described by Tim Bray, Norm Walsh is that they use the same vocabulary as the transport i.e. HTTP -this makes it a lot easier to understand as it does not add another layer of verbal indirection. This reduces the learning curve and hopefully the ambiguity. Having several service description languages is not an issue if they are all in xml they can be transformed from one to another easily. As the transformation is a design time dependency and not runtime a runtime one there is no performance penalty. The major issue may be loss of meaning but there are only a limited set of MEP's so this should not be a long term issue.

The tendency today for web services is to add more features and hence the complexity is increasing. Shift the focus to how simple they can be and reduce complexity, lets see how easy it can really be.

The focus must be on the communication of information and not overly abstracting the service descriptions to a point where everyone just gives up and writes word documents.

Building knowledge from parts

Google has done a great job of decomposing knowledge and making it accessible but is it possible to build knowledge from parts in an automated fashion.

The first questions two ask are 1) Is it possible to build useful knowledge for components in an automated way - (Rooter a machine generated would tend to suggest otherwise:-)) 2) why would we want to do this.

For me the why is the information overload caused in large part by change. A tool to categorize and filter information intelligently would be a better Google. Navigating down to page 15 of a Google search to find a nugget is not very productive. Though compared to the alternative it is a major step forward. Being able to compare and contrast becomes even more interesting an intelligent Google Fight (thanks to Mark Baker for the pointer) may be an interesting starting point. Rather than distill knowledge provide the ability to contrast and compare POV - something our political process badly needs.

How about parallel news tickers showing pros and cons on a viewpoint to help decide on a course of action. How about an uncertainty measure - we all know the uncomfortable feeling of not having enough information to make a decision - does it help to quantify. We live in an imprecise world is it possible to measure/estimate the degree of ambiguity?

So search is great but it is just the start - we have parts now what are we going to build to create new knowledge and understanding?