Bit confused with specifying a namespace for the service contract. Can understand with respect to a normal class,
My understanding about namespace
In normal OOPs model, say Employee class is part of Microsoft name space as well as Google name space. But since we may add reference to Google as well as Microsoft assembly in our project; hence to differentiate Employee's we have namespace, since when we say
Employee emp = new Employee()... compiler really doesn't really know which employee we are referring to?
Similarly, with respect to web service how does it matter? May I request an explicit example to explain the case please? For example
[ServiceContract(Namespace="Company.Matching.Algo")]
It's used - just like regular .NET namespaces - to keep things apart.
Having a namespace helps when you have multiple services that might end up all having similar methods exposed. With a namespace, they can all have a method called GetVersion or something, and the WSDL document will be able to keep them apart based on their namespace.
Also, namespaces are often used for versioning, so your first WCF service might have a service namespace of http://yourcompany.com/MyService/2011/08 and have five methods. If you later on introduce a v2 of your service, which might have 10 methods, and you put it into a separate namespace of http://yourcompany.com/MyService/2011/12 then you can keep those things separate - and an "old" client can still call the "old" service with (/2011/08) and use its method, while new clients can already call the new service with more capabilities.
From RebuildAll:
A note on namespaces: namespaces ARE NOT URLS!. They might look like one, like in my examples, but there is no such subdomain as schemas actually in existence. Namespaces follow the URI format, but are not actual addresses. They can be used to identify schemas, because usually a company owns a domain name. Thus using that as the schema namespace creates something unique. And that is exactly what namespaces should be: unique.
The namespace is important for serializing and deserializing objects.
In your example you can have the same Employee class on the server and client, and send an Employee object from one to the other over a web service. If the namespace is different it will be null when you deserialize on the otherside.
Related
I have noticed that WCF namespaces are usually URLs, but if you try to access them in a browser they typically return 404.
1) Are these namespaces ever really called?
2) If not, then why are they URLs?
3) Do they have to be URLs or would any string do?
An example of what I've seen:
[ServiceContract(
Name="ServcieAContract",
Namespace = "http://www.thatindigogirl.com/samples/2006/06")]
public interface IServiceA
The use of URIs for WCF namespace names is a convention which grew up around XML namespaces generally.
A namespace name can be any string, but the motivation for using a URI instead is that it is more likely (if chosen sensibly) to be globally unique - the host name part associates the namespace to a particular organisation, and that organisation should then have a standard for constructing unique namespace names within its domain.
In some cases the URI chosen is actually a URL: that is, a resource is obtainable from that address - usually documentation, or a copy of the schema, or such like. You might consider doing this if the namespace relates to some public interface and you want your customers to be able to easily find help/documentation on its usage.
Namespaces are just name *spaces*. They are not URLs.
Having said that sometimes Schemas are accessible in the URL.
can they be just normal strings? Absolutely. Although you would usually prefix them with urn: in this case.
As Chris commented, for URN specification see ietf.org/rfc/rfc2141.txt
1) They are not supposed to be called (although they may be, maybe for showing documentation) but are used to identify and versioning of the services and operations.
http://msdn.microsoft.com/en-us/library/ms733832.aspx
2) Check Chris Dickson answer
3) Any string would do but people mostly stick to the the label format with date-stamped namespace version
http://www.ibm.com/developerworks/xml/library/x-tipnamsp/index.html
I'm in the process of designing my first "proper" WCF service and I'm trying to get my head around how to best handle versioning of the service.
In older ASMX web services, I would create aMethodNameRequest and MethodNameResponse object for each web service method.
A request object would really just be a POCO wrapper around what would typically be in the method parameters. A response object might typically inherit from a base response object that has information about any errors.
Reading about WCF and how the IExtensibleDataObject, FaultContractAttribute and Namespacing works, it seems that I can revert back to using standard parameters (string, int etc) in my method names, and if the service is versioned, then ServiceContract inheritance can provide this versioning.
I've been looking into http://msdn.microsoft.com/en-us/library/ms731060.aspx and linked articles in that, but I was just looking for a bit of clarification.
Am I correct in thinking that dispensing with the Request/Response objects is more ideal for WCF versioning?
EDIT: I just found this article which suggests using explicit request/response object: http://www.dasblonde.net/2006/01/05/VersioningWCFServiceContracts.aspx
I don't agree that dispensing with Request/Response objects is that way to go.
There are obvious benefits of coding with messages:
you can reuse them, which avoids pass 5 ints and 3 strings to a number of different methods.
the properties are named and so can be reliably understood, whereas a parameter that is passed by value through multiple tiers could be confused, and so on.
they can be proper objects rather than just data containers, if you choose - containing private methods, etc
But you are really asking about versioning. Don't forget that you can version the messages within your service contracts. The classes in assembly can have the same name provided they are in different namespaces (e.g. v1.Request and v2.Request), and they can both implement a required interface or inherit from some base object.
They also need to be versioned for your service consumer, which can be done with xml namespaces; I've typically put the service contracts (the operations) in a namespace like http://myapp.mydomain/v1 and the messages (the request and response objects) in http://myapp.mydomain/v1/messages.
One gotcha with this approach is that if you have an operation, call it Submit, in the http://myapp.mydomain/v1 namespace then by convention / default the soap objects SubmitRequest and SubmitResponse will also exist in the same namespace (I don't remember what the run-time exception is but it confused me for a while). The resolution is to put message objects in another namespace as I've described above.
See "Versioning WCF Services: Part I" and "Versioning WCF Services: Part II".
Using WCF3.5SP1, VS2008. Building a WCF service that exposes about 10 service methods. We have defined about 40 [DataContract] types that are used by the service.
We now experience that adding an additional [DataContract] type to the project (in the same namespace as the other existing types) does not get properly exposed. The new type is not in the XSD schemas generated with the WSDL.
We have gone so far as to copy and rename an existing (and working) type, but it too is not present in the generated WSDL/XSD.
We've tried this on two different developer machines, same problem.
Is there a limit to the number of types that can exposed as [DataContract] for a Service? per Namespace?
No, there's no hard limit on the number of Data Contracts - mostly certainly not as low as 40 or 50!
What I'm guessing might be the problem is this: you can add as many DataContracts as you like - but unless they're actually being used (as an input parameter or return type of a service method), they won't be serialized into the WSDL/XSD.
What happens if you add another dummy service method which takes one of your newly added types, and returns an arbitrary INT value or something. Does it show up in the WSDL/XSD then??
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.
In Understanding WCF Services in Silverlight 2, the author, David Betz, explains how to call a web service without adding a service reference in the client application. I have a couple of weeks experience with WCF, so the article was over my head. In particular, although the author gave a lot of code snippets, but does not say what goes where. In the article, he provides two different code snippets for the web.config file, but does not clarify what's going on.
Looking at the source code there are four projects and two web.config files.
So far, I have been using the standard Silverlight project configuration of one project for the web service and one for the Silverlight client.
Firstly, does the procedure described in the article work with the standard two project configuration? I would think it would.
Secondly, does anyone know of a simpler example? I am very interested in this, but would like to either see source code in the default two project setup which is generated when a new Silverlight project is made, or find a step by step description of how to do this (eg, add a class called xxx.cs and add this code..., open web.config and add these lines...)
Many thanks
Mike Thomas
First, a little philosophy...
If you are a consumer of a WCF service that you did not write, adding a service reference to your client is really the only mechanism you have to enable interaction with that WCF service. Otherwise, you have no way of knowing what the service contract looks like, much less its data and message contracts.
However, if you are in control of both the client and the WCF service itself, adding a service reference to the client is a nice convenience, but I've recently been convinced not to use it. For one, it becomes a nuisance after the first few times you change your contract to remember to update your service reference. And in my case, I have several different C# projects that are consuming the WCF service, so I have to remember to update each one of them. Second, creating a service reference duplicates the contract definitions that are already defined in your WCF service. It is important to understand the implications of this.
Let's say your WCF defines the following type.
[DataContract]
public class Person
{
[DataMember] public string FirstName {get; set;}
[DataMember] public string LastName {get; set;}
}
When you add a service reference to your client, the metadata associated with this class is retrieved through the metadata exchange (MEX) endpoint, and an exact replica of this class is created on the client side that your client "compiles" against. So your WCF service has a definition of the Person class, and so does your client, but they are two different, distinct class definitions.
Given this, it would make more sense to abstract the Person class into a separate assembly that is then shared between the WCF service and the client. The added benefit is that when you change the contract definitions within this shared assembly, you no longer have to update the service reference within the client because it is already referencing the shared assembly. Does that make sense?
Now to your question. Personally, I've only used WCF within C# projects, not Silverlight. However, I do not think things are radically different. Given that, I would suggest that you watch the Extreme WCF video at dnrTV. It gives a step-by-step guide for how to bypass the service reference feature.
Hope this helps.
Let me try - I'm not an expert at Silverlight development, so bear with me if I say something that doesn't apply to Silverlight :-)
As Matt Davis mentioned, the "usual" use case is this: you add a service reference to a given service URL. In doing so, Visual Studio (or the command-line tool svcutil.exe) will interrogate the service and grab its metadata - information that describes the service, all the available methods to call, what parameter they expect etc. From this, it will generate a class for you (usually called the "client" or "client proxy"), which you as a client (=service consumer) will use to call the service. You can have this client proxy class generated inside your "normal" Silverlight client project, or you could possibly create your own "service adapter" class library, esp. if you will be sharing that client proxy code amongst several Silverlight projects. How things are structured on the server side of things is totally irrelevant at this point.
As Matt D. also mentioned, if you do it this way, you're getting copies of the service, its methods, and its data, in your client - those are identical in structure to what the server has - but they're not the same type - you on the client side have one type, the server has another (the fields and properties are identical though).
This is important to remember since the whole basic idea of WCF is message-passing - all that connects the client (you) and the server (the other end) are the messages and their structure - what method to call and what values to pass into that method. There's no other link - there's no way a server can "connect" to the client code and check something or whatever. All that gets exchanged is serialized messages (in text or binary form).
If you do control both ends, you can simplify things a bit - you can physically share the service contract (the definition what the service looks like and what methods it has to call into) and the data contract (the description of what data is being passed back and forth) on both the server side as well as the client side. In this case, you won't be adding a service reference, you won't be duplicating the service and data definitions, so things are a bit easier (but it only works if you're in control of both ends).
In this case, best practice would be to package up all that describes the service (the service interface with its methods and the data contracts) into a separate assembly (class library) on the server, which you can then copy to the client side, and reference directly from there (like any old assembly you might have). So in this case, you would typically have at least three projects in your solution:
your actual Silverlight client project
the website or web app hosting your Silverlight control for testing
the service interface assembly, which contains the service and data contracts
So there you have it - I hope I covered all the basics of what's going on, and why you would want to do one or the other thing. If you need additional info, don't hesitate to comment on this posting and let us know!
Marc