I may be at Strategic Architect Forum, but I’ve actually been coding off and on today - using WSE2 to expose web services. I hadn’t realized that SoapService supports auto generation of WSDL – pretty cool. I dug around with Reflector to figure out how it works. Turns out that SoapReceiver (parent of SoapService) exposes a method called GetDescription that returns the WSDL as an XmlDocument. The SoapReceiver version of GetDescription returns null, but the SoapService implementation uses an internal class called WsdlCreator to generate construct a ServiceDescription from SoapService type that you write. Pretty cool.

The only downside is that if you use raw SoapEnvelopes as the input and output parameter of the SoapService methods, the WsdlCreator has no way to know what schema to use for the corrisponding SOAP messages. So, it punts and represents a SoapEnvelope as sequence of xsd:any tags. 😦 If you use XML serializable types for parameters, then the WsdlCreator generates the associated schema in the WSDL. Only issue, I gave up on XML serialization a while ago.

I wish there was a way to adorn the SoapService methods with an attribute indicating the associated message schemas (with the ability to validate those messages automatically).

I like Jeff’s suggestions for a Service Oriented Lanugage as well as RebelGeekz’ idea of how to include XML Infoset information in a language without resorting to angle brackets. I wonder what a community developed lanugauge would look like? I’ve experimented with Coco/R which really reduces the effort it takes to build a parser. Of course, the language design and code generation are the hard parts!

Source for Coco/R is available on the Rotor Community Projects page. Other cool projects include a port of Rotor to WinCE, two different AOP projects – one for C# and the other language neutral and a set of improved collections.

Don pointed out to Goran that the Indigo definition of “a service is simply a program that one interacts with via message exchanges.” Goran pointed out that that definition “really doesn’t highlight how it’ll help a customer”. I think part of the reason they are both right is that they are talking about different things. I would say Don is talking about Service Oriented Programming where Goran is talking about Service Oriented Architecture. This gets back to the levels of architecture that I blogged about. Platform tools like Indigo are components used in systems. I’m guessing the customer’s Goran mentioned are at the system-of-system level for whom the messaging plumbing is below the abstraction level they care about. 

Of course, SO* buzzwords are thrown about with such frequency these days it’s hard to keep track of the difference.