thinking-out-loud

Advanced WCF Development

I've recently had the opportunity to join a client's team building an ESB solution using the Windows Communication Foundation (WCF) with requirements for security, logging, load distribution across a managed group of hosts, and more.  As you can see from my list of books here on my site, I spent some free time over the holidays reading up on WCF.  It seems that everything published about WCF so far just covers how to write and host services.

The best organized book I found that presents all the key concepts and somewhat covers extensibility through behaviors is Pro WCF by Chris Peiris and Dennis Mulder.  I've also reviewed Programming WCF Services by Juval Lowy, which has a somewhat shotgun approach development with WCF, great for coding, but doesn't really cover WCF extensibility. 

The best references I've found on extending WCF are Mark Gabarra's blog and this great, detailed MSDN article on WCF extensions by Aaron Skonnard, which gives full examples of extending WCF in a variety of ways, including behaviors.  I'm currently prototyping a WCF service with extensions at a variety of points and will post more as I make progress.

Web Services with MOSS

My current project requires web services accessible from InfoPath forms that all together integrate with MOSS.  My former colleague, Steve Walker, has some advice on managing security issues with web services accessing data in MOSS. 

But my current problem is that my web service doesn't act the same when hosted under MOSS as it does in a stand-alone site on the same server.  In fact, it's broken.  Here's the situation:

• I created a web service with several web methods in .NET.  I test the execution of the methods from VS2005 using the browser.  All is well.
• I publish the web service to a site hosted in IIS.  I setup the site to use my MOSS application pool, to execute scripts, and to allow browsing.  Now I can browse the site and get the handy web service test page.  I click on an operation, enter the parms, and invoke it.  All is well.
• Now, if I connect an InfoPath form to that web service and publish it to a form library in MOSS, upon creation the form fails to connect to the web service because the web service is in a "different domain" (not really....but that's what it says).
• So, we avoid the "different domain" problem by publishing the web service under the MOSS application.  Do this by creating a Virtual Directory under the MOSS application's web site.  Like with a stand alone web service site, go to the properties on the vdir, create an application, and set the permissions to run scripts.  Publish the web service to this new location (only accessible to VS2005 by the file system, not via local IIS) and test it out.  Initially, all *seems* fine - but some of the operations don't work.  After entering parms and clicking "invoke", the operations result in a 500 server error. 
• Oddly, I have the service hosted in the stand-alone site and the vdir under MOSS at the same time and it behaves differently depending on the URL used to access it.  Stand alone it works, and managed by MOSS it fails....on some operations but not others.

I think the solution may have to do with the "Web Service Proxy" page found at the bottom of the Application Management page in Central Administration.  It would be nice if the help files mentioned it or if the search in the help files could find anything remotely similar to my search criteria.

Update: Here's a good page on the Web service proxy and managing data connection files.

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.

Versioning and Mangaging Web Services

My buddy Joel over at Geniant has collected some nice links on the issue of designing versioning and extensibility into your SOA.

And my friend Andy at MS suggests these techniques for creating manageable services:

• Use complex-type messages, not simple type arguments. For instance instead of creating an operation like Customer GetCustomer(int customerId), create one like Customer GetCustomer(CustomerIdentity customerIdentity) this will allow each message to be created in an extensible way.
• Make each message extend from a base message that contains Xsd Any members for both elements and attributes. This will allow members to be added or removed from the message in the future with out breaking the existing consumer serialization.
• Separate the message classes from the implementation or domain classes. Keep a nice clean layered separation between interface and implementation. This will allow for better control on the interface and eliminate changes in the implementation that break the interface.

Patterns for SOA and the Enterprise Library

I was recently sent a copy of Ron Jacobs' presentation on Patterns for Service Oriented Architecture.  It's not too deep, but I agree with it completely.  And, clients who went to see him present it at the local DNUG said it helped them better understand how SOA is relevant to their enterprise.  Every little bit helps.

A couple of days later I had the pleasure of meeting Ron and hearing him present on the Enterprise Library.  While it's been around a little while, many still haven't heard of or at least used this collection of "application blocks".  These components simultaneous add architecturally significant capabilities to enterprise apps easily while exemplifying via open source the MS way to structure code.  Version 1.1 was recently released for compatibility with .Net v2.0.  A new version of the library (v2.0?) is due out in a few months, implemented in .Net v2.0 and exemplifying its use.

Ron's a fun presenter and apparently shares a disdain for Typed DataSets being used in all MS developer tool presentations.  "They have their uses", he allows, implying not many.  My question is, when will the rest of MS start evangelizing good architecture instead of just binding user controls straight to SQL queries or Typed DataSets?  Layers, people!  Layers!

On the (sort-of) cutting edge, Ron very briefly showed the practices and patterns team's up-coming Guided Automation Tool (GAT, as in "I got my GAT and I'm not afraid to use it").  Didn't see much other than yet-another-code-generator for Table Data Gateways, yawn.  When I inquired about the now defunct ObjectSpaces he said, "This is infinitely more flexible."  Uh-huh.... Infinity is a very big number.  Guess we'll just have to wait and see. 

Coupling and, eh-hmm, er, Cohesion?

David Linthicum chats about coupling and cohesion. As I am reading through it, I get feeling that I am looking in on some isolated culture in a remote region of the world where the language is remarkably similar to the language I know, but the meanings are completely different.

His "definitions" of coupling and cohesion both describe coupling. There is a simple way to tell the difference between the two, though. Coupling is a relationship between concepts. Cohesion, on the other hand is a metric reserved for a single concept (or a group of related concepts treated as a whole.) Cohesion is not really about relatedness. Cohesion is also not about completeness.

Cohesion is more about integrity. Dogs bark and Dogs wag their tails. Neither is necessarily related or similar, but if they were to be a part of a model of Dog, that model would be cohesive. Evaluating cohesion is about evaluating the 'Dogness' of the Dog model.

The worst thing, to me, is that he chooses to label service-orientation as coupling and cohesion as "information exchange."

I am sure that he has some actual advise to deliver, but I am lost in semantics.

I believe he is basically saying that sharing information imposes fewer constraints that expecting a service to exhibit a certain behavior, and so the coupling is looser. No arguments there. But really, did it need more than one sentence? And stating that the so-called "cohesive" (i.e. information exchange) systems are independent of each other seems a little generous.

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.

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.

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.

TexMex 1.3, WS-MetadataExchange, Spicy, getting Spicier

A new cut. I started collapsing some of the client code into TexMexClient, addressed the Dialect-specific GetMetadata where the service has no matching metadata, and corrected some xpath screw-ups. In particular, I wasn't looking for Dialect and Identifer attributes. Oops. Also, I wasn't getting the full cross-product of (soap 1.1, soap 1.2) X (ws-addressing 2004/03, ws-addressing 2004/08). Should be now, though.

Feeling better.