Archive

Posts Tagged ‘WCF’

SOA Services and the Many Visual Studio Solution File Problem

2011/09/10 Leave a comment

We’re working on a new project at work which is going to be implemented with a number of components with varying levels of dependencies on one another.  Since we knew that this project was to be quite large we thought it would be rather nice if we split the entire System into many Visual Studio solutions.   This would encourage components to be accessed via established contracts instead of potentially back-door methods.  It creates a rather friendly “black-box” perception of said components when you can only see the referenced .DLL instead of spying source code.

Sadly we ran into a problem which I suspect others have come across at one time or another – it can lead to circular dependencies when one project depends on contracts in another whilst at the same time one component may require say a Windows Communication Foundation (WCF) client proxy.  This is quite significant when many of the components are of the WCF variety.

One solution of course particularly when dealing with Service Orientated Architecture (SOA) is to adopt a Schema First practice whereby you define all your types, messages in XSD format rather than leaping straight into say c#.   Sadly, Schema First can be a bit like designing all your .net classes in a modelling tool where the code is generated – it’s nice but not particularly productive.  Plus, unless you have the rather good Stylus Studio and WSCF.blue tools, who wants to hand-crank XSD and WSDL just to add an extra argument to a method?  Not many agile programmers I don’t think.

Another possibility is to take all your .net domain classes and contracts for all the WCF services and place them in a separate solution.  Though this is arguably faster than code generation from modelling tools or schema first, it is rather annoying when you wish to refactor your code.   Renaming a method in the contracts solution won’t automatically rename the classes in the implementation solutions.

Ultimately having many Visual Studio environments open just for contracts and the services just plain sux, particularly when you need to compile things in a particular order.

So I’ll be boggled if I know what to do for the short to medium term.  I suppose we’ll just continue what seems to be the common practice – have a monolithic Visual Studio solution that at some point in the future we can split up once code changes become idle.

Which opens up another can of worms – splitting up the code introduces a reasonable level of risk particularly when we can assume that its already been QA’d.

I’d love to hear if anyone has some great ways to solve this dilemma.

Categories: Development Tags: , ,

Let’s Make a Distributed Object Cache in .NET with WCF 4’s Peer-to-Peer Binding

2011/09/04 2 comments

A distributed object cache is a system that allows one program to store an object in memory and have it available to another program on another computer.  Any node can store and make changes to the object.   Caches make huge performance improvements in certain workflows.  One of the more popular is Memcached, which I was hoping to use but was disappointed when I found that the devs have not made a .NET client library.  I would rather use one made by the Memcached team than some third party. Winking smile

Making an object cache in .NET is pretty straight forward when you think about it – its just a key-value pair with items that timeout after some time interval.  Making it work over the network is potentially difficult in a decentralised design but WCF 4 has the wonderful NetPeerTcpBinding that does all the tricky work of discovering, joining and leaving a virtual mesh of nodes in the distributed cache via a peer-to-peer (P2P) mesh.  Actually NetPeerTcpBinding was introduced in 3.5 or possibly 3 but WCF 4 is so much easier on the whole but I digress.

Basically NetPeerTcpBinding acts very much like NetTcpBinding so get your program to work with that first.  To transition to NetPeerTcpBinding you merely change your binding – no other changes to program flow are required.

Here’s a snippet of my WCF cache host config file:

<bindings>
         <netNamedPipeBinding>
             <binding name="noSecurityPipeCofig">
                 <security mode="None" />
             </binding>
         </netNamedPipeBinding>
         <netPeerTcpBinding>
             <binding name="noSecurityP2PBinding">
                 <security mode="None" />
             </binding>
         </netPeerTcpBinding>
         <netTcpBinding>
             <binding name="tcpNoSecurityConfig">
                 <security mode="None" />
             </binding>
         </netTcpBinding>
     </bindings>
     <services>
         <service behaviorConfiguration="myServiceBehaviour" name="Schmicky.Cache.Services.CacheService">
             <clear />
             <endpoint address="announcements" binding="netPeerTcpBinding"
                 bindingConfiguration="noSecurityP2PBinding" name="p2pEndpoint"
                 contract="Schmicky.Cache.Contracts.Interfaces.ICacheBroadcast"
                 listenUriMode="Explicit">
           
             </endpoint>
             <endpoint address="local" binding="netNamedPipeBinding" bindingConfiguration="noSecurityPipeCofig"
                 name="pipe" contract="Schmicky.Cache.Contracts.Interfaces.ICacheQuery" />
             <host>
                 <baseAddresses>
                     <add baseAddress="net.p2p://broadcastmesh/SchmickyCache/" />
                     <add baseAddress="net.pipe://SchmickyCache/" />
                 </baseAddresses>
             </host>
         </service>
     </services>

You will note that I have two endpoints.  The reason for this is that the P2P generally only allows for announcements and therefore one-way calls.  This sort of threw a spanner into the works as I thought a cache wouldn’t be too good if you could only store and not retrieve.

Then I thought, well why not make a secondary full-duplex endpoint just for queries?  That would work, and so I made use of the high-speed channel from NetNamedPipeBinding.  It doesn’t matter that its local host only because both endpoints are talking to the local cache access point host.  Yipee!

So with two endpoints it makes sense to map them to two different interfaces – one for storage and the other for cache query and retrieval:

[ServiceContract(ProtectionLevel = ProtectionLevel.None)]
    public interface ICacheBroadcast
    {
        /// <summary>
        /// Puts the specified item.
        /// </summary>
        /// <param name="request">The request.</param>
        [OperationContract(IsOneWay = true)]
        void Put(PutItemRequest request);

        [OperationContract(IsOneWay = true)]
        void Touch(string key);
    }

 

[ServiceContract( ProtectionLevel = ProtectionLevel.None, SessionMode = SessionMode.Allowed)]
    public interface ICacheQuery
    {
        [OperationContract(IsOneWay = false)]
        GetItemResponse Get(GetItemRequest request);
    }

When an item is stored it is broadcast to all other nodes in the mesh very quickly.  Retrieving an item is immediate for the app storing it in the first place as there is no network latency.  Remote nodes won’t know about it till it is broadcast there.  When any node gets an item I send an asynchronous touch command to all other nodes to keep the item alive.  .NET 4’s Task class is quite useful here.

The best thing about the P2P in WCF is that there is no looping’ing of sending updates to each node – its all encapsulated by WCF. Think UDP.

So now I have a working distributed cache and it only took me a day to do.  Who said things are too complex?

Till next time.

Categories: Development Tags: ,

WCF and nHibernate Can Live Together in Peace

2011/04/17 Leave a comment

WCF and nHibernate are two rather useful technologies for creating say SOA Entity Services[1].  WCF, particularly in .NET 4 makes it extremely easy for authoring a communications conduit whilst nHibernate unquestionably does to DB access as WCF does to communications.  Whether or not nHibernate has a place in large scale enterprise is a topic for another day.

I recently came across some peer code which cleverly defined a custom WCF service behaviour for initialising nHiberate when the service is first accessed and then for each method call.  It made good use of  the ability to utilise .NET attributes applied to the service class so developers in effect merely had to add one line of code to turn a WCF service into a DB-aware one. Quite well done I thought.

A problem occurred though when one wanted to just see if the service was published correctly by browsing to the .svc file in a web browser.  Instead of the usual WCF greeting displaying pseudo client code in a web page, an error and stack dump was displayed mentioning something about nHibernate.

Unfortunately, the mere presence of the class-level attribute meant that the nHibernate custom service behaviour was being called and I had not setup my database or some such.  Interestingly the error occurs even though we were not invoking any methods.  This meant it was technically difficult to verify the successful publication or hosting of the WCF service.  More disturbing was that it now broke all my MS Test tests for instantiating and invoking my WCF service.  Needless to say TeamCity was now displaying lots of red lights.

We discussed this and came up with an idea of moving the nhibernate service behaviour into the service configuration (in this case the web.config file) rather than hard code it explicitly with attributes or inline code.  I’m a great fan of defining behaviour by configuration irrespective of what technology the config is persisted as.  The beauty of this approach is that we can take advantage of web.config transforms for each build configuration.  Configurations for build, release, with DB and without.  Just perfect for continuous integration testing of the service itself but also deployed testing between client and service.

WCF allows you to define your own custom service behaviours and register them in the config file. This can be done manually by web.config heroes or via the magnificent WCF Service Configuration Editor.

First you need to define an Element Extension. Basically this represents the XML node in the config file. It acts as a moniker for creating an instance of your extension.  It is this moniker that the Service Config editor detects and not the behaviour extension itself.

public class NHibernateServiceBehaviourExtensionElement : BehaviorExtensionElement

{

protected override object CreateBehavior()

{

return new MyNHibernateServiceBehaviour();

}

public override Type BehaviorType

{

get { return typeof(MyNHibernateServiceBehaviour); }

}

}

Then to define the actual extension:

public class MyNHibernateServiceBehaviour : Attribute, IServiceBehavior { … }

Put both of these into ideally the same assembly.  Because of the way WCF and the Service Editor works the assembly will need to be in the same path.  This is arguably not feasible for all occasions so we elected to place them in the GAC.  Luckily nhibernate, log4net, hibernatinglamas (or was that rhinos) are all strong named.

With that done, I recommend that you use the WCF Service Config tool to do the next bit.  After all, if this part fails then it will most likely will in production.

NewImage

Save that to your typical config transforms and then it keeps everyone happy, even grumpy slappers of nHibernate such as me. 😉  This approach will allow you to have full debug WCF-only configs for local testing; full debug WCF+DB testing;  CI WCF only and CI WCF+DB.  Configs for all occasions.

Happy happy joy joy!

——————————–
[1] Thomas Erl, Patterns of SOA Design

Categories: Development Tags: , ,

Schema First

2011/02/24 2 comments

Traditionally, contract-first to us WCF developers meant a .NET interface.  This is a bit silly because In the word of SOAP messages, your recipient more than likely won’t give a toss for your .NET interface because they will never see it; rather it is the SOAP XML message that pops out the other end of your comms conduit.

For this reason, many feel you should Schema First your primitives and message types in XSD and auto-gen the following:

  • WSDL
  • .NET WCF interfaces
  • .NET WCF service stubs
  • .NET classes for your primitives (e.g. Person, Order, GolliWog)

…from the original XSD.

That way when you need to interop with a third party they can adhere to your XSD or you can find a middle ground via XSLT.

More info can be found here

Categories: Development Tags: , ,

Windows Server AppFabric – Where the Party is at for .NET 4 WCF Declarative Workflow Services

2011/02/05 Leave a comment

appfabric transparent

I don’t think I’ve been so excited about a new server technology since DCOM. Windows Server AppFabric (codename “Dublin”) is one of the latest server apps that makes deploying, hosting, persisting, managing and distributing .NET WCF services (particularly WCF declarative workflow varieties) rather simple.

…AppFabric is able to perform magic and route incoming  TCP, named-pipes or MSMQ to the service even though it resides in IIS

Some would say AppFabric is arguably just an add-in for IIS.  Though true in some respects that would be a little unappreciative of the full aspects of AppFabric.  For one thing – in exactly the same way that WCF declarative workflows encapsulate service interfaces, classes and code; AppFabric encapsulates

  • WCF hosting and transports
  • configuration
  • service and workflow tracking
  • service control

Plus there’s other uber goodies such as:

  • Workflow hibernate-to-database
  • Distributed Object Cache
  • Dynamic Scaling
  • PowerShell support

In addition some would point out that IIS has had the ability to host WCF services for some time – true; but I would point out that usually it required that the service be locked into the http xxx binding meaning stiff bickies for devs such as myself who would like to use some of the rather splendid features that IIS offers but would rather a different transport like named pipes, TCP or MSMQ. <insert cliché here>

But AppFabric solves all that because now although the service is technically hosted in IIS – it is not limited to just http for AppFabric is able to perform magic and route incoming  TCP, named-pipes or MSMQ to the service even though it resides in IIS.  Wonderful!

So now in WCF-WF .NET 4 we do not necessarily have to worry about coding service interface and classes explicitly; we no longer have to worry about writing a hosting application or what underlying transport to use[1]

References

  1. Features and Capabilities
  2. Scalable, Long-Running Workflows with Windows Server AppFabric
  3. Deploying a WCF Service to AppFabric
  4. Building a declarative WCF service using Workflow Foundation 4 and Content Based Correlation

———————-
[1] though WCF arguably always did this, AppFabric takes it to the next level

Categories: Development Tags: , , ,

The Emperor’s New Clothes – Affects Developers Too

2010/03/30 Leave a comment

…Two weavers who promise an Emperor a new suit of clothes invisible to those unfit for their positions or incompetent. When the Emperor parades before his subjects in his new clothes, [only] a child cries out, "But he isn’t wearing anything at all!".  [Everyone else was was too scared to say anything.] [3]

emperor_21702_lg

Something that I have noticed about the software development industry is that people will go to extraordinary lengths to author the most well structured software system.  This includes the utilisation of wonderful design patterns from the original Gang of Four in addition to new contemporary additions; the surprising new stage of developers not only adding test cases but also creating them themselves in the form of NUnit or MSTest and adding them to their project; the use of object-relational mapping (ORM) technologies and more recently, the use of something supposedly new called inversion of control [+ dependency injection] (IoC DI)[1].

The consequence of all of this leads to not just an improved working experience for the developer, but also creates software that is better structured, designed, loosely-coupled and obviously testable.  Developers have been wonderful in their approach to ‘let’s stop for a minute and do this better’ mentality and history has shown that all these new tactics have been quite successful leading to well-rounded reliable software.

However, in order for many of the above mentioned technologies/patterns/practises to work, generally requires developers to resort to doing something quite disturbing, something that requires complicated procedures; something that is error prone; something that can be a security risk; and in some cases something that can lead to application instability.

I speak of course is the practice of developers hand-editing XML files for the purpose of configuring a technology or 3rd party system that is either a framework or library.  XML when used right can be rather wonderful, I fully support it for scenarios such as data interoperability, transformations, SOAP messaging and so on.  I have no problem with a configuration tool or system saving application settings to XML, just so long the user experience is not hand-edited-XML-first.  Contrary to widespread belief, XML is not human readable, I doubt your English-speaking grandmother will be able to decipher it.  Nor is XML self-correcting – just try deleting a ‘>’ and see what happens.  This is why it should never be used for manual editing regardless of skill, I doubt anyone can claim 100% hand-editing without errors.

Libraries such as NHibernate require configuration before it can be used – fair enough, but to force developers to manually tweak XML configuration files is not only time consuming it is also error prone.  I believe there are now tools to generate the XML files.

IoC systems such as StructureMap also require configuration. Most uses I have seen is via hand-edited XML (though I believe runtime calls are also available). The issue here is that configuration for SM is subject to be:

  • error-prone
  • type-safety concerns
  • tedious
  • can lead to application instability[2]
  • can lead to security issues[2]

Then there are the technologies that take XML to heart literally, the authors being fan boys of XML so much they include it in the name of their system. The bizarre installer technology Wix and Microsoft’s XAML are two examples.   Wix offers developers questionable value whilst at the same time opens up a whole new set of problems for installer developers:

  • error-prone
  • lack of a rich developer experience
  • tedious
  • significant increase in time investment for making an installer

Shame on you Visual Studio users, have you not seen the Setup project wizards?  Click a few buttons and away you go. You can even do custom build actions in type-safe .NET should the need arise!

Don’t get me started on XAML. Whoever thought programming in a data-structure file format was a good idea has issues. Hand-edited XSLT is confusing enough.  I get the impression that Microsoft wanted to release an alternative to Windows Forms development but instead of providing a proper editor they just deployed XAML and said “…there you go! have fun!”. we certainly got fooled into thinking hand-editing XAML is pretty neat.

Personally I feel Wix and XAML share many traits, they both represent a backward step for the developer experience; crazy programming in a data-structure mentality; and also highlight a lack of a good IDE tool.

On the subject of Microsoft, their original sin was to allow or to give the impression to developers that the creation, deployment and hand-editing of xxx.exe.config files is the norm.  This practice remains to this day even surprisingly after Vista Development Guidelines stipulate that no files should be written to in .\Program Files by the application after the application has been installed (ignoring patches).  So you shouldn’t be updating xxx.exe.config files there.  Yeah I know there is the file virtualisation thing, but then again I can call WriteProfileString to write to the Win.ini file.  It does not mean that because you can do something, that you should do something.

Microsoft followed this up by allowing .NET Remoting and later WCF configuration to be, by default, persisted to the application’s xxx.exe.config file.  Again it’s bad form (see my prior post) because a user can easily change application settings that can have huge ramifications on your application. Case in point – WCF allows you to specify a transport provider as well as transport attributes. A user can change your finely-tuned, well tested and approved TCP/IP binary, no encryption, SOAP message settings to say https and now suddenly your application’s message size has grown considerably.  Not only that, because the user indicated either consciously or though accident WS-R, it’s no longer a one way message but perhaps up to four or so!

The innocent editing of a plain-view configuration file can have major ramifications for not just application behaviour but also application performance!  A GUI Configuration tool provides a rich user experience – it warns the user; it usually has some form of online help.  A XML config file does not!

Some of the technologies I mentioned have tried to clean their act up, unfortunately, the damage has been done perhaps regardless of the good intentions of follow-up tools in reducing the XML hand-editing.    However, people continue to hand-edit XML even with the knowledge of richer API counter-parts or the use of additional helper tools.

So I think or perhaps hope that developers are aware that providing complex configuration via hand-edited XML or to program in XML-related data structures is not really ideal, it’s a bit like the Hans Christian Andersen story – The Emperor’s New Clothes.

 

Most of us know its not really a good idea but we don’t do anything about it.

Until next time…

—————————————————-
[1] IoC DP is nothing new, anyone familiar with COM Shell Namespace Extensions plug-ins development (that has pretty much not changed since Windows 95) will see similarities. Microsoft Management Console snap-ins is another example. I’m quite sure avid readers will find other examples that predate my computer lifetime.  IoC incidentally merely means the API calls into your code, a button click event is a good example.

[2] because types and methods must generally be exposed publically for SM IoCDP to work, together that most configuration is via a XML config file, a reasonably skilled malicious user can alter your config to call a different type or member thus changing the behaviour of your system in an unforseen way. e.g. You might have accidently exposed a type or method publically thus allowing the malicious user to use that type instead. This type may offer similar functionality but could lead to a drastic outcome.  Perhaps this type was for testing purposes only.

[3] wikipedia – http://en.wikipedia.org/wiki/The_Emperor%27s_New_Clothes

WCF the Manual Way…the Right Way

2010/03/01 Leave a comment

Miguel A. Castro has a rather good article over at devx.com concerning best practices when developing WCF applications. 

Visual Studio 2008 and the .NET 3.0 extensions for Visual Studio 2005 add several new templates that simplify creating .NET 3.0 items such as WPF forms, Workflows, and WCF services. Developers have used templates such as these since the beginning of time to create traditional application elements such as Windows Forms, Web Forms, and User Controls—so you might think that these templates are equally great. Unfortunately, creating WCF projects or project items come with more baggage than you can imagine. They also don’t exactly promote some best practices when designing WCF services…

In it he describes the wizards are perhaps not the best thing in the long term due to the tight coupling, code duplication and poor code reuse produced.  His alternative addresses these issues so much so I followed his example in a recent project I was fiddling with.

Well done Miguel!

Read more…

Categories: Development Tags: