I am building a set of WCF services that share common data contracts (or entities if you prefer). These are simple data transfer objects that are decorated with DataContract and DataMember attributes. I am explicitly specifying the name and namespace. In trying to follow the principles of IDesign's recommendation of averaging 12 members per service contract, I am breaking my service project into multiple services.
My data contracts are in a separate assembly that I can provide to our clients if they are using .Net. They can tell their service reference to reuse types in referenced assemblies. However, if they are not using .net and they use 2 services that both use the same entity then they will, I assume, get an ambiguous reference message. I can see this in Visual Studio if I don't reference the data contract dll.
My question is, is there anything I can do in my services, or they can do in a client app to get around having to qualify which proxy the data contract came from?
Nice article that describes how to solve this issue.
Sharing DataContracts between WCF Services
I also tend to keep all my Data Contracts in one assembly which is referenced by multiple services and numerous client apps, which works great but I've never tried consuming the service outside of .NET.
It might be helpful to know what technology they are using to consume the service other than .NET? What is throwing the ambigious reference message?
I happen to have multiple services that share objects on my end. I am not certain why you are having this problem. In my case, I am able to access the objects in this way. . . .
SERVICE1 client = new SERVICE1()
client.CommonLibrary.Address. . .
SERVICE2 client2 = new SERVICE2()
client2.CommonLibrary.Address . . . .
It depends on what tools they are using on the client side. For instance, with Axis2 for Java the wsdl2java tool can share types by using the -u switch.
how can I share proxy objects across multiple Axis2 web service clients?
From my understanding and working with WCF, either one of the data contract used by the client app would not matter as long as the fully qualified name is the same and has the same data members. Internally it just create the object dynamically and reassign those data member property using the public setter.
A better approach I think is to refactor your data contract so that you will put all the common across more than one service into one assembly and refer to them hence you will not have this ambiguious or conflict issues regardless how many services are used by the client app.
We generate our service proxies not through the Visual Studio assistant but by custom batch files calling slsvcutil.exe (as we use Silverlight). There you can specify a namespace mapping using the /n parameter like this:
"C:\Program Files (x86)\Microsoft SDKs\Silverlight\v5.0\tools\slsvcutil.exe "^
http://ServiceUrl/MyService.svc^
**/n:http://youruri.org/CustomerService/DataContracts,CLR.Namespace.CustomerService^**
/n:*,CLR.Namepsace.MyService^
/r:"%ProgramFilesFolder%\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0\System.Windows.dll"^
/ct:System.Collections.ObjectModel.ObservableCollection`1^
/edb^
So all data contracts having the namespace http://youruri.org/CustomerService/DataContracts are generated to the clr namespace CLR.Namespace.CustomerService in the proxy file and so on. Given you have generated this proxy in advance in the same proxy assembly, you can cut this whole namespace out of your second file and everything works fine - we wrote a small tool for the last step. All other contract namespaces will be generated to the CLR.Namepsace.MyService namspace (see the asterisk meaning catch all)
The process is some hazzle to set up because you have to hand craft the batch files, but once this is done it works well.
Related
I went through many posts but, i did not able to clear my some of basic doubts related to WCF service as follow:
Why should we keep separate class library projects assembly for Service.Contracts and Service.Implementation ?
we can implement one interface multiple times even it in single assembly.
It suppose to create - WCF Application project and maintain interfaces into separate folder and SVC.cs file separately.
Add service reference is not good option as it adds all the schemas into client side.
svcutil.exe is also do same thing. Then, what is the best way to consume wcf service at client side ?
All is explained in this great article - WCF the Manual Way…the Right Way.
Essentially, Add Service Reference and svcutil just lead to client proxies that become out of date over time; and the fact that the solution has multiple types defined for what are essentially the same class.
Update: Since writing this answer I have learnt not to have answers in another castle so I update below:
Essentially, WCF the Manual Way…the Right Way describes that rather than using Add Service Reference, you instead divide your WCF system into separate dlls for:
Contracts
Service implementation
Roll-your-own client proxies
Both the service and client add normal code references (not service references) to the contracts dll.
In this way, the service and client are using the same types (and not code-generated ones in the client) and when the contract changes - both the service and client are forced to update less a compile error appears. No more out-of-date clients.
Setting: I'm developing an intranet tool set for my department, the main point of which is to centrally manage data quality and accessibility, but also to automate and scale some partial-processes.
Problem: I currently have my business logic in a CLR assembly, which is available on my SQL-Server for other CLR assemblies that run automated ETL directly on the SQL-Server. I am also developing an intranet site, which also needs the code information in that business logic assembly, but referencing the CLR assembly code has been working out sub-optimally, in terms of deployment and code maintenance. Also another department has voiced interest in using the code-base and data for their own intranet site.
Question(s): I've read quite a few Q&A(1,2,3,4,...) on SO to this topic, but I find it a very encompassing, so I'll try to ask questions for a more specific case(i.e. a single BL and Data Access code base)
Is a WCF service the solution I want? All my potential service clients run on the same server, is there maybe another way to reference the same code base both in CLR assembly and website projects? I don't need support for different platforms(ex. Java) - everything is .NET(yay for in-house progr!) - is WCF overkill?
Can code from a WCF service be used like a class library, or do I need to program a new way for accessing classes/methods from the service?
Separation of Development, Test and Productive instances?
Can a WCF service be updated while clients are accessing it, or do I need to schedule maintenance windows? When I update the service, do I need to update the client as well in some way?
Can I dynamically set the service reference, like I currently am dynamically setting the database connection string, depending on if StageConfig = dev, test, or prod?
My CLR assemblies are written for .Net 3.5, but the websites for .NET 4.0, will that pose a problem?
What minimum set of .NET service architecture programming do I need to know to accomplish this? I'll learn more about WCF with time, but I need to evaluate architecting effort and weigh it against getting things done(feature requests). Does the MS tutorial get me the desired skill?
I appreciate answers to only single questions, if you feel you know something, I'll +1 whatever helps me get closer to a complete answer.
OK, so you want to make your code enterprise-wide. There are two fundamental problems to talk about when you want to do this, so I'll structure the answer that way:
You have to understand what WCF is all about.
You have to manage your dependencies correctly.
What WCF is about
WCF is a way of doing RPC/RMI (Remote procedure call/remote method invocation) which means that some client code can call code that is located somewhere else through the network.
A callable WCF service is determined by the ABC triplet:
The service specification is implemented as a .NET interface with a "ServiceContract" attribute. This is the Contract ("C")
The "location" of the service is determined by a pair : Address ("A") and Binding ("B"). The Binding determines the protocol suite to be used for communication between client and server (NetPipe, TCP, HTTP, ...). The Address is a URI following the scheme determined by the Binding ("net.pipe", "net.tcp", "http", ...)
When the client code calls a WCF service at a specific Address, with a specfic Binding, and a specific Contract (which must match what the server at the specific Address and the specific Binding is delivering), WCF generates a proxy object implementing the interface of the contract.
The program delivering the service is any .NET executable. It has to generate one or many WCF Hosts, that will register objects or classes that implement the service contract, and asociate each delivered service to a specific Address and Binding. (possibly many thereof)
The configuration can be through the app .config file, in which you will be specifying ABC triplets and assotiate these triplets with a name that you will use in your application. You can also do it programmatically, which is very easy.
WCF does not address your problem of deploying your application, or the configuration of addresses and binding. It just addresses the problem of letting two executables communicate with each other with strongly-typed objects (through a specific interface). Sharing the service configuration is up to you. You may use a shared .config file on a Windows share, or even set up a LDAP server that will deliver all the data you need to find your service (namely A and B).
Managing your dependencies correctly
In your scenario, there are three actors that want to use your WCF infrastructure:
Your SQLCLR assembly, which will be a client.
The intranet site, which will be another client.
The service host, which will be a server.
The bare minimum number of assemblies will be 4. One for each of the aforementioned actors, and one specifying the contract, which will be used by all three actors. It should contain the following things:
The interface specifying the contract.
All types needed by the interface, which will of course be sent through the network, and therefore must be serializable.
There should be nothing more in it, or else, it will be a maintenance nightmare.
Answer to your questions
I hope that my answer is clear. Let's sum up the answers to your questions.
Is a WCF service the solution I want? All my potential service clients
run on the same server, is there maybe another way to reference the
same code base both in CLR assembly and website projects? I don't need
support for different platforms(ex. Java) - everything is .NET(yay for
in-house progr!) - is WCF overkill?
Everything is overkill. WCF is rather easy to use and scales down very well.
Can code from a WCF service be used like a class library, or do I need
to program a new way for accessing classes/methods from the service?
Setting up a WCF on existing code requires only the implementation of an additional class, and some code creating the Hosts which will serve the aforementioned class.
Calling a WCF service requires the creation of a Channel, which is a .NET (proxy) object implementing the interface.
So basically, your business code remains in the same state.
Separation of Development, Test and Productive instances?
WCF does not take care of that. Different environments, different service addresses. You have to take care of this yourself.
Can a WCF service be updated while clients are accessing it, or do I need to schedule maintenance windows?
It depends on your maintenance policy. Kill the serving process and launch the new version is the basic upgrade mechanism.
When I update the service, do I need to update the client as well in some way?
Provided that you manage your dependencies correctly like I sketched in the previous section, you need to update the clients only if the service specification (the interface) changes.
Can I dynamically set the service reference, like I currently am dynamically setting the database connection string, depending on if StageConfig = dev, test, or prod?
You have to manage that, probably by etting Address and Binding for a service programmatically.
My CLR assemblies are written for .Net 3.5, but the websites for .NET 4.0, will that pose a problem?
Provided that you manage your dependencies correctly like I sketched in the previous section, the only constraint will be the minimum CLR version required by the "contract" assembly.
What minimum set of .NET service architecture programming do I need to know to accomplish this? I'll learn more about WCF with time, but I need to evaluate architecting effort and weigh it against getting things done(feature requests). Does the MS tutorial get me the desired skill?
You'll need the result of these exercises:
Make two executables, a client and a server, that will communicate
through a WCF contract located in a separate DLL. The configuration
should be located in the app .config file.
Make two executables, a client and a server, that will communicate
through a WCF contract
located in a separate DLL. The configuration should be determined programatically.
Try to send a serializable class as a parameter to your service.
Try to send a serializable class as a return value of your service.
After that, you'll need to think about the best/cheapest way to share the Addresses and Bindings of your services.
Hope it helps.
i have two web services. One with user functionality, one with admin functionality.
Both services effectively work with the same object types, for instance:
AdminService provides functionality for deleting/modifying Customer objects
UserService provides functionality for listing/reading Customer objects
Now in the client i have two service references, Webservices.Admin and Webservices.User.
If i use the UserService to retrieve Customer objects, i cannot manipulate those via the AdminService, since the UserService retrieves objects of type Webservices.User.Customer, however the AdminService works with objects of type Webservices.Admin.Customer.
On the server side both types are identical, just belong to different namespaces in the client.
Now the question: How can i share types across different service references?
Check out https://github.com/geersch/WcfSvcMap
By tweaking the Reference.svcmap file you can make sure only one class is generated for each DataContract used by the different service references.
Note: Remember to delete the content of the node before pressing 'Update Service Reference'
If you're controlling both ends of the communication, and both ends are .NET only, you could do this:
put all your contracts, including your data contracts, into a separate "Contracts" assembly
reference that assembly in both the server side implementation code, as well as the client side code
If you do this, when adding the service references, WCF will find and use that shared assembly, and not create new types for the entitites. In your case, you'd only ever have one type Contracts.Customer or whatever you're dealing with.
This works only if you control both ends of the wire and have .NET on both ends! But in that case, it's a great way to share contracts - especially data contracts - across both the server and any number of clients.
Use the slsvcutil to create the WCF proxy on the clientside (assuming the clientside is a .net application), reference the DLL which contains your objects and it will be used for all endpoints that pass the same object in the DLL
Open Visual Studio Command prompt from the Start -> Visual Studio 2008 -> Tools -> Visual Command Prompt
goto directory similar to
C:\Program Files\Microsoft SDKs\Silverlight\v3.0\Tools
type slsvcutil and follow the syntax
slsvcutil http://somewcfservice:8080 /r:CommonLibrary.dll
where CommonLibrary.dll is the dll that contains the business objects
[edit] fixed the fact that the project is a silverlight project
There is an easy way to share types between client and service, just by adding reference to shared type assembly to your client BEFORE adding the service reference.
You can find the detailed scenario and sample project there:
http://blog.walteralmeida.com/2010/08/wcf-tips-and-tricks-share-types-between-server-and-client.html
I have a custom data entity (data object) that is exposed via a WCF webservice. The WCF service lives in a web application. I then have a Silverlight application with a service reference to that WCF service. When i add the service reference a proxy is generated, and that includes a version of the custom data entity.
How should i structure my code so that the data entity is declared in one place, and shared amongst the project containing the WCF service and any Silverlight applications that reference it? I want to eliminate the version of the data entity that is generated with the proxy.
There is a good example of how to do this here by Pete Brown. Using that approach you can use the same classes in both the Silverlight client and in the WCF service without having to use the generated objects.
Declare the data entities in the WCF service or a project that the service refereneces, then from the Silverlight project add the entities as links and make sure the "Reuse types in referenced assemblies" checkbox is selected from the Service Reference Settings dialog.
You can put the types in either the Silverlight or WCF side.
I have tried doing things this way and found that using DTOs instead and mapping them to the entities in the Silverlight side to be much cleaner and easier to work with although I did write a bunch of mapping code to get the DTOs into the entities and vice versa.
I´m not quite shure why anybody want to do that. You have to understand that the type you find in the proxy is a projection of the Type you have at Service server site. It´s defined in the *.g.cs files and gets generated new if you update the service reference.
In my opinion it´s the best way to have it declared in a single location, and project it. You need it in two places and it´s single defined.
I may be wrong anyway .....
Right now we have around 5 service reference added to our projects in a single solution.
I am force to add service reference even for projects having indirect dependencies calling service methods. Is there a way to get around for this situation.
For every single change in the service method, I have to update every single service reference to effect those changes. It is very time consuming too.
I am just wondering, is there any way i cam manage these things globally by making single service reference for the whole solution.
help appreciated.....:)
You should be able to use the svcutil.exe command line utility to generate a single service file (.cs file for example) from multiple service URL's. The nice thing about this is that you can share clinet-side DTO's and message types accross services if they have the same schema.
SvcUtil Reference: http://msdn.microsoft.com/en-us/library/aa347733.aspx
In regards to the requirement of adding the service reference to projects with indirect dependencies. You should probably not consume the service reference and related types directly from your service client. To improve maintainability and adaptability, you should wrap your service reference(s) in a facade. The facade would map between local types and service reference types, and give you much more agility in terms of responding to service changes. You would then only need to have the service references in a single location (preferably an independent project) along with the facade. The facade, which should change infrequently, will buffer you from the issues you are currently having with your service references.
You won't be able to get a single reference if you have multiple service, unfortunately.I stand corrected - see jrista's answer.
What you could do is create and update the service references automatically: instead of adding them manually in Visual Studio using Add Service Reference check out the svcutil.exe command line tool which will basically do the same thing.
Since it's a command line tool, you can have it run as e.g. part of your continuous build and update the necessary proxy client files every time you build the app.
Check out these additional links for tutorials and explanations about the details of using svcutil.exe:
http://msdn.microsoft.com/en-us/library/ms734712.aspx
http://asadsiddiqi.wordpress.com/2008/10/25/how-to-generate-wcf-client-proxy-class-using-svcutilexe/
http://www.xvpj.net/2008/03/08/wcf-step-by-step-tutorial/
Marc