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.

For example, creating a new example with the UsernameToken security token, based on the OASIS WS-Security standard, requires some minor adjustments to your web.config settings. Previously, when you configure a custom security token manager to handle <wsse:UsernameToken>, you would add the following <securityTokenManager> element:

Of course the namespace and qualified name of the OASIS WSS UsernameToken profile haven't changed, but the way ASP.NET 2.0 handles application assemblies has, along with the WSE 3.0 configuration schema.

First point: ASP.NET no longer has a single application assembly (DLL) for the application code. You can't count on a specifically named assembly like MyWSE30Service.DLL to be deployed to the \bin directory. In fact several assemblies are generated from the Web site source, and the assembly names are dynamically generated. So, you can't specify the name of the assembly in the type attribute of the <securityTokenManager> element, the custom token manager type is compiled with the ASP.NET application code. In this case the type attribute should only include the fully qualified type name with its full namespace.  And, you'll be glad to know that when you sign the Web site application output assemblies, the setting remains the same.

For types that are compiled into a separate assembly, then referenced, the traditional format for the type attribute would be used. The fuly qualified namespace and assembly name are provided for unsigned assemblies. For signed assemblies provide the full assembly name which includes version, culture, and public key token.

Second point: there is a new namespace attribute, and qname has changed to localname...and they aren't the same thing. Qname refers to a fully qualified XML name which means namespace and local name. Now, the QName property of the SecurityTokenManager at runtime can be generated from the namespace and localname in configuration.

Third point: with WSE 3.0 you can configure more than one token manager for each type of security token manager (binary or XML). THis changes the configuration schema for <securityTokenManager> which now supports the traditional pattern of add, remove, clear - as discussed in the WSE 3.0 specification:

<securityTokenManager>
<add localName namespace type />
<remove localName namespace />
<clear />
</securityTokenManager >

And so now your custom UsernameTokenManager should be configured like this:

Of course, you could just read through the WSE 3.0 documentation to find these things out...but I betcha browsed the Web first, so here ya go...