I just started learning on WCF and is trying to create a WCF service for my client application.
From the msdn tutorial, I have went through all the individuals steps and sort of grasp how WCF works and now I am trying to start coding the service on my part. For the first step it says, defining a service contract. and the sample code msdn gives are as follows
namespace Microsoft.ServiceModel.Samples
{
class Program
{
static void Main(string[] args)
{
}
}
}
and the service contract.
[ServiceContract(Namespace = "http://Microsoft.ServiceModel.Samples")]
what i would like to ask is, what can i actually substitute the namespace with since I am developing for my own application?
The namespace can be a string - typically it's a URI, like in your question, but it could also be a simple dotted namespace
[ServiceContract(Namespace = "Microsoft.ServiceModel.Samples")]
Contract namespaces are just strings to resolve possible conflicts (can be useful when versioning, for example). If you omit it your WSDL will contain http://tempuri.org. Not what you want in production. However, it's not that easy to just set proper name in ServiceContractAttribute, there are also binding and schema namespaces. For better understanding WSDL namespaces in context of WCF I highly recommend this blog post.
Related
Need help on an issue I am having. I inherited this WCF RIA project and am trying to understand a couple of things.
When I publish the project, how does the WSDL get generated and put on the URL that I published to?
And I want to incorporate FaultException handling so as to transmit the exceptions to the client side. I read some stuff regarding the FaultException on the web and was able to get a small sample working with the regular WCF service.
I thought it would be similar within my actual project. But unfortunately I am running into some issues(probably due to my lack of WCF + RIA services knowledge).
So in my actual project my Context class derives off of LinqToEntitiesDomainService.
I created a new ContextFaultException class which had some methods to capture some custom error messaging.
Then I applied the [FaultContract(typeof(ContextFaultException))] to some of the methods in my Context class. Everything compiles and all is fine. But when I published to a website and then when I added this service reference to the client, I don't see my new ContextFaultException in the Reference.cs file that's generated.
I thought may be moving it within the Context class will solve the issue. So I made my ContextFaultException class as an inner class of this Context class but I am running into some other issues. Before I try to figure out these issues, I just want to know if this the right approach?
Any suggestions/pointers??
TIA
The URL must be formatted to get to the namespace wdsl
for example:
namespace My.Namespace.Services
{
[EnableClientAccess()]
public partial class MyClassName : LinqToEntitiesDomainService<XXX>
{
....
}
}
Then use the following pattern for the url
http://YOURHOST/APP/Services/My-Namespace-Services-MyClassName.svc?wsdl
Use "-" for the "."
I used to code only in databases enviroments. Recent changes in the corp. made me start developing in whole new worlds.
This new project is something like SQL - C# - PHP.
The class I've been working on in VS2008 is almost dnoe. It calls all the SQL SPs I need and the info is there in the DataReaders.
When It came to read that info from PHP so I could populate the website I found out it wasn't that easy. I was recommended into trying several options, the one that suits the best for the project is to create a Web Service and then consume it (please be patient, As I just stated I'm new to most web related programming)
So, I'm trying to WCF/Rest and then consume it from PHP but I haven't got there yet.
I've read and watched several tutorials on WCF and It seems to be smooth, but all I've read is:
. Create Interface with its OperationContracts.
. Create Service with DataMembers etc and define the Methods listed in the Interface.
Ok, but what I'd like to do is not to specify any methods there, since all I want is to call C# method I've already written.
Should I do that in the Service or in the Interface? And first of all, is this the right the way to approach it?
You would want to write service methods that implement an operation contract interface. The service methods can call the C# code that you've already written.
For example, here is a simple service interface:
[ServiceContract]
public interface IYourService
{
[OperationContract]
int GetCountOfTransactions(string filter);
}
And then you would implement this interface in your service class:
public class YourService : IYourService
{
public int GetCountOfTransactions(string filter)
{
// Call your existing code
YourClass yourClass = new YourClass();
return yourClass.GetCountOfTransactions(filter);
}
}
There are plenty of examples out there for setting this up as a REST service, but I think you're on the right track.
The trickiest part is usually setting up the binding configuration to make sure all of your consuming client applications can connect.
Hopefully this helps.
Thanks for the quick answers all. But I am looking for an answer and not a workoaround (serialize as string) as I want to know how to use other types from the framework
I am fairly good at WCF but I think I am still at the beginners stage since I cannot serialize a System.Drawing.Color.
This is my Service Contract
using System.Drawing;
using System.ServiceModel;
namespace wcfServer
{
[ServiceContract]
public interface IColorService
{
[OperationContract]
Color DoWork();
}
}
And here is an implementation
public class ColorService : IColorService
{
public Color DoWork()
{
return Color.Yellow;
}
}
However, at the client WCF doesn't use a System.Drawing.Color but it generates it own color type (a struct) ?
The net result is that the color Yellow does not arrive at the client
I thought that this wasn't a problem since the .net Color type is marked with the serializable attribute
Kind Regards, Tom
Colors are usually a mess - there are so many of them. Just convert to color to a 32-bit ARGB structure (the Color class has a method that does this) and use that in your WCF interface. If you want to be extra careful, define your own struct with A, R, G and B (as bytes, WPF has them as doubles, but nobody really needs that), and decouple your service from any specific UI platform.
However, at the client WCF doesn't use a System.Drawing.Color but it generates it own color type (a struct)? [...] I thought that this wasn't a problem since the .net Color type is marked with the serializable attribute
I'm assuming you use basicHttp or wsHttp here. What I'm saying doesn't go for all bindings.
Communication between a WCF service and client has nothing to do with .NET. Keyword is interoperability. The client doesn't have to be written in .NET, it might very well be a PHP or Java or whatever kind of client.
WCF therefore uses SOAP to send and receive data, which all major programming languages implement. So to let a service and client exchange data, a format for that data has to be defined. You can't say "Hey, I'm gonna send a System.Drawing.Color", since that may very well not be a valid class or struct definition in the client's language.
So your service defines a WSDL, containing a schema definition, where the contents of the Color struct will be copied from System.Drawing.Color. It won't be linked to the .NET framework from the point it gets serialized and sent over the wire.
I was able to fix this problem by using "KnownTypeAttribute" on a data contract. So you can try "ServiceKnownTypeAttribute" on a service contract like this :
[ServiceContract]
[ServiceKnownType(typeof(System.Drawing.Color))]
public interface IColorService
{
[OperationContract]
Color DoWork();
}
This works fine assuming that the client code is also using .NET.
The strategy with "KnownType" worked well in my project http://www.nquotes.net/ and let me avoid additional serialization hassle. They should have included Color as one of the base types (as they do with Guid, for example, which is "known" automatically - http://msdn.microsoft.com/en-us/library/ms731923.aspx ).
So far I found that MEF is going well with presentation layer with following benefits.
a. DI (Dependency Injection)
b. Third party extensibility (Note that all parties involved should use MEF or need wrappers)
c. Auto discovery of Parts (Extensions)
d. MEF allows tagging extensions with additional metadata which facilitates rich querying and filtering
e. Can be used to resolve Versioning issues together with “DLR and c# dynamic references” or “type embedding”
Pls correct me if I’m wrong.
I'm doing the research on whether to use MEF in Service layer with WCF. Pls share your experience using these two together and how MEF is helping you?
Thanks,
Nils
Update
Here is what my result of research so far. Thanks to Matthew for helping in it.
MEF for the Core Services - cost of changes are not justifying the benefits. Also this is big decision and may affect the service layer in good or bad way so needs lot of study. MEF V2 (Waiting for stable version) might be better in this case but little worried about using MEF V1 here.
MEF for the Function service performs - MEF might add the value but it’s very specific to the service function. We need to go deep into requirement of service to take that decision.
Study is ongoing process, so everyone please share your thoughts and experience.
I think any situation that would benefit from separation-of-concerns, would benefit from IoC. The problem you face here is how you require MEF to be used within your service. Would it be for the core service itself, or some function the service performs.
As an example, if you want to inject services into your WCF services, you could use something similar to the MEF for WCF example on CodePlex. I haven't looked too much into it, but essentially it wraps the service location via an IInstanceProvider, allowing you to customise how your service type is created. Not sure if it supports constructor injection (which would be my preference) though...?
If the WCF service component isn't where you want to use MEF, you can still take advantage of MEF for creating subsets of components used by the service. Recently for the company I work for, we've been rebuilding our Quotation process, and I've built a flexible workflow calculation model, whereby the workflow units are MEF composed parts which can be plugged in where needed. The important part here would be managing how your CompositionContainer is used in relation to the lifetime of your WCF service (e.g. Singleton behaviour, etc.). This is quite important if you decide to create a new container each time (container creation is quite cheap, whereas catalog creation can be expensive).
Hope that helps.
I'm working on a solution where the MEF parts that I want to use across WCF calls are stored in a singleton at the application level. This is all hosted in IIS. The services are decorated to be compatible with asp.net.
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
In Global.asax, I import the parts.
[ImportMany(typeof(IOption))]
public IEnumerable<IOption> AvailableOptions{ get; set; }
After initializing the catalog and container, I copy the imported objects to my singleton class.
container.ComposeParts(this);
foreach (var option in AvailableOptions)
OptionRegistry.AddOption(option);
EDIT:
My registry class:
public static class OptionRegistry
{
private static List<IOption> _availableOptions= new List<IOption>();
public static void AddOption(IOption option)
{
if(!_availableOptions.Contains(option))
_availableOptions.Add(option);
}
public static List<IOption> GetOptions()
{
return _availableOptions;
}
}
This works but I want to make it thread safe so I'll post that version once it's done.
Thread-safe Registry:
public sealed class OptionRegistry
{
private List<IOptionDescription> _availableOptions;
static readonly OptionRegistry _instance = new OptionRegistry();
public static OptionRegistry Instance
{
get { return _instance; }
}
private OptionRegistry()
{
_availableOptions = new List<IOptionDescription>();
}
public void AddOption(IOptionDescription option)
{
lock(_availableOptions)
{
if(!_availableOptions.Contains(option))
_availableOptions.Add(option);
}
}
public List<IOptionDescription> GetOptions()
{
return _availableOptions;
}
}
A little while ago i was wondering how I could create a WCF web service that will get all of its dependencies wired by MEF but that i wouldnt need to write a single line of that wire up code inside my service class.
I also wanted it to be completely configuration based so i could just take my generic solution to the next project without having to make code changes.
Another requirement i had was that i should be able to unit-test the service and mock out its different dependencies in an easy way.
I came up with a solution that ive blogged about here: Unit Testing, WCF and MEF
Hopefully will help people trying to do the same thing.
I'm creating a service reference to a web service written in Java. The generated classes now follow the Java casing convention used in the web service, for example class names are camelCase rather than PascalCase.
Is there a way to get the desired casing from the service reference?
CLARIFICATION:
With WSE based services, one could modify the generated Reference.cs to provide .NET standard casing and use XmlElementAttribute to map to the Java naming presented by the external web service, like this:
[System.Xml.Serialization.XmlElementAttribute("resultType", Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]
[System.Runtime.Serialization.DataMember]
public virtual MyResultType ResultType
{ ... }
Not terribly maintenance-friendly without writing custom code to either generate the proxy code or modify it after it's been generated.
What I'm after is one or more options to present a WCF generated client proxy to calling applications using the .NET casing conventions, achieving the same as I did previously with WSE. Hopefully with less manual effort.
Well, since your WCF client proxies are partial classes, you could always add a second file for the same class, which implements the PascalCasedMethodName for each javaCasedMethodName and then just call the Java method from your new method.
public partial class MyClientProxy
{
......
public MyResultType GetResultType(string inputParam)
{
return this.getResultType(inputParam);
}
......
}
Seems a bit redundant - but that should really work, I think. Since your code is stored in a separate file, it won't be overwritten if you re-create the client proxy - and since it's the second part of a partial class, it will be "merged into" the class definition for your client code to call.