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.

catch:
To put that another way, if you use the WebGet annotation it’s assumed the calling party is going to use rest.

finally:
if you use the WebGet annotation on your WCF operations they can be called as soap operations

No related posts.

Ha! Dimecasts.net is my phonebook!

Ha!

No related posts.