Examples on setting up for WCF?

Examples on setting up for WCF?

Old forum URL: forums.lhotka.net/forums/t/1388.aspx

jpalexa posted on Wednesday, October 04, 2006

My apologies if this is somewhere obvious; my meek searching of the forum did not reveal what I was hoping to find.

Are there documented steps on how to implement the beta CSLA WCF channel and data portals?  I assume (!) that adding the WcfChannel project into the main CSLA solution and rebuilding gets me hooked up from a CSLA.dll perspective.

I was wondering if there was a Chapter 12-esque example of implementing the remote WCF data portal (creating an IIS virtual directory, creating a .svc file, proper set up of the config files on both the server and the client, etc.).

Thanks in advance -- JP

RockfordLhotka replied on Wednesday, October 04, 2006

Unfortunately I haven't had time to document the channel...

You don't need to merge WcfChannel into CSLA at all - you can build it seperately into its own DLL, and then just reference that DLL from your UI project and WCF service project.

Then on the client, just change the data portal configuration to point to the WcfChannel assembly and proxy class. Also, in the client config you need to configure WCF itself.

On the server, as you note, create an svc file and configure WCF itself through web.config.

At some point in the next few weeks I do plan to write the Chapter 12-esque documentation for using the channel, but I've been waiting until WCF is final, and until I have time to then finalize both the C# and VB versions of the channel.

I also will merge it into CSLA itself - in CSLA .NET 2.2 (or 3.0?) - but that's a bigger task, because at that point I'll provide full support for WCF, including DataContract serialization.

RockfordLhotka replied on Wednesday, October 04, 2006

To expand on that quickly though.

The UI project references the Csla.WcfChannel assembly and has a config file like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
  </configSections>
  <appSettings>
    <add key="CslaAuthentication" value="Csla" />
    <add key="CslaDataPortalProxy"
      value="Csla.DataPortalClient.WcfProxy, Csla.WcfChannel"/>
  </appSettings>
  <system.serviceModel>

    <client>
      <endpoint name="WcfDataPortal"
                address="http://localhost:1107/WcfHost/WcfPortal.svc"
                binding="wsHttpBinding"
                contract="Csla.Server.Hosts.IWcfPortal" />
    </client>

  </system.serviceModel>
  <system.diagnostics>
    <sources>
      <!-- This section defines the logging configuration for My.Application.Log -->
      <source name="DefaultSource" switchName="DefaultSwitch">
        <listeners>
          <add name="FileLog"/>
          <!-- Uncomment the below section to write to the Application Event Log -->
          <!--<add name="EventLog"/>-->
        </listeners>
      </source>
    </sources>
    <switches>
      <add name="DefaultSwitch" value="Information" />
    </switches>
    <sharedListeners>
      <add name="FileLog"
     type="Microsoft.VisualBasic.Logging.FileLogTraceListener, Microsoft.VisualBasic, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"
     initializeData="FileLogWriter"/>
      <!-- Uncomment the below section and replace APPLICATION_NAME with the name of your application to write to the Application Event Log -->
      <!--<add name="EventLog" type="System.Diagnostics.EventLogTraceListener" initializeData="APPLICATION_NAME"/> -->
    </sharedListeners>
  </system.diagnostics>
</configuration>

The Wcf server project is a virtual root in IIS and references the Csla.WcfChannel assembly (along with your business assembly typically - so the business assembly gets into the bin directory). The WcfChannel.svc file looks like this:

<%@ ServiceHost Service="Csla.Server.Hosts.WcfPortal" %>

The web.config file looks like this:

<?xml version="1.0"?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
  <appSettings>
    <add key="CslaAuthentication" value="Csla" />
  </appSettings>
  <connectionStrings>
    <add name="PTracker"
    connectionString="Data Source=.\SQLEXPRESS;AttachDbFilename=&quot;C:\Visual Studio Projects\csla20\ProjectTracker20cs\PTracker.mdf&quot;;Integrated Security=True;User Instance=True"
    providerName="System.Data.SqlClient" />
    <add name="Security"
    connectionString="Data Source=.\SQLEXPRESS;AttachDbFilename=&quot;C:\Visual Studio Projects\csla20\ProjectTracker20cs\Security.mdf&quot;;Integrated Security=True;User Instance=True"
    providerName="System.Data.SqlClient" />
  </connectionStrings>
  <system.serviceModel>
  <services>
   <!-- Before deployment, you should remove the returnFaults behavior configuration to avoid disclosing information in exception messages -->
      <service name="Csla.Server.Hosts.WcfPortal" behaviorConfiguration="returnFaults">
        <endpoint contract="Csla.Server.Hosts.IWcfPortal" binding="wsHttpBinding"/>
      </service>
    </services>
  <behaviors>
   <serviceBehaviors>
    <behavior name="returnFaults">
     <serviceDebug includeExceptionDetailInFaults="true"/>
    </behavior>
   </serviceBehaviors>
  </behaviors>
 </system.serviceModel>
 <system.web>
  <compilation debug="true">
   <assemblies>
    <add assembly="System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
    <add assembly="System.Runtime.Remoting, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
    <add assembly="System.Design, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/>
    <add assembly="System.Transactions, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/></assemblies></compilation>
 </system.web>
</configuration>

 

jpalexa replied on Wednesday, October 04, 2006

Yes, that worked beautifully for me.  Thanks a ton!

JamesColeman replied on Wednesday, January 17, 2007

I got it working as well, thanks for the guidance.

I want to make sure some of my assumptions are correct.  I am working with a client where we will have some CSLA business objects that are going to accept a credit application and return a credit decision (i.e. you are approved for 30k - There is more to it than that but keeping things simple).  The extranet is under our control and so they are going to be using this CreditApplication business object directly but there will also be dealers external to the company that will be submitting a CreditApplication request and getting a CreditDecision response back.

Assumptions I am making:
- The extranet web application will be calling the business tier through Enterprise Services because it is the best peformance wise and we can open up the library to our web developers

- The dealer application will be calling our service layer that is going to expose some of the functionality in our business objects as services but they will not get the full CreditApplication business object, only the prop/methods we make available.  I am assuming we will make some WCF web services with message level security (X.509).

- We wouldn't actually use the WCFChannel for the dealers because we don't want to open up the entire library to them

- The WCFChannel might be used in replace of Enterprise Services for the extranet because if we wanted to, we could keep things over TCP/IP and binary and WCF doesn't mean HTTP/Text - Right?

Let me know if any of the above sounds off.  I think I just know enough to be dangerous.  I guess I am not for certain when the WCFChannel would be used in the real world.  Any guidance or oppionions (Rocky's or others) would be appreciated.

Thanks
~james

RockfordLhotka replied on Wednesday, January 17, 2007

Everything you are saying makes sense to me.

The one thing I'd quibble with is the use of ES rather than WCF. Now that WCF is out, it is the replacement not only for Remoting and Web Services, but also for ES. If you are installing .NET 3.0, I'd go right ahead and use the WcfChannel for the extranet scenario.

dlutz52 replied on Wednesday, February 06, 2008

Rocky --

I was sent this URL by a colleague. Upon reading it and seeing the date I have to ask if this thread is out of date or not?

It appears to be almost up to date except that the CslaDataPortalProxy assembly value is Csla.WcfChannel whereas in the CSLA 3.0 release it is just Csla.

In this thread you have: <add key="CslaDataPortalProxy" value="Csla.DataPortalClient.WcfProxy, Csla.WcfChannel"/>
whereas the released version has: <add key="CslaDataPortalProxy"
      value="Csla.DataPortalClient.WcfProxy, Csla"/>

Or, maybe this is some additonal functionality that I am not aware of?

Best regards --
David Lutz
County of Marin


 


RockfordLhotka replied on Wednesday, February 06, 2008

I released a beta WCF proxy for CSLA .NET 2.1, and that article refers to that standalone proxy.

 

When I put the proxy actually into CSLA itself the assembly name changed of course, because it is now in Csla.dll itself.

 

Rocky

 

 

From: dlutz52 [mailto:cslanet@lhotka.net]
Sent: Wednesday, February 06, 2008 4:06 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Examples on setting up for WCF?

 

Rocky --

I was sent this URL by a colleague. Upon reading it and seeing the date I have to ask if this thread is out of date or not?

It appears to be almost up to date except that the CslaDataPortalProxy assembly value is Csla.WcfChannel whereas in the CSLA 3.0 release it is just Csla.

In this thread you have: <add key="CslaDataPortalProxy" value="Csla.DataPortalClient.WcfProxy, Csla.WcfChannel"/>
whereas the released version has: <add key="CslaDataPortalProxy"
      value="Csla.DataPortalClient.WcfProxy, Csla"/>

Or, maybe this is some additonal functionality that I am not aware of?

Best regards --
David Lutz
County of Marin

 

 

 



Copyright (c) Marimer LLC