Indigo

We had a mid-month North Dallas .NET User Group meeting tonight. David Chappell came and talked to us about Indigo, Microsoft's next framework for distributed computing, combining their web services, remoting, and enterprise services stuff into one big framework, all built on top of .net 2.0, itself to be released later this year. Thoughts:

1. Microsoft sometimes comes out with super cool stuff. This looks like this will be one of those things. And I can't wait till .net 2.0 comes out this Fall either...
2. I am reminded what a great industry the software industry is to work in. With such interesting technology, who wouldn't want to do this?
3. I like free pizza, and they give us some at the meetings.
4. We had drawings and I was only two numbers off from getting a copy of Visual Studio. Of course, I already have one. But it never hurts to have extras.

Service Oriented Architecture. I really think there is something to that in a lot of situations. And that, basically, was what the talk was about, at least implementing it in Indigo.

Now the only truly thought-shifting thing that happened during the meeting happened when we talked about the idea of separating the service interface from the class hierarchy that will undergird it. He showed a code sample, with a private method in a class that was meant to be invoked during the service call. Of course, at first this just seemed backwards. Private methods are meant to be called outside of the class at all, yet here we are exposing them over web services.

Then he explained it. And it really clicked and made sense to me. In the object-oriented world, the idea of having a private method callable in such a way is truly abhorrent, and that is accurate. It is. But this is different. We're talking about the creation of the external service interface.

So here is the rational. If you make the web service methods private yet accessible via webservices, you have a way of enforcing within your class a way to keep the business logic from calling that web service method. The service method exists to be called from the outside, not generally from the inside. That's why you attach the service attribute and make it callable from the outside, but make it private and not callable outside the class within the code.

Here's an example. Let's say you have an application for getting book information. The data is stored in some RDMS. At least in my applications, book objects that are created to represent the book entities in the db will usually be identified by some primary key id, usually an identity/auto-incremented column. That's what is its main identifier. So if you have a class that is called "BookManager" that has a GetBook() method, chances are you'll have something like this:

public Book GetBook( int bookID )
{
//foo;
}

But, if you want something callable over a webservice, that won't work. They don't know what's in your db, much less your primary key id's. You might make a method for them that looks like this:

public Book GetBook( string isbn )
{
//foo2;
}

Assuming you aren't going to use the second method within your library, you can mark that method private and give it the service attribute:

[OperationContract]
private Book GetBook( string isbn )
{
//foo3;
}

With this you keep a method from being called from within the library that is not meant to be called, but at the same time expose it to the world. I like the idea.

Great meeting!