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.
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
We are developing a WCF service for internal company use. The entities (data contracts) are in a separate assembly and are referenced by both the service and applications that consume the service.
Is there any need to implement the IExtensibleDataObject interface?
No. IExtensibleDataObject (IEDO) is used if you expect your contract to receive (e.g., in a service call) more data than is listed in the data members. If you have the same assembly on both client and service this will not be the case.
For a more detailed description of the scenarios where IEDO is useful, check the post at http://blogs.msdn.com/b/carlosfigueira/archive/2011/09/27/wcf-extensibility-other-serialization-extensions.aspx.
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.
I'm developing a service oriented architecture for an application and I would like the services to be exposed both over WCF as well as usable through a simple library. Ideally I would like to reduce duplicated code.
Conceptually, this maps to:
Client => WCF Service => Service Library (actual implementation)
or
Client => Service Library (actual implementation)
based on where the client is located (local or remote).
Here's a simple example:
[ServiceContract]
public interface ICalculator
{
[OperationContract]
int Add(int a, int b);
}
public class Calculator : ICalculator
{
public int Add(int a, int b)
{
return a + b;
}
}
public class CalculatorFactory
{
public static ICalculator CreateCalculator()
{
return new Calculator();
}
}
And my client application did the following
int result = CalculatorFactory.CreateCalculator().Add(1,2);
or
int result = IChannelFactory<ICalculator>().CreateChannel().Add(1,2);
depending on if it were local or remote.
Is it a bad practice to call into WCF annotated code directly (i.e., without using WCF)?
Additional comments:
I realize that I could use WCF in all cases and just host the service using NamedPipes for local connections. I would like to avoid this if I can for simplicity sake.
The alternative to the above is to essentially duplicate the ICalculator interface in the service library and change the WCF service implementation to contain CalculatorFactory.CreateCalculator().Add(1,2). This seems like a lot of overhead given that I want the interface to be the same.
You can create and consume WCF annotated classes localy without any problems unless you start to use some WCF related features like OperationContext etc.
Generally this is useually abstracted in different way:
Client => ServiceAgent => Business Service
or
Client => ServiceAgent => WCF Service => Business service
The client itself doesn't know if the service is local all remote. The service agent is client side component which based on its implementation either creates local service instance or callse remote WCF service which in turn creates business service instance. ServiceAgent can be injected as dependency into client which will make your application pretty good configurable. Also you can expose different interface on the service agent (the same as business service implements) and if you want WCF service and proxy can use different one.
If you decite to use WCF service all the time including local calls don't use NamedPipes. NamedPipes are for inter process communication on the same machince. If you want to use communication in the same process use NullTransport or Local Channel instead. It still has worse performance then direct call.
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.