By post 6 we managed to construct an operational service application with a minimum of code that could actually do something useful. However, its worth noting that it has some big drawbacks compared to a more professional rendition of the same. The following is a short list (the list is actually much longer) of items we will refactor for the purpose of raising our application to an acceptable level of engineering.
1. Service application clients should not bind directly to any instance of a service application. Why? Because multiple instances of a service application can exist within the farm and each one may have a different set of user managed configurations. Also, a single application instance will be running on a specific farm server thus defeating SharePoint’s built-in load balancing. Finally, given the last two points its now very clear that the following code (from the last post) only assumes the First known instance is the one we need DemoServiceApplication app = service.Applications.Cast<DemoServiceApplication>().First(); Not good.
2. We also must be able to configure what “proxy group” the service application belongs to relative to an existing SharePoint web application. This is one of the major strengths of service applications. That is, the ability to group services anyway you wish and have them applied to specific web applications. This is also a great idea for multitenant hosting scenarios.
PS: Don’t confuse a programmatic proxy (as in SOAP or WCF) with the proxy I’m discussing here. The above image shows a proxy group which is a purely “logical” grouping that really just borrows the word “proxy” as a descriptive name only – this is an administrative configuration and one of the principle advancements in Service Applications.
3. The code presented so far only assumes a single instance of the service application (maybe, but its actually worse) will be available on a single server – remember that SPServiceInstance provides you the On/Off ability on a per-server basis (see the next image)
In our current solution this is represented by the DemoServiceInstance class located in the SPServiceInstance.cs file
Instance Bait and Switch
Let’s begin with the last point concerning DemoServiceInstance.
The CreateDemoService.cs file from the solution is the ONLY bit of code that references DemoServiceInstance and that code DOES NOT actually create an instance of the Service – in fact we could comment out this code and it would have no effect on the operation of the Service Application! The following snippet was taken from Andrew Connells SA sample code http://msdn.microsoft.com/en-us/library/gg543112.aspx – we now remove it as it doing nothing in our demo sample.
We can also remove the SPServiceInstance class itself and still no impact on the service application is felt. The below image shows the SPServiceClass being removed.
It turns out the service still works !……but why is the service still functioning? Because, as you recall from Part 6 the client web part is concretely binding directly to the DemoServiceApplication we created when adding a new SPServiceApplication instance. In our case we call DemoServiceApplication.Create (shown in the image as part of CreateDemoService.aspx / .cs). The client web part only needs to grab a reference to the service application using code similar to what we have shown a number of times, that is service.Applications.Cast<DemoServiceApplication>().First();
The upshot of this bad code is that we have completely circumvented the ability to have multiple servers handling service application requests redundantly in the farm environment. All requests are just routed to the same instance of the Service Application. So lets reverse course just a little and follow these next few steps to remedy the situation. The following steps ultimately enables our ability to activate a particular service on a particular server.
1. Let’s leave Andrew’s code out of the Create page for now
2. Add back the SPServiceInstance class
3. Add a Create method for the SPServiceInstance class that we can use to setup multiple instances as needed
4. In the farm feature for the solution lets be sure we have one instance setup per server (which means we need to iterate through all farm servers to add the SPServiceInstance object).
Lets add the create method to DemoServiceInstance.
Next, on activation add an instance of the service application to each server in the farm from our Feature. In the interest of “full disclosure” I’m developing on a single server VM and have not tested this code (our “non-WCF” demo service application) on a multi-server farm (yet)
That’s pretty much it for this class in general. Done and done. The rest of the plumbing takes place pretty much behind the scenes and you need not do anything further for now.
Our next issue (actually the first major point of this blog) is what to do about the concrete binding situation – this is the most critical problem we have at this point and it should be corrected. What we actually need is a way for our client to call back to our service application in a way that separates where the service application actually executes. The actual SPServiceApplication instance used need not be known to the client – and -- the client should have no clue what server is actually handling the method request. This is where we introduce proxy classes. Proxy classes are client side classes that act as the go-between from the client to the server side instances.
The two important classes in this regard are SPServiceProxy and SPServiceApplicationProxy. These classes have a relationship that mirrors the relationship that SPService and SPServiceApplication have.
SPServiceProxy is rather trivial so I will simply add it to our solution. Here is the only code we need to include for now
I would only point out the decoration called SupportedServiceApplication as having the same Guid as our custom SPServiceApplication called DemoServiceApplication as shown here beginning with “048DC….” below is the original DemoSerivceApplication from previous posts. More on that at a later time.
Of course the important class is DemoServiceApplication but now we need to include its “client side equivalent” to minimize the coupling between client and server. Our next class will be called DemoApplicationProxy and from this point forward the rubber really starts hitting the road. So lets see what our solution looks like now
We can start building out the contents of SPServiceApplicationProxy.cs as follows (same drill as before)
We also need to wire this up properly to the solution so it can be properly created. Remember, this is a client class and therefore should be instantiated at the same time we create the service application (NOT WHEN DEPLOYING VIA A FEATURE). This class creation is administrator controlled. As such, we add the creation of this class to the CreateDemoService.cs code behind for our create page we defined in a previous post and looks (now) as follows
This post is now long enough – we have added the last two major classes for this “non-WCF” version of a service application. In the next post I will finish up a few loose ends and demo once again. Lots more to go 
Cheers!