I want to find out whether or not WCF service is platform independent. That is, can WCF service receive requests from other platform, like Java? If it can, Does abstract class in WCF work for other platform. For example, can the code below work for other platform?
-- This is only example
[ServiceContract(Name = "Service1")]
public interface IService1
{
[OperationContract]
[ServiceKnownType(typeof(Retangle))]
[ServiceKnownType(typeof(Square))]
string GetShape(Shape shape);
}
[DataContract]
public abstract class Shape //is abstract interoperable by other language
{
}
[DataContract]
public class Retangle:Shape
{
}
[DataContract]
public class Square : Shape
{
}
http://localhost:10287/Service1.svc
Thanks
A Qualified Yes, WCF if used with standard transport and message protocols like SOAP, JSON, REST, HTTP/S is highly interoperable with other platforms and languages. In practice the compatibility will vary depending on the language and platform as also the level of WS-* protocols being used if you are using SOAP.
In your specific case using KnownType works with Java and I can vouch for it as we use it in our enterprise WCF app consumed by a Java client. The Java stack we have used is Metro and the IDE is Netbeans.
You can always try with SoapUI which is a generic SOAP client written in Java to consume your WCF service and test if it works.
Related
One guy explained this way but not very clear to how to implement it.
From experience:
Using different binding, for example one BasicHttpBinding for Java clients while using WsHttpBinding for .NET clients. Also HTTPS for some and HTTP for others...
Dividing and exposing different contracts/interfaces. For example you have one interface that exposes many operations and you have a cut down interface which does basic things and you publish the second to outside so internal clients use the endpoint for extended interface but external clients use the other one.
For example
interface IFoo
{
void DoBasic();
}
interface IFooInternal : IFoo
{
void DoMore();
}
Now you have One class implementing both:
public class Foo : IFooInternal
{
....
}
And now you expose only one to outside while implementation is in the same class.
the things which i do not understand how to design my service contract in such a way that few operation i will expose to other client and extended feature i will expose to internal client. so if possible just make me understand giving me a small program & code that how it can be possible through multiple endpoints in WCF service. thanks
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.
We have already Business logic layer available in our application. It has lots of classes. and this is in separate library(.Dll). Now we want to use this in to our WCF Service. For that We create new project and gave reference to that .Dll. But we are not able to see our class .. I verify that class is public..
Could you please let me know what should I do?
Here I am attaching my code what I need to do
My Business Layer class
namespace BusinessLayer
{
public class MessageContext : Dictionary<string, object>
{ ....}
}
Now I am reference this Project to my WCF project and tried to expose this class into WCF client. So I Create one MessageContextHelper class which inherit from MessageContext the code is following
namespace WCFService
{
public class MessageContextHelper : MessageContext
{ ...... }
}
On client I am not able to get MessageContextHelper class.
Thanks
JK
WCF doesn't send business logic classes to the client. If you're using the SOAP version of WCF (BasicHttpBinding for example) then what WCF will expose is methods that are in your service contract. Your client can call those.
So if you have methods in a business logic class that you want exposed, create methods in your WCF service that will in turn call the business layer methods.
A very rudimentary (and not complete) version would look something like this:
namespace WCFService
{
public class MyService: IMyService
[OperationContract]
public String DoSomeStuff() {
return MessageContext.DoSomething();
}
}
You absolutely cannot (and should not) use your business layer from your client code. As the previous reply message, WCF does not send your business class to the client. Think about how long it will take to send. The business layer (your dll) should be used on the server only. Your WCF should only accept modified/new data from the client, pass the data to the business layer, and then return the results to the client.
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.
I'm working on a Windows Phone 7 app using WCF for communications with my server.
I've created a service and am able to communicate well, but I'm having trouble accessing an interface in the client code.
For instance, in my server code I have something like this:
[OperationContract]
[ServiceKnownType(typeof(IField))]
[ServiceKnownType(typeof(TextField))]
[ServiceKnownType(typeof(NumberField))]
FieldForm GetForm();
Now my FieldForm contains the following declaration:
[DataContract]
class FieldForm
{
public List<IField> Fields { get; set; }
}
And finally, this IField interface has a few implementations:
interface IField
{
string Name { get; set; }
}
[DataContract]
class TextField : IField
{
}
[DataContract]
class NumberField : IField
{
}
(this isn't my code, but describes what I'm trying to accomplish)
Now on my client, I receive a FieldForm object via WCF and want to iterate through the Fields list to determine what UI elements to create. Problem is, the service did not provide the IField interface on the client, but I do have the implementations available (TextField and NumberField).
This leads to some crappy code in my client code like:
foreach ( object field in Fields )
{
if ( field is TextField )
// do textfieldy stuff
else if (field is NumberField)
// do numberfieldy stuff
}
when I'd really prefer to just use:
foreach ( IField field in Fields )
{
field.Name;
}
Am I missing a simple annotation on the interface in order to make the interface type available on the client, or does WCF simply not provide the ability to serialize interfaces?
Is there a way I can access my interface in my client code?
No you cannot serialize an interface across a WCF connection.
WCF uses serialized (XML) messages to communicate between client and server - all you can express in XML schema (XSD) can be moved across. This basically means any concrete type, composed of atomic types like int, string, etc.. XSD also supports inheritance and enums, but that's about the end of the flagpole.
What you might be able to do if you control both ends of the communications link (e.g. both server and client) is to put those interfaces (service interfaces and your data contracts and interfaces) into a common, shared assembly which both your client project and server project would then reference. Use any class implementing your interface in the concrete service implementation, but with this assembly sharing, you can use the signature you like on the client side and program against an interface. Mind you: this "kills" all interoperability of your WCF service - no Ruby or Java clients will be able to call your service anymore.