January, 2008

Hello world web programming model

Signed up for the Remember the milk service just to try and get a feel for their REST api’s, which are modelled just like Flickr’s API’s. What better method to call on a service than the quintessential “Hello World“. Turns out its very straight forward with the new Web Programming Model in .net 3.5 WCF

    [ServiceContract]
    interface IRTMEchoService
    {
        [OperationContract]
        [WebGet(UriTemplate = “services/rest/?method=rtm.test.echo&api_key={apiKey}”, BodyStyle = WebMessageBodyStyle.Bare)]
        XElement Echo(string apiKey);
    }

All we did there was to create an interface to mimic the REST api defined for the echo method

    public class TestRTMEcho
    {
        private string ApiKey = “xxxxxxxxxxxxxxxxxx”;
        [Test]
        public void TestRtmEcho()
        {
            using (WebChannelFactory<IRTMEchoService> factory = new WebChannelFactory<IRTMEchoService>())
            {                
                factory.Endpoint.Binding = new WebHttpBinding();
                factory.Endpoint.Address = new EndpointAddress(new Uri(“http://api.rememberthemilk.com/”));
                factory.Endpoint.Behaviors.Add(new WebHttpBehavior());
                IRTMEchoService task = factory.CreateChannel();
                Console.WriteLine(task.Echo(ApiKey));               
            }
              
        }
    }

Wrote a small test that creates a WebChannelFactory and loads it with the default WebHttpBinding and WebHttpBehaviour point it to our endpoint and voila! the output as expected!

<rsp stat=”ok”>
  <api_key>xxxxxxxxxxxxxxxxxxxxx</api_key>
  <method>rtm.test.echo</method>
</rsp>

Notice the use of the UriTemplate property in the WebGet attribute in the IRTMEchoService interface.

Betamax in an SOW(orld)

I posted about how WS-* “stacks” up against REST in my link posts. Just had an opportunity to comment on it. I really like the arguments presented in favor of “not dumping” WS-*, eloquent even I might add, but none to say why WS-* trumps over REST. WS-* does stack up quite well compared to REST. Theoretically WS-* is certainly got its strenghts in the enterprise especially large enterprises where REST doesnt have too many formal stories surrounding orchestration, service registries, BAM etc. One could argue that such requirements may not matter, but it would be hard to convince the business otherwise.

On the other side of the argument, which I think is really the key, that REST has going for it is… Adoption! What Steve Vinoski terms “Serendipitous reuse“. Developing RESTful applications is agile and allows for iterative development; to a large extent interactive even. It presents a low barrier of entry in terms of skills, courtesy uniform interfaces; and the killer feature of it all “freeing the data” from the shackles of specialized interfaces (more on that in another post)! Somehow I get the feeling WS-* might become the betamax of the SOA world!

Weekly crumbs #4

Vittorio Bertocci and Caleb Baker: Understanding CardSpace and the Complexities of Identity
Introduction to MTOM: A Hands-on Approach
Software + Services in the Microsoft World
WCF Latency Test Harness and WCF Performance
Next-Generation Grid Enabled SOA
Hypermedia in RESTful applications

LINQ to SQL first impressions

While creating a windows application using LINQ the first thing that struck me was, yes, this is cool and it makes it looks so easy. This is great for a client-server application! After the initial eye-candy-effect faded I was stuck with a very fundamental question; what is the typical lifetime of the DataContext derived object? Are there any best practices around it? After a little bit of googling heres what I found in the LINQ Project General forum

…As you may notice, DataContext pins entity objects. hiding them from GC. That means, once object was retrieved using DataContext, it’ll be in cache until DataContext is alive. Doesn’t this mean that DataContext has to be short-lived object? Any guidelines/examples of proper using of DataContext would be really appreciated.

And the moderator’s reply

2) Yes, the DataContext should not be long-lived for a server app. You should create one to cover the duration of a transaction. For client code this is less critical.

Which leads me to think that it is not very easy to scale the application with this approach when you apply SOA and split the application into n-tiers; handy as it may be for a connection oriented applications (read: windows application), over HTTP, a protocol thats inherently disconnected, the LINQ-to-SQL model degenerates into a nifty way to query the database without using a third party ORM/ORM-like solution.

Digging further I found a couple of articles that allow you to work around this limitation either by allowing you to “Detach” and “Re-Attach” entities or working around it when they cross tier boundaries. All of these solutions mean that the DataContext has to stay around in memory to track changes and if objects created by it. If the objects are “pinned”, as the forum post suggests, this would mean web applications/services that have session affinity with a potentially large memory footprint which may not really allow the application scale!

I havent looked at what Entity framework has to offer yet, but LINQ to SQL seems very Dataset-like! Disappointing!

Service interface documentation

I’ve always wondered how the REST camp could get away from documenting the services in a machine readable form or otherwise. As it turns out there’s standards there too… but this post by Ryan Tomayko really sums it up; quite hilariously too!

“Serendipitous” Readings

Happened to read an interesting article by Steve Vinoski. After graduating from the school of SOAP I’ve always wondered what was so special about REST that gets the Restafarians so excited but never bother to ask ;-). The article had me looking for examples that validated the benefits of uniform interfaces. (Disclaimer : I’ve always been a WS-* fanboy and haven’t read a word of Fielding dissertation until this week)

To be honest I wasn’t really convinced reading the article that REST was going to solve all of the worlds problems, though I agree with much of whats opined. My sentiments being echoed on this post by Nick Malik

Don’t get me wrong. I love REST. Integration based on REST gives you a great way to share some basic operations and minimize coupling on the operation, but coupling exists in data as well. Decoupling on the operation is step 1, but without similar decoupling in the data, is a partial answer.

However I don’t agree with Nick when he says

Honestly, a messaging protocol doesn’t provide for reuse, serendipitous or not. A data model does. That is the far greater problem.

The reason being data is always going to be the variant and different systems need common data models or at least operate on the same semantics to be useful to each other. But what REST gives you is, once you “agree” on the data (more on that in another post), a fundamentally simple and useful way to pipeline your data across your enterprise systems. Giving pieces of the enterprise a consistent way to participate in “mash-up” of the data that normally would require considerable effort. In the article Steve’s comments on control particularly hit home this point.

Enterprise architecture is primarily about control. Architects put rules in place hoping to achieve application consistency across the enterprise, increase the chances for reuse, and cut costs. Unfortunately, as I’ve mentioned, allowing the proliferation of ad hoc interfaces creates a losing battle for the architect trying to gain buy-in for such rules. Many such architects are SOA enthusiasts who intentionally ignore REST and its elements, constraints, properties, and relationships. Ironically, if applied properly, REST could yield the very consistency and reuse they seek.

I finally do get why REST style can really be useful many thanks to Steve’s comment on this post:

Consider the UNIX shell pipeline. It allows independently-developed tools conforming to its semantics to be chained together serendipitously to create new tools. This reuse is based entirely on the uniform stdin/stdout bytestream interface. Different data formats can pass through the pipeline, depending on the tools involved and the command-line options given to them. The tools, of course, have to understand the data formats they exchange. But best of all, the same power applies to more than just the shell; any UNIX app can open its own pipes and chain together whatever tools it wants to.

I still haven’t got my head around when a RESTful style is more appropriate over a SOAP style of SOA and vice versa, but I do believe that there is a certain class of applications, when built RESTfully, could provide very interesting network effects and value within an enterprise. Many thanks to the debaters for a week that has been full of “serendipitous“, informative and fun reading

Biztalk Identity Services…

In trying to get my head around Biztalk identity services I’ve been going through the examples for the identity services provided by BizTalk and from the Biztalk Labs, the concept of identity services makes perfect sense. However, and it might very well be my ignorance (read disclaimer :-)), I’m not sure how the current incarnation of the services provides value other than security claims evaluation for authorization.

From The “BizTalk Services Identity Provider” page

How can an application take advantage of Identity Services in the BizTalk Services offering?
If you run a Web site or Web service, you can enable it to accept identity tokens provided by the Security Token Service. To do this, you must create a digital identity at this site on behalf of your site or service, and then you must configure your site or service to accept the appropriate identity tokens.

While it can make sense in a web service interaction scenario (I havent dug deep enough yet) using Saml tokens with claims assertions issued by the Biztalk Services STS(?). How does it translate to a web applications attempting to use Biztalk Services as an identity service provider.

In the authentication/authorization of a web application scenario, when a user logs in there is no way to get at the claimset associated with a user. Ideally, I would think this would come from the information card (issued by a trusted managed card provider) or in the token generated by identity services after a successful login. In essence how does one go about using BTS as an identity provider? Is it meant to be used that way in the first place?

The examples that come with the SDK seem to suggest it possible!

Just discovered…

New in Visual Studio 2008 there is a neat little tool tucked away in the “C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE” directory a neat little tool called WcfTestClient

Point it to the mex endpoint or the metadata for e.g.

WcfTestClient http://localhost:1345/Service1.svc?wsdl

Also included is a tool (WcfSvcHost.exe) that can generically host WCF service, albeit not as sophisticated as IIS or a custom host. There is a host of other framework and IDE enhancements but I think these are just so handy! very cool for quickly testing services!

Weekly Crumbs #3

Jim Webber on “Guerilla SOA” - late to notice this one
Distributed Architecture on ARCast.TV Rapid Response
.NET Framework Library Source Code now available - no WCF sources yet unfortunately
Myth: RESTful Web Services Don’t Need an Interface Definition Language
WCF Web Programming Model Documentation
Custom UserNamePassword Validators in .Net Framework 3.5 - (via Dr. Nicholas Allen)

Weekly crumbs…

• What’s In a WCF Binding, And What Can My Service Do Right Now?
• How to become a real Guru: The Microsoft Certified Architect Program
• New in VS.net 2008 for WCF
• The Authorization Continuum
• Modify Message Content With WCF