Architectural challenge – Convert COM based winforms application that uses DCOM for the distributed communication part to service oriented architecture
Choice of technology – WPF for the smart client part and WCF for the application tier
Possible solution – Forget porting the entire business logic (who needs that nightmare!); retain the business logic that resides in the C++ COM layer and have a wrapper façade layer of services over it
Biggest hurdle – the need to wrap the fully connected, session based COM middle tier with a dis-connected, sessionless architecture based on WCF
Why?- The COM components were designed in such a way that an initial login would establish a session and the winforms client app would hold a handle to it for all subsequent communications till the user does a log-off (or the session times out). This also limited the client applications ability to make concurrent asynchronous calls to the application tier to support parallel operations since the calls had to be serialized through the session handle. On the other hand, the WCF calls were to be designed with a per call instancing type to provide the maximum level of concurrency support and to use the Username/password embedded in the message headers for establishing the identity of the user for each service call.
Here’s my solution – To converge these two distant designs, I decided to create a layer that sits in between the WCF and COM layers that will cache a pool of COM sessions at user level. The WCF service, when it needs to access the COM functionality, would request an instance of the COM session from this layer. If there are free session instances available in the user pool, then it is provided or else a new session is created and the handle returned. Once the WCF layer is done with using the session, it is released back to the pool. This design ensured that
- The WCF layer could seamlessly communicate with the COM functional layer
- Support multiple asynchronous concurrent calls from the client app since there are a pool of sessions available for servicing the requests of each user
Trouble ahead – Things looked and worked fine in the initial round of testing. But when the newly developed WPF smart client app started firing some realtime concurrent requests, a glitch was noticed. If a WCF service makes nested method calls, say for eg., if a service request Service1() calls Method1() and Method2(), then each of these three methods would request for a session instance from the pool for accessing COM functionalities resulting in 3 different session instances being used, where as ideally this should be serviced by a single session instance shared across all the nested calls (since there is no concurrency situation here). This resulted in some noticeable hit in the performance as well as scalability of the application.
The evident solution was to attach the session at a service request level (rather than obtaining it from within the individual method calls). A few hours of brain storming gave me the solution – use custom service behavior extensions.
Why? Custom service behavior extensions in WCF are comparable to SOAP extensions in the web services era and provides handles to extend the WCF request processing pipeline for adding custom functionality. Custom WCF service behaviors would need to implement the System.ServiceModel.Description.IServiceBehavior and System.ServiceModel.Dispatcher.IDispatchMessageInspector interfaces which provide methods like AfterReceiveRequest, BeforeSendReply etc. The ‘AfterReceiveRequest’ is called immediately after the incoming request hits the WCF request processing stack and ‘BeforeSendReply’ immediately before the response is send out to the reply channel. Also for any custom service behavior to be used from an application configuration file, it needs to extend the System.ServiceModel.Configuration.BehaviorExtensionElement class.
Final Solution – Now the request for a session from the pool will happen from the ‘AfterReceiveRequest’ and it will be added into the request properties collection, so that any number of methods that are invoked in the same request context can now use a single session instance. A concurrent call would appear as a different service request for which a different session is attached form the pool. Once the request processing is complete and reaches the ‘BeforeSendReply’ stage, the session is released back to the pool. Now to utilize this service behavior, a couple of changes had to be made in the configuration file of the service hosting application, as shown below.
- Add the service behavior type details to the extensions section under system.serviceModel as shown below.
<system.serviceModel>
<extensions>
<behaviorExtensions>
<add
name=”SCSessionPoolServiceBehavior”
type=”MyProject.SCServiceBehaviorExtension, MyProject,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=null” />
</behaviorExtensions>
</extensions>
- And then add the service behavior extension name to the desired service behavior
<behavior name=”xxxxxxx_WithSessionPool”>
………………………
<SCSessionPoolServiceBehavior />
</behavior>
We’re listening.
Have something to say about this article? Contact us to know more or share it with us on Facebook, Twitter or our LinkedIn.
