In my WCF service I use Unity to resolve my services and their dependencies.
When registering types I want to give some types the lifetime of the request. Is there any well known and "correct" implementations of a PerRequestLifetimeManager?
Related
I have been googling for quite some time now but cannot find a definite answer.
I want to consume a wcf service, whose address will be provided at runtime.
The user will enter the address of the wcf service at runtime.
During compilation I have no idea of the service contract or the data contract or the endpoints of the wcf service.
Could someone please let me know how to achieve this requirement ?
This was the original idea behind UDDI. Before making a call, the client would query some central repository and obtain the address, contracts, and bindings of the service endpoint. It would then use this information to assemble and call the channel.
Some ESBs work on this principal - the call to UDDI can also be logged centrally, so an audit is kept of all service calls made within the enterprise.
Microsoft implemented it's own UDDI server which can be integration into SCOM for this purpose.
Im doing a client server application. The server part is implemented with a WCF service. The WCF service exposes data types via service contract. The client is modularized and uses MEF for DI. In the client I have a infrastructure module that references the WCF service. The infrastructure module knows about the WCF data types. My question is , is it possible to let the other modules that references the infrastructure to know about these data types without adding a reference to the WCF service in every module. Is there any way of of exposing the WCF data types
Normally, you have a contract dll. This contract dll contains the service interface and all dependent classes. Your WCF service and any client component will then reference this contract assembly.
As the contract assembly only contains interfaces and POCOs (Plain Old CLR Object, only data, not methods or logic), it can be referenced from virtually anywhere without giving away anything about your infrastructure.
nvoights answere is probably the correct one here however it is also worth mentioning that if you control both server and client then you can if you want put common objects in a dll consumed by both and ignor the WCF generate types. In some senarios that works out better than managing both the server types and the WCF generated equivalent types.
I am developing a solution with multiple WCF services which all communicate among themselves, even though they are of different types. The services connect to one another through the ChannelFactory generic interface, and every service is hosted inside a ServiceHost.
My question is if it would be correct to use a callback contract among the servers to communicate with one another and if so how would such a solution look.
Currently I don't like the implementation because every service needs to host a couple of endpoints with different interfaces some for other services and some for other clients.
When I tried to implement the callback contract inside a service class that was hosted inside a ServiceHost it failed.
First of all, whenever you post a question saying, "it failed", you need to tell us in what way it failed. If there was an exception, then you need to post the entire exception, including all InnerException instances, by posting the result of ex.ToString().
To your problem, I'd implement a service contract that represents the part of each service that needs to talk to the other services. There would also be a callback contract associated with this service contract.
That way, it's as though each service operates a miniature service intended only for service-to-service communications. They can then each do their own thing with the information that is passed between the services.
So I already have a working implementation of StructureMap with the WCF service (including custom instance provider, behaviors, etc.)
When I try to have an object that is instantiated only once per user request, I use the InstanceScope.HttpContext and it throws because the context is null.
Do anyone have a proper way of doing that?
On the server-side of the WCF service? By default, WCF has nothing to do with ASP.NET and thus all your HttpContext etc. aren't there.
By default, your WCF services will be called on a "per-call" basis, e.g. each request gets a brand-new, separate, totally isolated instance of your service class. Why not just put those things into the service class as internal fields??
Or you might want to check out this blog post on how to abstract request state and providing sample implementations for ASP.NET (using HttpContext.Items) and WCF.
I am learning WCF,one of the benefits of WCF is that you can use WCF even the client and service are not in the same network.Can anyone explain why?
Why using normal asp.net services, .NET remoting or Windows enterprise service client and service have to be in the same network?
Another question is that does the client needs to have a service contract interface and data contract? I assume not ,but how the client understand the type returned from the WCF services?
Edit: Reflecting More comments
A primer on WCF (such as What Is Windows Communication Foundation?) is a good place to start. WCF can use SOAP to implement the contracts way down deep. WCF also uses a variety of communication facilities within windows (and any custom ones you want to create) so talking across machines is built in.
The very essence of contract (IMO) implies that this is present on both sides of the communication. In a pure .net cases I've usually put the contract definitions in separate assemblies and share them. In other places I've used WSDL to be the main contract definition so that the client and service share definitions.
Edit: Answering comments
You can knock up simple examples of communication in WCF easilyy (provided you know the basics of comms on windows including firewalls etc). However doing something custom is not easy but there are many many resources on the web and books to help you get there.
The books i used:
http://www.amazon.com/Programming-WCF-Services-Juval-Lowy/dp/0596526997
http://www.amazon.com/Essential-Windows-Communication-Foundation-WCF/dp/0321440064/ref=pd_bxgy_b_img_c
http://www.amazon.com/Inside-Windows-Communication-Foundation-Developer/dp/0735623066/ref=sr_1_1?ie=UTF8&s=books&qid=1252111759&sr=1-1
Another question on SO with a set of resources is "WCF for the Totally Clueless"
I don't know where you read that a benefit of WCF is that it allows the client and server to be on different networks. They can already be on different networks using .NET Remoting or DCOM (Enterprise Services).
The client does need to know the service contract and any other contracts required in order to use the service. This can be provided through WSDL or the Metadata Exchange Protocol (mex). If using .NET on both sides, then it is possible to share the contract assemblies, but this introduces a coupling between client and service.
Previous Microsoft technologies were designed for some specific needs in particular environment. For example ASMX Web Services were designed to send and receive messages using SOAP over Http only. .NET Remoting specific to Microsoft environment, no interoperability. But WCF is designed to send and receive messages using any format (SOAP as default) over any transport protocol i.e. HTTP, TCP, NamedPipes, MSMQ etc.
And your second question "but how the client understand the type returned from the WCF services?"
Its through proxy, client interacts with proxy which contains all the types etc.
You can find a good concepts and questions here for understanding WCF core concepts.