thinking-out-loud

Ron over at ZapThink says:

The real challenge to applying REST as a means to implement loosely-coupled Services is that REST has no explicit contract to define behavior, which means that all behaviors are implied. In REST, the data pumped through a GET, PUT, or POST operation contain all the semantics necessary to understand how a Service behaves.

Therefore, REST isn’t appropriate for organizations that wish to take a contract-first development approach aimed at maximizing reuse and composition, in addition to loose coupling. And that’s the rub with REST – SOA aims to reuse not just the resource, but also the operation and the composition as well.

[Emphasis mine.]  Hmmm. I was thinking that the contract is explicit (for purists or pragmatists). Of course, I don't work for a research firm, so there you go.

"Data pumped." He makes it sound as if the data is encoded with the application semantics and is merely being "tunneled" over HTTP rather than the application is using HTTP to broker the application state. Oh wait, but isn't that SOAP? File under 'M' for misunderstanding. Ron, here's a suggestion for some research. Pick a problem worthy of a services and/or restful solution. Solve it twice, once with REST and once with WS-splat. Hire some high-priced consultants to help you get each "right," if necessary. Publish the results. Boy, now that would be nice.

Indigo's CTP out

Don Box let the indigo doc cat out of the .net bag. You can also get the latest CTP from subscriber downloads if you have coughed up for the msdn subscription. The world is one step closer to becoming a better place for soap lovers everywhere [as long as you're on the ms platform :)].

TexMex 1.7 -- link doesn't 404 anymore

In my previous, sleepy state, I apparently failed either to upload the zip file to the server or to wait for it to complete. In my new, sleepier state, I can't remember which. Regardless, it is now uploaded.

Have a nice day!

TexMex 1.7, WS-MetadataExchange, three-alarm spicy!

My poor, sweet daughter is teething--four molars. Ouch. She had a hard time sleeping last night. I sleep very lightly as it is, so I also had a hard time sleeping. One the old ticker starts to ticking, I can't stop it, and I usually have to get up and do something. Now, if I Iie there, I tend to have a million amazingly wonderful ideas escape from my brain. As soon as the body goes vertical, though, they all go away. A shame.

So anyway, at least I had some time for hacking. I didn't get to the configuration, but I did a lot of clean up that I wanted to get done. I do remember one thing from when I was lying down and thinking. I thought a lot about how I would want to code around the fact that we as an industry choose to conflate semantic chunking (i.e. namespaces) and versioning into one thing, namespaces. Sometimes that makes sense, because the new version is semantically distinct enough, but for nominal uses of Soap and WS-Addressing, the namespace differences are just annoying.

System.Xml.Serialization will let you get away with a lot. System.Xml.XPath... not so much. What I would really like to be able to do is to say "Please consider these two namespaces, urn:a and urn:b to be synonomous, and pretend that they are the latter," and I think that could be relatively easy to do with a custom xml reader, but I haven't done anything about it yet. Maybe soon.

WS-Addressing+Soap=Soap

So the question is this: Now that w3 owns ws-addressing and soap, shouldn't soap 1.3 be soap 1.2 + ws-addressing internalized under the soap xmlns umbrella?

WS-Addressing, refprops-b-gone

Via Mark Baker. The WS-Addressing group agrees to remove the ReferenceProperties. Nice. I was also happy when they closed the following, even if the motivation is just a standardization issue. It is helpful in bootstrapping, I suppose, but it just didn't feel right.

The WS-A Submission normatively references WS-Policy, which is not a recognized standard.

Resolution 2004-10-26 - We will not reference the WS-Policy spec.

I wonder whether this particular bit of the design is going to sneak its way back in as a part of the ws-policy spec? I also wonder what impact it has on the vendors that are implementing these specs - indigo, anyone?

Note also, that Mark got a 98 on the Nerd test.

Mine:

I think that one of the questions should have been:

The url of your blog:

1. Contains your name.
2. Is intended to be funny.
3. Has a science, science fiction, or technology reference.
4. Has a math reference.
5. Contains the date it was created, because you are religious about cool uris.

The latter of which would, of course, push Mark up into the 99th percentile, while the fourth would have given me a little boost.

TexMex, WS-MetadataExchange

A new cut. I have started to refactor the serialization into a object model for data transfer and to address the client side a bit. The client side is currently coupled to WSE 2.0 sp2 for convenience, but as the aforementioned object model gets fleshed out more, I will remove the dependency to allow for soap 1.1/1.2 and WS-Addressing 0304/0804. I am going to look into Dilip's requests now.

Using default ASP.NET Wsdl Documentation with TexMex

Dilip comments on TexMex and makes a couple of requests:

I'd love to see support for configuration based metadata as opposed to it being attribute based. The idea being, I'd rather not modify my services if I dont have to! * I'd like to see it reuse some of the service metadata that comes from the asmx model... i.e. http://uri/HelloWorld.asmx?wsdl

The first one shouldn't be too bad -- I'll see what I can do. I figure I will use an XmlSerializationSectionHandler-style implementation. (Then I will need to get Christian Weyer to let me integrate with WsContractFirst, so that the configuration is automatically generated :).

The second one is actually supported in the sense that you could add a MetadataLocation attribute referencing the ?WSDL doc url.

[MetadataLocation(Dialects.Wsdl11, "http://idontexist.com/my.asmx?wsdl", "urn:my-identifier")]
public class MyService
{
  // impl
}

It is unfortunate that the url currently has to be hard-coded, which of course makes it difficult to use the same codebase in multiple environments - dev vs. prod. I may rework it to accept relative uris.

Additionally, I have been thinking about integrating ServiceDescriptionReflector - i.e. when initializing the MetadataService from the attributes, provide the service type so that the MetadataReference can reflect the description and/or schemas. I could also make it default to support that, I can check to see if documentation is turned on, and if so, auto-generate the wsdl. I would rather build the tool to encourage Contract-First, but it seems like a reasonable marriage of the default asp.net model and TexMex.

I have another cut of TexMex (1.5) coming out this afternoon that fleshes out the client and DTOs a bit. I will look into the latter request for 1.6 and the former for 1.7. Thanks for the feedback, Dilip!

TexMex dependencies

I forgot to mention, TexMex currently depends on WSE 2.0 sp1. I will upgrade to sp2 to be current for the next drop of code.

TexMex 1.4, WS-MetadataExchange

Today's cut. I think that this one is relatively faithful to the spec. Of the issues I mentioned earlier, this version should correctly handle:

WS-MetadataExchange Semantics

1. GetMetadata w/ Dialect where no satisfactory dialect exists returns an Empty Metadata element.
2. Support Multiple MetadataSections with the same Dialect/Identifier pair
3. GetRequest with valid To

Another TODO: I need to make a proper separation between the client and server code.

Enjoy. If you have any suggestions, feel free to leave them in the comments or send mail to TexMex.