Decoupling clients from web services

[Aleks Seovic]

How does everyone feel about allowing for pluggable message processors that could be used to transform request/response messages after serialization and before deserialization.

I guess it would be somewhat similar to SOAP extensions, except for the fact that it could be easily configured using Spring and that we would provide few standard processors out-of-the-box, such as XsltMessageProcessor for example, that would allow you to configure XSLT template to use, for example.

The reason I'm asking is that the more I'm thinking the more XSLT seems like the best solution for the message-to-domain mapping we discussed. It allows you to serialize your objects any way you want and then transform the serialized XML into the schema required by the target service. The same thing applies for response messages -- you can easily transform them into the schema required by your domain model.

A drawback is that some people (Mark included) don't like to use XSLT unless they absolutely have to, and shy away from anything that requires them to write it. I personally don't mind it, although I can't say it's one of my favorite things in the world. It does get the job done, though.

Another drawback is performance -- as we all know, XSLT is not the most performant technology around, but I don't think it would have a big impact in this case. Each template would be parsed only once, when the context is loaded, which solves the biggest performance problem with XSLT. Actually, I think that overall it might be faster than all the reflection and dynamic serializer type generation that is used by the standard .NET web services infrastructure.

However, there are benefits as well. Unlike custom serialization configuration schema that we might come up with, XSLT is a standard and there are good tools for it that would allow users to write and test their templates. In many cases, they also wouldn't have to learn one more new thing (and even if they do, XSLT, well, at least basic XSLT knowledge is a good tool in a developer's toolbox).

As you can probably see, I'm a bit torn on this one myself, so any feedback, opinions, suggestions, even flames telling me I'm out of my mind for even suggesting this would be highly appreciated. And of course, make sure that you vote for your preferred option above.

Regards,

Aleks

[smhinsey]

I think I like this idea. The XSLTs would basically act as assemblers for converting DTOs to domain objects. That's pretty nice.

I think that taking an Nhibernate-style approach to the mapping files would be nice as well. Use Spring to configure a namespace to look for the XSLTs as resources within your assembly. Of course, it would be helpful if this were optional.

That would give you the ability to internationalize your domain objects. A classic example of this is a service method that returns a localized list of options. Your XSLT could convert it to an enumeration with automatically localized descriptions.

I also think there might be some really interesting intersection here with the work being done on the validation framework. If the domain mappers could easily tie into that framework, it would make for straightforward validation at your service boundary with a nearly transparent implementation.

[Aleks Seovic]

I think that taking an Nhibernate-style approach to the mapping files would be nice as well. Use Spring to configure a namespace to look for the XSLTs as resources within your assembly. Of course, it would be helpful if this were optional.

One thing I want to be able to do is define different transformations for the same type, which would require templates to be configured explicitly. They could be stored as assembly resources however, or as any other resource that has corresponding IResource implementation, for that matter.

Another question that we need to answer is, if we do this, what should be the granularity of the transformation templates? My original thought was that they should be at the message level, but your suggestions implies that they should be on the type level. Both have pros and cons, so again, what does everyone else think?

- Aleks

[smhinsey]

How would you envision this working in a message-based fashion rather than types? It seems like either way the goal is to convert from one type to another.

[Bruno Baia]

How would you envision this working in a message-based fashion rather than types? It seems like either way the goal is to convert from one type to another.
granularity.
You should need multiple types to make one message.

Messages are more approriate for services specially if you want to decoupe clients from services.

[spmva]

I greatly dislike XSLT, but I wonder how a proprietary format would be any less complex to manage. For that reason, I celebrated the democratic process by voting "Yes" for XSLT.

[spmva]

After some thought...in terms of granularity, I think that the message level is the correct place for transformation templates. It provides the highest degree of flexibility. I admit that I was very much thinking in terms of types at first, but the thought of having the ability to provide more than one mapping to the same type sounds useful.

Assuming I'm thinking about this the correct way, I guess a con for message level granularity would be possibly more XSLT to write....correct?

steve

[smhinsey]

I don't really think that there is any difference at all between translating a message and a type. It was sort of my assumption all along that nested or multiple types would be translated as they were encountered.

I do like the idea of having custom translations for specific scenarios, though. I can see where that would be useful in cases where you get a huge list of types in a report. The application might want to transform that huge list into something other than the actual type.

[spmva]

Anyone else find it interesting that this thread isn't so interesting (at least to what seems like a majority of people)? Why isn't this a hot topic? I was excited with where this was going. .

[spmva]

I really liked where this XSLT concept was going. Though there hasn't been much going on with this thread, I'd just like to add that I implemented this concept in an integration between my .NET web service layer and a third-party Java-based business intelligence platform.

I used XSLT to convert SOAP messages to XML that the XmlSerializer could understand. I then passed back my newly deserialized domain object(s) back to the client calling my web service.

I didn't build it as a pluggable message processor as aleks suggested, so it's not the most re-usable thing. That's not to say I came up with a better way to do it, I just chose the path of least resistance to get things going...I needed a solution fast.

[.ben]

This would certainly solve some problems, as more then just public fields could be serialized. Interesting approach.