What is a good way to create a WCF service layer so that a native .Net client application and other client types can talk to the service?
I know, in the future our applicaiton will need to support mobile devices.
We are passing objects into our WCF methods similar to this:
[DataContract]
public class User: DomainBase
{
[DataMember]
public string Username { get; set; }
[DataMember]
public string Password { get; set; }
[DataMember]
public string FirstName { get; set; }
[DataMember]
public string LastName { get; set; }
}
So there may be a method in our servcie like this:
public bool Save(User item){
...do some work
}
public User GetUserByUsernameAndPassword(string username, string password){
...do some work
}
Now, in .Net I can use the same object library as my services, but with other clients I will not be able to. So, if I don't want to write a bunch of differnt methods for each type of client what would be the best way to handle this?
I think interoperability with other clients is more dependent on the binding that the actual contracts. If the other clients and client languages that you will support can do SOAP, then sticking with the BasicHttpBinding provides the best support. For example clients using .NET 2 can still interact with a .NET 3.5 WCF server. There area also SOAP libraries for Java and other languages.
The server can just publish the WSDL, and the clients can then generate all your contract interfaces and types automatically in whatever language from the WSDL. That handles the 'reuse' of your data contract types.
If you want to venture away from SOAP, there are ways to do REST or Plain-old-XML or JSON with WCF, but it gets a lot more complicated from the server side...
What you have now should work perfectly for any other client. What leads you to believe there might be a problem?
It depends on which binding you choose to support. Certain bindings only work with .NET.
BasicHttpBinding: SOAP over HTTP. Any SOAP client can connect
WsHttpBinding: - It is same like
BasicHttpBinding. In short, it uses
SOAP over HTTP. But with it also
supports reliable message transfer,
security and transaction. WS-Reliable
Messaging, security with WS-Security,
and transactions with WS-Atomic
Transaction supports reliable
message.
NetTcpBinding: - This
binding sends binary-encoded SOAP,
including support for reliable
message transfer, security, and
transactions, directly over TCP. The
biggest disadvantage of NetTcpBinding
is that both server and client should
be also made in .NET language.
NetNamedPipesBinding:-Ths binding
Sends binary-encoded SOAP over named
pipes. This binding is only usable
for WCF-to-WCF communication between
processes on the same Windows-based
machine.
Related
So is it that you shouldn't or can't use Interfaces in methods you are exposing or in the DTOs you are exposing to the client in a WCF service? Because if I have this for example:
public class MyCustomDTO
{
public ITransaction Transaction { get; set; }
}
or
IPaymentRequest SendTransaction(PreAuthorizeRequest request);
I notice that when I try to create integration tests to prove that the wsdl can be used and make successful calls, my ITransaction and IPaymentRequest are serialized and exposed through the service client as "object" probably because it doesn't know what kind of object to expose in the contract right?
so is it you can't create methods or DTOs with Interfaces in them as part of the contract you are exposing to the outside world that consumes your WCF service?
If you are using WCF to connect two .NET instances and you share your contracts as a common contract assembly between the two instead of using the auto-generated client from the wsdl, then it works. However, WCF is about interoperability and you may want to add a non-.NET client down the road so you should only use actual types so your service will work well with all the other languages out there.
WCF Newbie alert. I'm reading "Learning WCF" and "Programming WCF Services" where both books recommend throwing FaultException<T>. If T is .NET type "DivideByZeroException" and assuming a FaultContract exists with
[FaultContract(typeof(DivideByZeroException))]
on method "Divide", will a non-.NET client consuming that WCF service and method be able to understand and process that .NET exception? If yes, is it because the type info (DivideByZeroException) is part of the metadata (because of the FaultContract) that the client has access to and uses?
Thanks for any help.
You can throw a FaultContract<DivideByZeroException>, but in general you shouldn't do that, exactly for the reason you mentioned (*). What is usually recommended is to have a data contract with the information from the exception, such as the exception message, and then have a FaultContract of that type.
[DataContract]
public class MyErrorDetails
{
[DataMember]
public string ErrorCode { get; set; }
[DataMember]
public string ErrorMessage { get; set; }
}
And then use
[FaultContract(typeof(MyErrorDetails))]
(*) Another reason to avoid returning exceptions as faults is that they disclose more information to the client than the client needs; things such as the stack trace are serialized by the exception, but that's some information internal to the service and shouldn't be sent to clients.
I have a wcf service secured by ADFS deployed in azure. I am able to consume that service in my console application. But when I am not sure how to consume that service in windows phone 7 application.
In my console application, I am retrieving a security token and passing that token to channelfactory object using CreateChannelWithIssuedToken method. But there is no such method in windows phone app to pass the token to wcf service. Can anyone guide me in this issue?
Thanks in advance.
CreateChannelWithIssuedToken was an extension method added by the WIF assembly in .NET 3.5/4.0 (I believe .NET 4.5 has most of this stuff now built-in to the System.ServiceModel namespace). Since you won't have this on the phone, you're stuck with the regular WCF methods to create and use channels.
This is still the case when working on WinForms/WPF apps, though in that case you have the option of bringing in the WIF assembly. Still, it isn't required, and consuming an ADFS-secured service is perfectly doable with the regular WCF classes.
Windows Phone seems to support this stuff, though with some caveats. Looking at the implementation of the extension method, it doesn't seem like they are doing anything all that fancy really:
public static T CreateChannelWithIssuedToken<T>(this ChannelFactory<T> factory, SecurityToken issuedToken)
{
return ChannelFactoryOperations.CreateChannelWithParameters<T>(factory, new FederatedClientCredentialsParameters
{
IssuedSecurityToken = issuedToken
});
}
public static T CreateChannelWithParameters<T>(ChannelFactory<T> factory, FederatedClientCredentialsParameters parameters)
{
ChannelFactoryOperations.VerifyChannelFactory<T>(factory);
T t = factory.CreateChannel();
((IChannel)t).GetProperty<ChannelParameterCollection>().Add(parameters);
return t;
}
The verify method simply performs some diagnostics and throws exceptions (such as if the endpoint isn't set). ChannelParameterCollection is defined in System.ServiceModel.Channels and is supported in Silverlight/WP7. And FederatedClientCredentialsParameters is nothing special either:
public class FederatedClientCredentialsParameters
{
public SecurityToken ActAs ( get; set; )
public SecurityToken OnBehalfOf ( get; set; )
public SecurityToken IssuedSecurityToken ( get; set; )
}
It seems like you should be able to create a channel and use your token with it normally, even from WP7, though I'm afraid I don't have the exact steps to do so. Maybe someone else does or maybe this leads you in the right direction.
This article shows how to access a WIF-protected WCF service from Silverlight, which I imagine is nearly identical to how you'd do it on the phone.
There is a training kit (http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=8396) example ACSAndWindowsPhone7 that may help here (I've not looked at it in detail). I know that Wade Wegner has a number of blog posts on ACS and WP7, but not sure if he's tackled ADFS specifically versus OAuth type mechanisms.
I am currently developing a C# Windows Form Application that I intend to let it interact with a server. The server will receive posting from a mobile application that I have developed and whenever a posting is received, my Windows Form Application should be notified and give me a notification. And for now I am starting to create a WCF service for it.
This is a sample scenario of what I meant,
E.g. My mobile application sends an message over to my server. Once my server receives the message, my windows form application should display a new notification showing the content of the message received.
so for the operationcontract of the service, what type of methods should i put in in order for me to receive the posting?
e.g.
[OperationContract]
bool receivePosting(int n);
I'm not quite clear as to which direction you want to communicate:
your "server" needs to notify the Winforms app of a new posting that's been saved?
or:
your Winforms app asks the "server" about new postings??
I put "server" in quotes because in WCF world, that's a term being used for a specific role.
Assuming the first option, you need to do this:
your Winforms app needs to be the WCF server - e.g. it needs to define a service contract, operation contract and data contract - and implement those
your "posting server" would be the WCF client in this case; whenever a posting is received/stored, then you would call the WCF service in your Winforms app to send a notification (so really, in this setup, your roles are reserved - the Winforms app is the WCF server)
As for the operation contract - what does your Winforms app need to know about the new posting? Just the fact a new posting has been received? The whole contents of the posting, or just parts of it??
In any case, you need to define a method on your WCF service that the "posting server" can call and pass all relevant info to the Winforms WCF Server - you don't want to have to make two or more calls just for one notification.
So you Service Contract might be:
[ServiceContract]
public interface IPostingService
{
[OperationContract]
void NotifyAboutPosting(Posting post);
}
and your Posting class would be the data contract:
[DataContract]
public class Posting
{
[DataMember]
public int ID { get; set; }
[DataMember]
public string Description { get; set; }
[DataMember]
public DateTime PostingTimestamp { get; set; }
}
Whatever you need to send between those two parties - define it in your data contract which is the argument to your service call
I have a Silverlight application with a Silverlight-enabled WCF service. The service passes along a small POCO class with a few string properties, and a List<> of an enum defined in the class. Everything works fine when running using the ASP.NET development server, but when I move the service over to an IIS server (Windows 2003) I get the following error when I try to browse the .svc file:
Type 'MyProject.Web.MyClass' cannot be
serialized. Consider marking it with
the DataContractAttribute attribute,
and marking all of its members you
want serialized with the
DataMemberAttribute attribute.
Even though it's working development side, I've tried adding the decorations... but so far without effect.
Any ideas as to what might be causing this difference of outcomes between development workstation and server?
Make sure that (1) the .NET Framework 3.5 SP1 is installed on the server and (2) that the website is running in ASP.Net 2.0 mode and not 1.1 mode.
The Web Platform Installer is an easy way to install the updated framework if it isn't already installed.
Your data elements (POCO classes) ought to be marked as DataContracts for WCF, so that WCF knows explicitly what it'll need to serialize to send across the wire.
Contrary to the Xml Serializer, the DataContractSerializer in WCF uses an "opt-in" model - only things that you explicitly mark as [DataContract] and [DataMember] will be serialized - anything else will be ignored.
[DataContract]
class YourPocoClass
{
[DataMember]
private int _ID;
[DataMember]
string CustomerName { get; set; }
public decimal CustomerOrderAmount { get; set; }
}
In this example, from YourPocoClass, you'll have both the _ID field and the CustomerName property be serialized into the WCF message - but the CustomerOrderAmount will not be serialized - public or not.
So, best practice is: explicitly mark all your complex types that you need to send around in WCF with [DataContract] (for the class) and [DataMember] (for each member to be sent across inside that class).
Marc