views:

94

answers:

3

I've hit a wall on this one. I have a WCF library with a respective WCF web service. A sandbox web application attempts to fire one method from this service.

The service, however, will log requests as they are made. The persistence layer here is built with FluentNHibernate. Session management in a web application has been pretty straight forward in the past(ie HttpModules), but in WCF it got a bit tricky for me.

I followed the notes and examples with the IglooCommons library and added the following line to my global.asax(residing in the web service directory).

    protected void Application_Start(object sender, EventArgs e)
    {
        NHibernateFactory.Initialize(new SessionFactory().BuildSessionFactory());
    }

BuildSessionFactory returns the following:

public class SessionFactory
{
    public SessionFactory() { }

    public ISessionFactory BuildSessionFactory()
    {
        return Fluently.Configure()
            .Database(MsSqlConfiguration
                        .MsSql2005
                        .ConnectionString(x =>
                            x.FromConnectionStringWithKey("myConnection"))
                        .ShowSql()
                        .CurrentSessionContext<WebSessionContext>())
            .Mappings(m =>
                m.FluentMappings
                    .AddFromAssemblyOf<OneClass>()
                    .AddFromAssemblyOf<AnotherClass>()
                    .Conventions.Add(
                        PrimaryKey.Name.Is(x => x.EntityType.Name + "ID"),
                        ForeignKey.EndsWith("ID"),
                        Table.Is(x => Inflector.Net.Inflector.Pluralize(x.EntityType.Name))))
            .BuildSessionFactory();
    }
}

The service page(*.svc) loads up with its soothing stock blue "to generate classes use this wsdl" page, with no issue.

When the web application that references this attempts to call a service method,

NHibernateContext.Current().Session

is unable to find any live session. After stepping through the application, the app start method in global.asax is being fired, however seems to be dying(this is a guess) prior to any action requiring it.

I realize IglooCommons may be a bit specific as NHibernateContext is a proprietary library, however, WCF with a persistence layer isn't uncommon. Any thoughts on what I've missed or another direction to take are greatly appreciated.

Additional Note:

For the web application using this service, I've created an "interop" library which was based on the wsdl, auto-generated using svcutil. There isn't a web reference between the web app and the web service, just the web app using the auto-gen classes.

A: 

Have you enabled the ASP.NET service hosting environment for your WCF service? This requires that you:

  1. Apply the AspNetCompatibilityRequirementsAttribute to your service with an AspNetCompatibilityRequirementsMode of Required.
  2. That you configure the hosting environment in WCF web.config like so:

    <system.serviceModel>
        <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
        <!-- rest of config here -->
    </system.serviceModel>
    

More information about WCF Service hosting with ASP.NET is available here in the MSDN documentation.

Drew Marsh
I had not enabled the above. Am I correct in assuming that because the service is what is persisting data(not the web app), that a HttpModule is not required in this scenario?
Alexis Abril
Honestly I don't know how the NHibernate architecture plugs/plays with ASP.NET, so if it requires an HttpModule normally in the "pure" ASP.NET world, you should have that same configuration to use it in WCF this way. The alternative would be that they provide some kind of "pure" WCF behaviors and then you use those and shed the ASP.NET hosting environment since it's more expensive to have that environment spun up around you and doing its own request/response processing on top of WCF's.
Drew Marsh
+1  A: 

See this article http://realfiction.net/?q=node/167

Do what it says and you won't need the aspnetcompatibility enabled.

Neil
A: 

This resolution in particular was a misunderstanding of the IglooCommons lib. The "NHibernateContext" attribute in the example was used to decorate the interface, when in reality it needed to decorate the implementation. By moving this alone, the sample on the Igloo site was able to function normally.

As a side note, the other solutions provided here were excellent in expanding the little knowledge I have of inner workings with WCF and its interaction with NHibernate.

Alexis Abril