Never ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever ever write service contracts and implementations inline.

With the PDC bits for WCF, using the Indigo Service template is like opening a box of chocolates...you never know what you'll get...IService, IMyService, IIndigoService...but that's just Beta stuff...

For Web sites the template generates the .svc endpoint and service implementation, for other project types it generates only the service implementation. Normally the service implementation would be in a .cs or .vb file (pick your language)...and this is true in all cases but one: adding a new Indigo Service to an existing Web site project in Visual Studio.

This template is evil...it creates inline code like this, with all the implementation in the target IIS endpoint file:

<%@ Service Language="C#" Class="IndigoService" %>

using System;
using System.ServiceModel;

[ServiceContract()]
public interface IIndigoService
{
    [OperationContract]
    string MyOperation1(string myValue);
}

public class IndigoService : IIndigoService
{
    public string MyOperation1(string myValue)
    {
        return "Hello: " + myValue;
    }
}

Now if I want to host this service outside of this Web site application I'll have to copy the service code into another file somewhere, or migrate this code to use a class library and share it. Why would I not just create the service in the class file from the beginning?

This may change before release...but just in case bookmark this post ...

Getting back to my earlier brain dump on the many ways you can create WCF services today...I have uploaded two samples:

The first sample is a solution with three projects: service, host and client. The service is a class library with a HelloIndigo.Service implementation, the host is a console application that initializes the ServiceHost for the service (self-host over HTTP), and the client consumes the service. ServiceFromScratchConfig.zip (54.5 KB)

THe second sample is a solution with two projects: a Web site created from the Indigo Service template, and a client to consume the service. The Web site acts as the host for the service (through IIS) but actually references the HelloIndigo.Service from the previous example. IISHostedService.zip (22.11 KB)

Same service, two hosts with possibly different bindings, behaviors, instancing.

If you always designer your services to be “moveable“ you will have an agile service-oriented system on your hands. The service contract and implementation (as expected) does not change, that should be appropriately versioned once it has been published. Oh, and guess what? Since the service is contained in a separate class library (assembly) it can be versioned appropriately with CLR versioning as well as contract versioning semantics.

So I have now explained why you should never use the Indigo Template “as is” when you build Web site, console, class library, or other applications that contain or host services. Sorry...templates are for kids...

I had several conversations this weekend with Steve Swartz (one of my favorite people, not just because he's smart, but he's a really cool guy too!) about best practices in various aspects of the service model. I'll eventually get a chance to blurt all of my thoughts on this (and confirmations a-la Steve) but let's start with the subject: base address and endpoints...how “should” it work?

Consider this example that creates a new self-hosted service with a base address and endpoint Uri as shown here hard-coded:

Uri baseAddress = new Uri("http://localhost:8000/HelloIndigo");
using (ServiceHost host = new ServiceHost(typeof(HelloIndigo.Service), baseAddress))
{

host.AddEndpoint(typeof(HelloIndigo.IService), new BasicHttpBinding(), new Uri("http://localhost:8000/HelloIndigo/Service"));

host.Open();
Console.ReadLine();
host.Close();
}

Seems harmless, and it will work. Clients will bind against the target Uri of the endpoint:

http://localhost:8000/HelloIndigo/Service

But the truth of the matter is that the base address should be relied on as the...well as the base address for all endpoints that share the same protocol, port, etc. In the above example that would suggest that when I add an endpoint to the service host, I should only submit “Service“ as a string (something you can do with one of the overloaded methods for AddEndpoint):

host.AddEndpoint(typeof(HelloIndigo.IService), new BasicHttpBinding(), "Service");

The same goes for declarative configuration for the service host, no need to specify the complete Uri, it will be inferred from the base address:

<service type="HelloIndigo.Service" >
  <endpoint address="Service" contract="HelloIndigo.IService, HelloIndigo" binding="basicHttpBinding" />
</service>

This makes your services more configurable, modify the base address and relative Uri will follow suit.

I thought I'd share this observation in the interest of coding practices for the WCF. For client applications invoking services, you'll see lots of samples already out there that use the following syntax:

ChannelFactory<IService> factory = new ChannelFactory<IService>("");
IService proxy = factory.CreateChannel();

string s = proxy.HelloIndigo();

If you weren't at the PDC, you can still get the latest WinFX bits, with the latest drop of WCF and WPF:

http://www.microsoft.com/downloads/details.aspx?familyid=ffd636f0-86e9-41e8-9e1c-100a4cc4888f&displaylang=en

Of course you need MSDN subscription to install the latest Visual Studio 2005 bits on top...but the RC1 candidate is available up there, so I recommend you use that...apparently it only runs with Beta 2, so you can't work with the latest and greatest 2005 bits today and get WinFX running.

Do this if you want to be able to run any code samples I post on Indigo...er...WCF WCF WCF WCF...

ADDING MORE INSTRUCTIONS

I found a great blog post explaining all the steps for PDC DVDs or downloaded bits here: http://www.longhornblogs.com/rrelyea/archive/2005/09/16/PDC2005Software.aspx

These are the download instructions from Rob Relyea's blog:

1. Operating System Required - Windows XP SP2 or Windows Vista 5219 (not Windows Vista beta1!)

2. WinFx CTP installation
This installs WinFX on the machine...end users will need this done.
WPF (fka "Avalon"), WCF (fka "Indigo"), and .NET Framework 2.0 all get installed with an integrated setup.

3. Visual Studio (Beta 2!!!)  (or you can also install Visual Basic Express  or VC# Express - just make sure it is "Beta 2"!)  Sorry, there is currently no build of WinFX that is compatible with RC or RTM builds of VS!
Once the install is done, make sure you do step 2 of the VS setup...install Help content - use it offline if you want it to work its best with WinFX SDK content to come later.

4. Windows WinFX SDK
This installs a ton of help content (samples, documentation) and some great tools (xamlpad, etc...)

5. VS Extensions for WinFx
This installs Project Templates and Item Templates for Visual Studio.

Sometimes it is really helpful to have different ways to build things...like WCF services for example...I can approach it from many different starting points. If I know I am going to host my services as part of a Web site/application...I might start from a different path than if I was building a truly service-oriented application that may or may not be always exposing services over HTTP and/or through IIS.

So you can do any of the following to create a service:

 a)       Create a new Web site project using the Indigo Service template and selecting HTTP (creates an IIS virtual directory for you, that's great!)

b)       Create a new Web site project using the Indigo Service template and selecting File System (this creates a file-based Web site, no IIS virtual directory, hosted with Cassini Web server)

c)       Create a new Class Library project then add an Indigo Service template item to it (no virtual directory is created for you, and no .svc endpoint is created...because the idea here would be to host this service “wherever you like“)

d) Create a new Console Application project then add an Indigo Service template item to it (no virtual directory or .svc but you can add self-hosting code to this application, coupling the host and service in one)

Some observations:

Option a) is useful for testing IIS services because it quickly generates a project that and creates the appropriate IIS virtual directory.

Option b) is problematic for a few reasons. First because in general, Cassini testing does not yield the same results as IIS-hosted testing when we’re talking about anonymous vs. authenticated access. Second because it requires NTLM authentication by default, requiring extra steps to enable access to your services on the development machine (I'll make a separate post on this)…possibly settings that will leak into deployment configs for QA and production if not caught. Whenever possible I think we should develop in the environment we will deploy in.

Both a) and b) have another drawback, that the service interface now gets lumped into the deployment of the ASP.NET Web site (the project it belongs to). That means either deploying source (hopefully no one will really deploy source in ASP.NET 2.0...just because you can) or precompiling the site (so now the code for the service is lumped into the ASP.NET application DLLs and it must now be versioned with those DLLS). This tightly couples the service (which should be an agile component of a system) to the ASP.NET application it is exposed through. I recommend there NOT be a template for creating indigo services with Web sites for this reason…because it moves you away from a pure service-oriented design.

Option c) is best because it implies that the service interface is part of a component that can be distributed and used by either an ASP.NET site, or a self-hosting environment, but coupled to neither.

Option d) couples the service to the host, nice for demos, not practical in deployment.

Of course, we always want tools for testing, that will make us quickly productive, and for that reason I say perhaps we are missing a few things. If we can have templates for services exposed as part of Web sites ( a) and b) ), we should also have template for creating self-hosted console services ( d) ), or IIS hosted class libraries ( c) with a twist ). The last item there is what we are missing perhaps, just in productivity terms:

e) Create a new Class Library then add the template item for IIS Hosted Indigo Service. This would create the IIS vdir and give us the darned .svc file for our class library, maybe even set the Build directory to \bin instead of \bin\debug or \bin\release so it will work without editing that.

Of course e) goes against my initial argument -> to force developers to build services in a service-oriented and decoupled manner...which would mean get rid of all but c) and watch people scream. I think what we'll need instead is a) through d) (plus e) if I get my wish) and we'll need to educate people why real services should be designed with c) because you know that a million and one code samples are already flying out to the Web that don't do c).

I'll post some samples separately, I wanted to get my rant out first. That feels better.

A long time ago Benjamin Mitchell told me about this tip...and I recently shared it with a few others...so I thought I'd post it for the entire world that reads my blog...

If you turn on word wrap (Tools->Options->Text Editor->All Languages, select Word Wrap and show glyphs), you shouldn't have to say things like this during your code presentations:

As you can see here...oh...wait...let me just scroll over a bit so you can see the rest of this statement...there...oh...wait...just a little further...there...ok, just a liiiiittle further...ok, can you remember all that? Good.

Keving Boyle, one of my local Microsoft Architect Evangelists makes an interesting observation here...

http://blogs.msdn.com/socalarchitect/archive/2005/09/23/473399.aspx?CommentPosted=true#commentmessage

and I'm not surprised because I still hear from a lot of companies that need to get started with Web Services 101. SOA just sounds like this big huge ominous endeavor if you listen to all the buzz out there...yet it should be very simple in my opinion.

OOP to classes is like components to applications is like services to systems

The question is of when an “application“ becomes a system, and that is a question of composition, complexity and distribution.

Notice you did not see the term “web services“ above. Web services are NOT a requirement of SOA, there are an interoperability facilitator.

Enterprise systems should be designed so that major chunks of functionality can be moved, distributed, refactored, replaced with alternate application or vendor sources...without tumbling down the entire system. Today's system is no longer a single monolithic endeavor by a single vendor. We are now in the business of building composite systems that comprise many applications or feature sets that are respectively built by appropriate domain experts. So, systems must be sure that major sources of functionality are not tightly coupled. Major features become “services“. Each “service“ can receive inputs, or return outputs...and everything that happens in the middle should be completely independent of the rest of the application (black box). That means I should be able to move the service to another machine, another vendor and still have things work just fine so long as the location can be found. So, a service is designed to use its own tables, configure its own file IO directories, and manage all other resources needed to perform its function. That does not mean there is a different database for every service in an application. It just means that the service is programmed not to depend on another services table structure. Use the same database, use a different database, it should not matter to the application as a whole because the service maintains its own configuration.

Consider this progression.

An application that logs incoming Web service requests, records a transaction, and shoots off a request to generate a PDF from the XML.

The functionality that logs messages doesn't have to be on the same tier, and the application may leverage another application to do the work...therefore that is a service (logically speaking):

The transaction logging activity is a core part of the application, but could later be distributed therefore that can be considered a logical service as well. In particular the PDF generating functionality could receive XML inputs, and be considered a separate service as well:

But, let's not think small. This entire system could be considered a service to another application that requires PDF generating and transaction reporting activities. In this example, the system is a certificate issuance system (from a system I designed for the insurance industry years ago) - so that would be the purpose of this interoperable service endpoint:

SOA is an approach to system design that has been implemented in systems of many differing technologies in the past, that makes a business more agile. New technologies are making SOA easier to implement, Web services make SOA interoperable, but it is really about designing enterprise systems so that there is an appropriate level of configurability and reuse at the outer "service" or "functionality" layer.

Indigo (WCF) will just make the implementation of services a natural part of system development.

What do you think? Is SOA too confusing?

Microsoft is sponsoring a brand new architecture podcast series, the first one which I participated in with Chris Haddad, Roger Sessions, Jeff Schlimmer and Dare Obasanjo. The subject is of the future of WS* and interoperability. Want to know what we all collectively think on the subject, check it out here:

http://www.microsoft.com/architecture/default.aspx?pid=share.podcast&abver=FEEB2E89-4412-4C58-A7F8-9B2CA0E0BDAC

We put on a 1 day seminar at UCSD Extension on Saturday for those interested in getting up to speed on the upcoming release of .NET 2.0. I'm posting a bunch of 2.0 samples here directly related to the topics we covered at the event.

Dave McCarter gave a great overview of the VS 2005 IDE and its productivity features. No code to share on that one, you have to be there to see it!

I presented a talk on VB.NET and C# language enhancements. Samples include a few new VB.NET samples:

• EventAccessors in VB.NET
• BackgroundWorker in VB.NET

Several C# samples that are posted on the IDesign site:

• http://www.idesign.net/idesign/uploads/GenericsPerfs.zip
• http://www.idesign.net/idesign/uploads/Arrays.zip
• http://www.idesign.net/idesign/uploads/GenericLinkedList.zip
• http://www.idesign.net/idesign/uploads/Iterators.zip

I also presented a talk on ClickOnce and Smart Clients...the code sample is better seen in “live demo“ but here's the finished product of what I demonstrated:

• ClickOnceDemo

And to wrap things up, Scott Mitchell gave a great talk on ASP.NET 2.0...he did most of his demos live, but I told him I'd post some of my finished ASP.NET 2.0 samples here that were related to his talk...since I have them handy:

aspnet20samples.zip 

For more IDesign samples go here:

http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=5&tabid=8

Enjoy!

This blog looks very very boring...for now...but I can assure you I have a lot more personality inside...and it shows in my other endeavors more obviously such as Stuntmusician.

My point?

Well, some of you may know my brother is in a rock band, and I'm very proud of he, his band, and their music...so if you like hard core rock, they just pressed their second CD on a shoestring budget, the usual artists wage...recorded lead vocals (my brother, Paul) in 3 hours, no kidding!!! I happen to think they rock...

http://www.evildoersmusic.net

My second point?

In my “other“ world I'm trying to bring technology to the independent music scene, which I'm a great fan of...for obvious reasons (my brother)...so...I have been interviewing indie rock bands since January (well, sort of, we had a little break as I moved from Mondays to Stuntmusician)...and I just posted my latest interview with Killola, a rock band in LA - diverse, a bit racy for some, and yes there are some profanity so you might want to stay clear if you are the conservative type...this won't be for you...

Check out their interview here: http://www.stuntmusician.net

I have a lot of plans for this site...well...after I get the Indigo book finished...for now enjoy monthly indie rock interviews and some reviews that will get up there very soon...

and I will now return to slaving over the book...

For all you dasBloggers out there...if you want to have nested blogs like I have here:

www.ucsdxcommunity.com

www.ucsdxcommunity.com/ASPNET

...you have to first configure the subdirectory as an IIS application, then remove the <httpModules> section of the web.config in the nested blog. Modules can only be loaded 1x per appdomain, and the nested blog is loaded into the same appdomain by default.

The funny thing is, the error message tells you that it can't load the module twice, so this is actually pretty obvious, but if you are like me, you may have seen this error and started looking for a “bigger“ problem (I always do that...dunno why) ...therefore I didn't pay attention to the error message 'literally“ at first.