The basic intrinsic types (e.g. byte, int, string, and arrays) will be serialized automatically by WCF. Custom classes, like your UploadedFile, won't be.
So, a silly question (but I have to ask it...): is UploadedFile marked as a [DataContract]? If not, you'll need to make sure that it is, and that each of the members in the class that you want to send are marked with [DataMember].
Unlike remoting, where marking a class with [XmlSerializable] allowed you to serialize the whole class without bothering to mark the members that you wanted serialized, WCF needs you to mark up each member. (I believe this is changing in .NET 3.5 SP1...)
A tremendous resource for WCF development is what we know in our shop as "the fish book": Programming WCF Services by Juval Lowy. Unlike some of the other WCF books around, which are a bit dry and academic, this one takes a practical approach to building WCF services and is actually useful. Thoroughly recommended.
I would simply host a WCF proxy service. (http://firewallhostaddress:80/MyDataz).
Inside the GetData method you would use the WCF proxy to get the data from the service. The WCF service inside the network would talk to the SQL server.
Am I missing something? Maybe later I could work up an example.
It's possible to forgo xml config and build up the Binding and Endpoint classes associated with the service in the constructor or a custom "Service Factory". iDesign has some good information on this:
http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=5&tabid=11
(See In Proc Factory)
In their approach, you set attributes on your services to specify at a high level how they should work (ie [Internet], [Intranet], [BusinessToBusiness]), and the service factory configures the service according to best practices for each scenario. Their book describes building this sort of service:
http://www.amazon.com/Programming-WCF-Services-Juval-Lowy/dp/0596526997
If you just want to share configuration XML config, maybe use the configSource attribute to specify a path for configuration: http://weblogs.asp.net/cibrax/archive/2007/07/24/configsource-attribute-on-system-servicemodel-section.aspx
If the client is WinForm or WPF, you need to use [CallbackBehavior(UseSynchronizationContext = false)] as otherwise the client will not process the incoming message until the UI thread enters the message loop.
Firstly a “Duplex” channel in WCF is not truly Duplex! A message from
Client to server
Can block a message the server is waiting for from the client
(or the other way round)
As messages are only dispatched in order on a single WCF channel. A Duplex WCF channel does NOT give you two incoming message queues. The results coming back from a “TwoWay” call are just the same as the “call” as this level of the WCF stack. Once you get your head round this a lot of the problems become clearer to understand.
If the client is WinForm or WPF, you may need to use [CallbackBehavior(UseSynchronizationContext = false)] as otherwise the client will not process the incoming message until the UI thread enters the message loop.
Some rules I found to help avoid deadlocks. (Look at my WCF questions to see the pain I had!)
The sever must never call out to a
client on the same connection as a
call from the same client is in
process on.
And/or
The client must never call back to the
server on the same connection as is
used for the “callbacks” while
processing a call-back.
The next time I think I will just use two contracts (and hence TCP connections) one for the callback and other for all client->server requests. Or use my own polling system, as this gave me so much pain.
Sorry I don’t have time today to write an example. Anyway most examples work for what the example is trying to do, but break down in real life for some reason to do with your application.
The best web site I know for WCF examples is Juval Lowy’s web site.
Your may also find the questions I asked about WCF on Stack Overflow useful, as I was having the same kind of problems as you.
Also spending a day or two reading all the WCF questions and answers on Stack Overflow will give a good idea of the problems to avoid.
If you are going to be developing with .NET, use WCF for your interprocess communication. WCF greatly simplifies development because the intricacies associated with a specific communication mechanism (e.g., sockets, pipes, etc.) are abstracted behind a unified programming model. Thus, it doesn't matter if you choose to use http, tcp, or named pipes for your transport mechanism, the programming model is the same.
For an overview of WCF, watch this free video at dnrTV. It covers the purpose of WCF and demonstrates WCF programming through some easy-to-follow examples.
If you have not already created your Windows service but plan to do so in C#, you can follow the step-by-step here.
A primer on WCF (such as What Is Windows Communication Foundation?) is a good place to start. WCF can use SOAP to implement the contracts way down deep. WCF also uses a variety of communication facilities within windows (and any custom ones you want to create) so talking across machines is built in.
The very essence of contract (IMO) implies that this is present on both sides of the communication. In a pure .net cases I've usually put the contract definitions in separate assemblies and share them. In other places I've used WSDL to be the main contract definition so that the client and service share definitions.
Edit: Answering comments
You can knock up simple examples of communication in WCF easilyy (provided you know the basics of comms on windows including firewalls etc). However doing something custom is not easy but there are many many resources on the web and books to help you get there.
I don't know all answers but here are the ones I do know
transport security means the communication is encrypted while the message is transported so it can't be read and or tampered with. Message security means the contents of the message itself is encrypted the transport however isn't necessarily. Message security can for instance be used with HTTP while transport security would require the use of HTTPS (or other bindings).
IPrincipal principal = Thread.CurrentPrincipal;
no answer
Yes, although SSL itself uses certificates it's not the same. You can have the client send a certificate which is known to the service or which is signed by a trusted authority to that the service knows who the client is and whether to allow them to make the call or not. Using SSL will only ensure that third parties can't read the communication between the client and the services by intercepting the network packages.
IPrincipal principal = Thread.CurrentPrincipal; principal.Identity.Name;
No.
You have None, Transport, Message and Mixed security as your options however Transport security will require calling the endpoint using HTTPS since thats the secured version of the protocol
Scopes are immensely useful in
customizing discovery and in adding
sophisticated behavior to your
application, especially when writing a
framework or administration tools. The
classic use for scopes is to enable
the client to distinguish among
polymorphic services from different
applications. However, this is
somewhat of a rare occurrence. I find
scopes handy when it comes to
distinguishing among endpoint types in
the same application.
For example, suppose for a given
contract you have multiple
implementations. You have the
operational mode used in production
and the simulation mode used in
testing or diagnostics. Using scopes,
the client can pick and choose the
correct implementation type needed,
and different clients never conflict
with one another by consuming one
another’s services. You can also
have the same client pick up a
different endpoint based on the
context of the invocation. You could
have endpoints for profiling,
debugging, diagnostics, testing,
instrumentation and so on.
This fits very well with the kind of problems you want to solve.
The article also contains good samples on declaring scopes both in configuration and in code. From service consumer's point of view I see two options: you can stuff all your desired scopes in FindCriteria instance that you pass to the DiscoveryClient.Find method if you want to filter your services on the discovery stage or you can get all services and check their scopes by hand.
Scope itself is an Uri object so it can put a lot of different information there using "key=value" notation. That should take care of "extending" the scope filtering and it doesn't limit you in terms of forward compability.
The basic intrinsic types (e.g.
byte,int,string, and arrays) will be serialized automatically by WCF. Custom classes, like your UploadedFile, won't be.So, a silly question (but I have to ask it...): is UploadedFile marked as a
[DataContract]? If not, you'll need to make sure that it is, and that each of the members in the class that you want to send are marked with [DataMember].Unlike remoting, where marking a class with [XmlSerializable] allowed you to serialize the whole class without bothering to mark the members that you wanted serialized, WCF needs you to mark up each member. (I believe this is changing in .NET 3.5 SP1...)
A tremendous resource for WCF development is what we know in our shop as "the fish book": Programming WCF Services by Juval Lowy. Unlike some of the other WCF books around, which are a bit dry and academic, this one takes a practical approach to building WCF services and is actually useful. Thoroughly recommended.
I would simply host a WCF proxy service. (http://firewallhostaddress:80/MyDataz).
Inside the GetData method you would use the WCF proxy to get the data from the service. The WCF service inside the network would talk to the SQL server.
Am I missing something? Maybe later I could work up an example.
WCF Examples: http://msdn.microsoft.com/en-us/library/ms751514.aspx
I also recommend the book Programming WCF Services by Juval Lowy. http://www.amazon.com/Programming-WCF-Services-Juval-Lowy/dp/0596526997
It's possible to forgo xml config and build up the Binding and Endpoint classes associated with the service in the constructor or a custom "Service Factory". iDesign has some good information on this: http://www.idesign.net/idesign/DesktopDefault.aspx?tabindex=5&tabid=11 (See In Proc Factory)
In their approach, you set attributes on your services to specify at a high level how they should work (ie [Internet], [Intranet], [BusinessToBusiness]), and the service factory configures the service according to best practices for each scenario. Their book describes building this sort of service: http://www.amazon.com/Programming-WCF-Services-Juval-Lowy/dp/0596526997
If you just want to share configuration XML config, maybe use the configSource attribute to specify a path for configuration: http://weblogs.asp.net/cibrax/archive/2007/07/24/configsource-attribute-on-system-servicemodel-section.aspx
Firstly get yourself a copy of Programming WCF Services, if you don't already have one.
If the client is WinForm or WPF, you need to use
[CallbackBehavior(UseSynchronizationContext = false)]as otherwise the client will not process the incoming message until the UI thread enters the message loop.Firstly a “Duplex” channel in WCF is not truly Duplex! A message from
As messages are only dispatched in order on a single WCF channel. A Duplex WCF channel does NOT give you two incoming message queues. The results coming back from a “TwoWay” call are just the same as the “call” as this level of the WCF stack. Once you get your head round this a lot of the problems become clearer to understand.
If the client is WinForm or WPF, you may need to use
[CallbackBehavior(UseSynchronizationContext = false)]as otherwise the client will not process the incoming message until the UI thread enters the message loop.Some rules I found to help avoid deadlocks. (Look at my WCF questions to see the pain I had!)
And/or
The next time I think I will just use two contracts (and hence TCP connections) one for the callback and other for all client->server requests. Or use my own polling system, as this gave me so much pain.
Sorry I don’t have time today to write an example. Anyway most examples work for what the example is trying to do, but break down in real life for some reason to do with your application.
The best web site I know for WCF examples is Juval Lowy’s web site.
Your may also find the questions I asked about WCF on Stack Overflow useful, as I was having the same kind of problems as you.
Also spending a day or two reading all the WCF questions and answers on Stack Overflow will give a good idea of the problems to avoid.
If you are going to be developing with .NET, use WCF for your interprocess communication. WCF greatly simplifies development because the intricacies associated with a specific communication mechanism (e.g., sockets, pipes, etc.) are abstracted behind a unified programming model. Thus, it doesn't matter if you choose to use http, tcp, or named pipes for your transport mechanism, the programming model is the same.
I would highly recommend Juval Lowy's book Programming WCF Services for all things WCF. You can also visit his website, IDesign.net, for free WCF code samples.
For an overview of WCF, watch this free video at dnrTV. It covers the purpose of WCF and demonstrates WCF programming through some easy-to-follow examples.
If you have not already created your Windows service but plan to do so in C#, you can follow the step-by-step here.
Edit: Reflecting More comments
A primer on WCF (such as What Is Windows Communication Foundation?) is a good place to start. WCF can use SOAP to implement the contracts way down deep. WCF also uses a variety of communication facilities within windows (and any custom ones you want to create) so talking across machines is built in.
The very essence of contract (IMO) implies that this is present on both sides of the communication. In a pure .net cases I've usually put the contract definitions in separate assemblies and share them. In other places I've used WSDL to be the main contract definition so that the client and service share definitions.
Edit: Answering comments
You can knock up simple examples of communication in WCF easilyy (provided you know the basics of comms on windows including firewalls etc). However doing something custom is not easy but there are many many resources on the web and books to help you get there.
The books i used:
Another question on SO with a set of resources is "WCF for the Totally Clueless"
I don't know all answers but here are the ones I do know
And the questions certainly aren't stupid.
P.S. I can recommend the book programming WCF services by Juval Lowy it's really in depth and comes with a really useful framework extending WCF/Simplifying certain things.
Yes, scopes are the way to go. I'd like to recommend to you a great article Discover a New WCF with Discovery by Juval Lowy (the author of the Programming WCF services book). Here's the direct quote on using scopes:
This fits very well with the kind of problems you want to solve.
The article also contains good samples on declaring scopes both in configuration and in code. From service consumer's point of view I see two options: you can stuff all your desired scopes in
FindCriteriainstance that you pass to theDiscoveryClient.Findmethod if you want to filter your services on the discovery stage or you can get all services and check their scopes by hand.Scope itself is an
Uriobject so it can put a lot of different information there using "key=value" notation. That should take care of "extending" the scope filtering and it doesn't limit you in terms of forward compability.