[Disclaimer: This post had a point. ChannelFactory vs. Proxy vs. Hand Rolled Proxy. That point got lost along the way.]

The “application” that I am working on is more of a platform then a single application. Our solution contains over 150 projects and is organized into what we call, sub-systems. A sub-system is basically a stand-alone application. sub-systems contain web, shared, service, configuration and testing projects. They can be deployed independently and are designed to be one piece in a larger SOA. These sub-systems are broken down into 5 categories of work. Web (MVC/Silverlight/API), Services, Data (Entities/NHibernate), Queuing, and Support.

For the last years worth of development, with the exception of the silverlight clients talking back to the web server via service reference generated proxy classes, we’ve been using a Service Factory/Locator pattern. Currently the development team is considering the merits of this implementation and possible alternatives.

Personally; I really like our current design, it follows the basic tenants of SOA and provides many benefits. The benefits out-weight the drawbacks and the drawbacks SHOULD be easy to overcome.

Cross Sub-System Communication

Every sub-system has a “shared” library project that houses it’s interfaces. This library is designed to hold only items that need to be shared between sub-systems. Service contracts, request and response messages and data contracts are typical items that should be in the “shared” library project in the sub-system.

When SS-A wants to call a service on SS-B, SS-A adds a project reference to the SS-B’s shared project. Next, SS-A uses our ServiceFactory class to locate and/or create the channel and service client. Now SS-A can work with SS-B’s methods as if they were local and without the need for a service reference or generated proxy class.

Screen-shot here.

We use this pattern because we have control of both the client and server code.

1. Separating the web and app tier.
2. No need to update ref/proxy when service changed.
3. Compile time checks.
4. Testable – Not that we are doing it.
5. Less code to maintain.

Problems With Current Implementation:

1. Can’t mock ServiceFactory – I shouldn’t say “can’t”, I just don’t think we’ve tried. Are tests are shit right now anyway.
2. The Shared project in every sub-system has become a dumping ground for implementations that don’t fit into our current project structure. For example, validators, extensions, repositories, and on and on are in these shared projects.

Shared Sub-System Bloat

At first this does not sound like a very big deal until you start to work with it. Every class added to the shared projects could potentially have a dependency on another sub-system. When this happens the entire platform starts to break down into a spider-web of dependency hell.

No really! This is the fucking problem! When I add a reference to a shared project I, by-proxy, add a reference to up to 40 other projects! The shared project in each sub-system should not have ANY references. It should only contain interfaces and/or contracts.

“The shared project in each sub-system should not have ANY references”

Serving & Consuming SOA

There are 2 main sub-systems that act as the services in our SOA. They reside on our application servers, have access to the database, don’t (shouldn’t) communicate with each other and provide a bulk of the business logic.

The consumers of these sub-systems include a web application, console applications, windows services, silverlight web hosts. These systems use the ServiceFactory class to communicate with the application servers.

F’ing up the program

The silverlight systems have another hop as they have to send the data down to the client. Our original design was to use RIA Services to emulate being on the server and hopefully write less code. However; since we moved to visual studio 2010 and couldn’t get .NET 4.0 on the servers our team decided to remove RIA.

Now we have a situation where the Silverlight clients need communicate back to their web servers. We used “Right Click-> Add Service Reference” to generate the proxy and a service locator to create the client.

Knee-Jerk Reactions

Our dev team, for some crazy reason, is suggesting that having a hand generated service proxy will be easier to mock then one generated via “Add Service Reference”. Also, they are adding “ServiceFactory” like code to the silverlight clients. I don’t know why we can’t use our current implementation by using linked classes in a silverlight class library and more importantly: How this is better in any way?

Proxy Class Fail

I feel that the champions for hand rolled proxies are looking at the problem idiosyncratically. The extra work required to keep the client and server code in sync (for both Silverlight and inside the platform) would FAR out weight the benefit of hand rolling proxies.

I just don’t think they realize the amount of use the ServiceFactory gets throughout the platform.

Testing WCF

I am far from a testing expert but I am pretty damn good at the googles.

1. http://mokosh.co.uk/post/2009/04/19/prism-2-wpf-and-silverlight-services/ – (we use prism)
2. http://houseofbilz.com/archives/2008/11/18/testing-wcf-service-apps-part-0-of-4/ – (we use RhinoMock)
3. http://stackoverflow.com/questions/2509316/best-way-to-mock-wcf-client-proxy – (client proxy)

Governance

SOA is a complex technology theory that can’t be bought. It requires buy-in from a team, developers and someone to watch over the implementation. Every developer thinks they understand SOA, when asked to implement it they create services and then complain that they don’t need SOA.

When I spent Christmas even developing across 4 layers just to get a fucking coupon onto a page. I bitched but I didn’t break the existing convention. I spent endless hours trying to understand how to fit MVC and SOA into the same project. During my development vietnam, SOA was a pain-in-the-ass, but now that we have a “stable” codebase and have 20/20 I can see how SOA will save our ass when the time comes. 

Coup d’état

A bunch of words go here. They aren’t important. Just know that when implementing SOA the development staff will constantly say things like “this would be so much easer if I could call the database”. SOA is not for developers; it’s for the project and the organization (much like TFS).

SOA is not for the developers; it’s for the project and the organization.

Concluding

I think that Silverlight clients should use “Add Service Reference” to generate proxies for a few reasons:

1. Right click “Update Service Reference” is much easier then keeping client and server code in sync.
2. We are in pretty rapid development.
3. We can mock the service.

Silverlight clients could, not for us, not now, use nant to keep the proxies up-to-date.

All service communication from the web to app tier should use the ServiceFactory pattern.

Console applications, windows services don’t use a consistent pattern. We need to resolve that.

Explicitly Covering My Ass

If any of my co-workers happen to read this: I wrote most of the code I’m suggesting needs to be fixed. It’s how I (we) spent my (our) holidays.

I’m just putting some thoughts down so I can understand the situation. I’ve rewrote this a few times when I grasped certain concepts/implementations/reactions/reasons/etc.

I think this sums it up. Now I need to get that one last question answered.

Why check in proxies for sub-systems that we have control over the client and server?

No related posts.

Quick tip:

If you want to put your custom controls in a separate assembly you need to include the layout (generic.xml) in that assembly.

Related posts:

1. Thoughts on Silverlight In a recent post Jamie Kosoy, who I believe is...
2. AutoMapper.Silverlight I could, and will soon, write a long ass post...
3. Silverlight, Actions and Prism When using Prism for composition in Silverlight how do...

I could, and will soon, write a long ass post about how I cobbled together a messed-up architecture for building Silverlight applications on top of an enterprise class SOA architecture without RIA but with RIA…

Here is a branch of AutoMapper, compiled against Silverlight and now with support for entities generated from WCF service references.

http://github.com/detroitpro/AutoMapper.Silverlight

I really hope I published it to GitHub correctly; yell at me if not.

No related posts.

In a recent post Jamie Kosoy, who I believe is a flash developer, posted his thoughts on his first Silverlight project. I’m also green to Silverlight and just finished my first project. I’ll save the post about my thoughts for another day; but I wanted to add my two cents regarding Jamie’s observations.

Timeline animation is different.

Flash uses a key frame based animation framework, Silverlights animation is based on time. Seems simple, and as someone coming from jQuery heavy development it was, but I can see how it would take a second too understand.

Silverlight is the better videoplayer solution

Adaptive streaming is amazing. The power to stream a single feed (HD) and have it chunked up into bit size bits for clients of all connection speeds to render with as much bandwidth/gpu power they have can’t be overstated.

XAPs aren’t fun to load…

Building even the simplest of applications without Prism, and soon MEF, is like coding with one hand. Yeah; you can do it but its hard, painful and frustrating. I hear parts of Prism are being pulled into SL4, I’ve voting for regions, modules, and events.

Classes can get really messy

C# is powerful; with great power comes great responsibility.

Building on OS X is critical.

I believe you can use MonoDevelop and Moonlight to develop silverlight applications on a mac. (Alpha)

Learning C# and Blend is empowering

C# Yes, Blend Yes, Declarative Programming in XAML – Big Fat No – Web ASP.NET Webforms. It causes more problems then it solves.

No related posts.

<Image Height="40" HorizontalAlignment="Right" VerticalAlignment="Bottom" Width="40" Source="/SilverlightDemo.MainToolbar;Component/Images/i_chart.png" Stretch="Fill" Canvas.Left="222" Canvas.Top="55">                <i:Interaction.Triggers>                        <i:EventTrigger EventName="MouseLeftButtonDown">                                <Actions:ToggleCollapseAction

                            TargetName="HERE:/SilverlightDemo.Modules.TargetModule;Views/TargetModuleView"                             CollapseHorizontal="False"                             CollapseVertical="False"/>                        </i:EventTrigger>                </i:Interaction.Triggers>            </Image>

No related posts.

After a day or so of working with Silverlight it became quite apparent that you can’t, no you Shouldn’t build Silverlight LOB (Line of Business) applications without Prism.

Prism offers a way to break down your application into modules. And it uses Regions as a way to put it all back together again. Its very similar to the ASP.NET MasterPage/Content area approach.

Unfortunately for me; the control toolkit I’m using (I work for GISi now; its a mapping company…more on that in a future post) is from ESRI but none of the ESRI samples use Prism. When I got down to the nitty gritty I ended up tearing out my hair over my inability to make the map control do two things.

1. Live in a module (a module is a separate project)
2. Take up 100% of the height and width of the shell. – Its a prism term – long post and screencasts coming soon.

I could make the map do 1 or 2 but not 1 and 2…that is until I got some help from @sharpgis

http://forums.esri.com/Thread.asp?c=158&f=2455&t=290394&mc=4

So, the key is to use

 HorizontalContentAlignment="Stretch" VerticalContentAlignment="Stretch"

No related posts.