ARCast.TV - Every Class a WCF Service with Juval Lowy

Hey, after watching the CCR video, and the Robotic Studio video, I was convinced that every class SHOULD be a service, now you're telling me it shouldn't?



P.S. I think this was a great video.... and should've been featured on the front page.

Great vid guys.  Actually I have to agree with Juval here.  It makes a lot of sense.  Not sure at the moment what a service for "int" would provide, but I can totally buy into making all/most of your classes services.  If we take that thinking a small step farther, we can see that the goodness of strong typing and assemblies is actually hurting us on this path, because my types are not as loosely coupled as they should be and it is still hard to share types because you have to share assemblies and compiled code.

However, what if we kinda toss out the normal packaging of types and assemblies and think more in terms of meta-data types and a root registration system (ala DNS like).  Start from a root System (e.g. App Designer System diagrams).  The base System may be composed of many other applications and/or components.  However, it is still one system and "owns" all the types as metadata in a very loose way with no assemblies.  I can then have 1 MyType in this system and all other subsystems use it.  It is read either at compile time or dynamically from the root meta-data and JITed.  So no everyone "in-the-system" uses same type, but not bound by assemblies as such.  So now, you are free to pick and choose types and Refactor these type objects to run on local process or across-process on different systems.  This would also allow real-time moving of these services to other systems as load and fail-over dictate.  For example:

public service MyType
{
      public string Name {get; set;}
}

The MyType service has a namespace off the root, but is *not tied to any one assembly.  It is writen as c# (in this case), but will live in the type system registror(s) as plain-old string meta-data in some xml format.  When two systems need to share data using MyType or access it via endpoints, they can ref MyType from the Root and it gets compiled (or the proxy to the service) into there local app.  So we would not reference assemblies, but just use "Using" statements because the IDE would have the connection to root already set in a Solution property so it can read-in Type info for Intellisense, etc.  MyType can now live on any system, in any assembly and can move around to other hosts inside the root system of hosts.  You could also locally extend MyType using Parcial Service like parcial classes today. The root system can also keep track of service instance locations (ala DNS style registrations and lookups) within the system and provide policy for such.  Services could also log errors, messages, and perf stats automatically back up to root.  Root management tools would allow you to see the whole system of services and messages running real-time.

Ron, just found this podcast, and the issues brought up are still spot on today. Juval is an excellent spokesperson for WCF. He definitely hit all of the highlights I feel are worth mentioning about WCF. His statement that WCF is like learning another development platform resonated with me. I saw this as a problem, and was inspired to develop a solution for those that sought the benefits of WCF but without the learning curve. There are many businesses out there that need to implement the type of functionality that WCF offers, but not all of them have the expertise and resources to learn and utilize WCF. BizTalk Services (Internet Service Bus) exists, but one still needs to learn WCF. I look forward to more of your podcasts. I'm going to browse through your archives and get caught-up.

I wonder if having a wcf service for "int" helps us solve that other problem on the horizon, moore's law? It's all very well having 90 cores to play with, but if we haven't got tools to use them effectively  we're still stuck in single thread land. With all the overhead of wcf, that could be very painful indeed.

I agree with jmilgram though - I must go and hunt out other broadcasts by juval!

Bingo!! Stacyw
Lets face it, follow the trend out......
You are either writing C++ unmanaged code for efficiency, proprietary control, etc. or abstraction and loose coupling make sense, even at what may seem like a high price today.

Where has the video gone to?