I'm having a WCF service with wsHttpBinding. The service contract interface is declared with ServiceKnownTypeAttribute as:
[ServiceKnownType("GetKnownTypes", typeof(Helper))]
public interface IService1
The GetKnownTypes method returns a collection of 75 types.
I've tried connecting the service with ServiceKnownType and without ServiceKnownType.
It's causing around 2.3 minutes to connect with ServiceKnownTypeAttribute and less than 1 second without it.
If I don't use ServiceKnownTypeAttribute then I've to write minimum 3 APIs for each class i.e. around 225 APIs :(.. with ServiceKnownTypeAttribute the max APIs I've written are 10, which works excellent.
Can anybody suggest a solution?
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
Trying to really 'get' endpoint contracts:
I understand offering different endpoints to support different bindings, but when would one define n endpoints for a service, and use different contracts? Seems that in most cases (bar IMetadataExchange) the endpoint contract would be the same no matter the protocol, no?
If most of the time the contract would be the same across all endpoints, would it have been too simplistic (and why?) to define the service contract on the parent service instead of on each endpoint (seems cumbersome/repetitive), while alllowing an override on the endpoint for when needed (eg: IMetadataExchange).
Thanks for help with the small questions that keep me up at night ;-)
OK, well - the service that you define in the <service> tag is the actual implementation code - the actual C# or VB.NET lines that make up the service. Therefore, it's a concrete class (which might even implement multiple service contracts). This is server-side only.
The endpoint however is the communications channel between the server and the client, and between those two, you want to share only the contract - never any concrete implementation of that contract. The endpoint will only ever be used for a single service contract - if your concrete service implements multiple contracts, you need to expose multiple endpoints to the clients to provide all that functionality.
Does that make things a bit clearer?
I'm in the process of writing a duplex WCF service using NetTcpBinding, and I've run into an architecture question that I think I know the answer to, but hope that I'm wrong.
Our service is stateful, and we've selected NetTcpBinding with PerSession InstanceContextMode. For various reasons, this is something that we require. I'm trying to break up our larger interface (where large blocks of the operations would not apply to many clients) into multiple smaller interfaces with the operations logically grouped. While it's simple enough to have a single service implementation implement all of the contracts, I'm not sure if it's possible to have multiple service contracts share a single channel (or, more to my requirement, a single session), and I'd definitely need to be able to do that in order to make this work.
I could, of course, include everything on one contract and throw FaultExceptions when an invalid operation is performed, but I'd really like to be able to break these up and not even add an endpoint for inapplicable contracts. Is what I'm looking for possible?
TL;DR Version:
I need to be able to do this:
[ServiceContract]
public interface IServiceA
{
[OperationContract]
void Foo();
}
[ServiceContract]
public interface IServiceB
{
[OperationContract]
void Bar();
}
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)]
public class Service : IServiceA, IServiceB
{
...
}
And be able to establish one session from the client to the service but use both IServiceA and IServiceB.
The default instance provider over a sessionful channel will give you an instance per connection in your case. You can however extend the instance provider to pick up an existing object from your own cache and return the same object.
How you correlate instances will be upto you using some special message header etc. The underlying channel/Connection will be different for each proxy and also use differnt buffers / concurrency models but you can allow service model to use the same instance.
http://msdn.microsoft.com/en-us/magazine/cc163590.aspx
Im trying to consume a WCF service in silverlight...
What I have done is to create two seperate assemblies for my datacontracts...
Assembly that contains all of my types marked with data contracts build against .Net 3.5
A Silverlight assembly which links to files in the 1st assembly.
This means my .Net app can reference assembly 1 and my silverlight app assembly 2. This works fine and I can communicate across the service.
The problems occur when I try to transfer inherited classed. I have the following class stucture...
IFlight - an interface for all types of flights.
BaseFlight : IFlight - a baseflight flight implements IFlight
AdhocFlight : BaseFlight, IFlight - an adhoc flight inherits from baseflight and also implements IFlight.
I can successfully transfer base flights across the service. However I really need to be able to transfer objects of IFlight across the interface as I want one operation contract that can transfer many types of flight...
public IFlight GetFlightBooking()
{
AdhocFlight af = new AdhocFlight();
return af;
}
... should work I think?
However I get the error:
"The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error."
Any ideas would be appreciated.
You say that BaseFlight works; does your base-class name the known types?
[DataContract]
[KnownType(typeof(AdhocFlight))]
class BaseFlight : IFlight {...}
You might also want to look at [ServiceKnownType]. In general, WCF isn't going to like the interface-based approach (IFlight), as it is going to want to know exactly what to expect from the data it is (de)serializing; I would expect it to work fine with the above and using BaseFlight on the API.
I think what you want to do is possible in "normal" .NET WCF. Here is a question that talks about passing interfaces in a WCF service:
Passing Interface in a WCF Service?
But I seriously doubt whether this will work in Silverlight. WCF support in SL is sketchy, to say the least. I haven't tried it though. I might be wrong.
This may or may not be related to a bug with serializing generic interface types in WCF as logged here.
http://connect.microsoft.com/VisualStudio/feedback/details/391260/executionengineexception-thrown-from-datacontractserializer-with-ilist-t
If this is related to your problem you'll be glad to hear that it's fixed in .net 4.0
i have recently been involved in developing a WCF service which acts as a kind of multicast relay (i.e. accepts some incoming data, does some processing and then sends it off to multiple other external services). this service (which i will refer to as "my service") is fed data by a second internal service.
this data is going to be relayed from my service as XML held in a string. therefore my service could simply accept a string as an parameter to a method request - but this is not ideal as we lose type safety.
the second service has a class that encapsulates all of the information which my service requires to be processed, and eventually relayed to the external services.
the second service exposes this class in it's data contract. Ideally, in order to maintain type safety, and without requiring lots of changes to the second service's implementation, i should accept this type of class as an argument to my service operation.
what would be the best way for me to say in my datacontract that i require this type of class without duplicating code? could i add a service reference to this second class, and then use the proxy class which is created in my data contract?
i just can't get my head around this, even though it seems like a trivial problem!
cheers for any help!
If you are trying to avoid duplication of classes, put your class declaration in its own assembly and share that dll between all parties in the WCF Service. When you create your service reference you can choose which assemblies are shared (assuming you use the VS GUI service utility).
The use of a proxy class might be a good avenue as well. If you expose your main data class as a data contract, then create a proxy of that, the proxy will have a version of the exposed class that can be used by your other services.