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
Related
In our BizTalk application we would like all internal messages to have the same structure, with a Header element with routing and logging information (this header is the same for all messages), all properties of which are promoted, and a Body element which is different for each specific message. When I create a new message based on the above (by setting the schema's DataStructure or BaseType), I would like the promotions to be kept as well.
I tried getting this to work by creating a Header message with the required fields and promotions, and also by creating a "complete" BaseMessage with a Header and Body element (again with all properties in the header promoted), but either way in a schema using this DataStructure the property promotions are not kept (which I guess makes sense; the XPaths indicated in the PropertySchema are different, because the BaseMessage namespace is different from the derived message).
Is there a way to have a shared schema including property promotions? Or can you copy the structure in a derived message, but you always have to redo the promotions?
Thanks for any insights!
We have a similar header structure that is imported and always have to redo the promotions.
My recommendation would be to solve this problem by not doing what you're describing. While it sounds good in theory, you will find eventually that it's over-engineering with little practical benefit.
What will matter is the routing information, meaning, the Properties, not the Header section. So, it's fine to have shared Property Schemas (deployed separately) but don't try to shoehorn the messages into a 'common' wrapper.
At work (bank) we are re-designing our MW / Web services. We are using bottom-up approach to build those services. We are using Java, jax-ws. So I need to create rules to be followed. So I have 2 questions so far:
Should we create types to our objects fields, i.e. in class Client, should we create a CellPhone object or use simply string for that. I can see the pros & cons , object will be become heavy weight, but easy to validate & control.
Any other ideas ?
Should we be using SOAP built-in fault or create our own error status code (maybe in the SOAP header). I really like the SOAP fault because of the direct mapping to Java Exception.
Thanks in advance
Some answers:
1. Bare in mind that Web Services (I assume you're talking about SOAP-based WS, as you mentioned jax-ws and not jax-rs) use SOAP which is an XML based protocol.
2. For every class you create, you will have a type in your WSDL file.
3. The SOAP envelope (which holds the "body" of your message will also hold additional XML element to denote the cellphone - you're creating more traffic.
To conclude 1 - 3 and the fact you're talking about CellPhone, I don't understand why you need to have class for this.
Are you taking about a CellPhoen class that actually models a CellPhone (i.e - the cell-phone device, with properties like "vendor", "operator" ,etc..) or are you talking about the cell phone number? If this is just Cell-Phone number, then my recommendation, based on 1-3 is still valid.
To handle validation:
You can use many validator fameworks in order to validate phone number.
There is even a JSR in Java for validation.
I recommend you to look at here to read about the Hibernate-Validator framework which conforms to JSR 303.
You can also download the source of oVirt open source project ,
and take a look at oVirt-engine (look at ovirt-engine/backend/manager/modules/common) at our BusinessEntiies and see some "real life" examples on how to use these validators.
Regarding fault - you can create your own Faults, and map them to Java exceptions, I see no harm there.
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.
I have a web service that will be deployed to multiple domains. I would like to get rid of the WCF default namespace of "http://tempuri.org/," and replace it with the domain on which the web service is deployed, such as "http://mydomain.com/." I know the best solution here is simply to have the web service exist in one place, and use that one domain as the namespace, but that is not an option for me at the moment.
I found a partial answer to this question here. In this post, the suggested answer is to set a URL property in the config file, but I am afraid I don't quite understand the answer. Where is this URL property, exactly? Also, for reasons beyond my control, the client app that will be consuming this web service does not have an app.config file, so all configs in that client app will have to be set in code. I am not sure if that matters, but figured I would mention it, just in case.
EDIT: To clarify, the reference to "http://tempuri.org" that I am trying to remove is inside the .cs file that is generated by svcutil.exe.
e.g.
[System.ServiceModel.OperationContractAttribute(Action = "http://tempuri.org/IEmailService/SendEmail", ReplyAction = "http://tempuri.org/IEmailService/SendEmailResponse")]
void SendEmail(Services.Internal.CorrespondenceWebService.Email email);
You may be confusing XML namespaces with URLs. Here's an example of a namespace which is not a URL: urn:schemas-microsoft-com:datatypes.
Since a namespace is not necessarily a URL, you do not have to change it for each environment.
On the other hand, you should pick a namespace, and use it consistently. Perhaps something like http://services.mydepartment.mycompany.com/myservice/. You really don't want to ship a service that still uses http://tempuri.org/, as that demonstrates a lack of understanding of namespaces.
In response to your updated question: those namespaces are present in the .cs file generated by svcutil.exe because they are present in the metadata from the service. You need to change them in the service, and when the client is created or updated, it will have the correct namespaces.
I am trying to pass an object into a WCF web service, the object I am passing in is a Server object, I then want to be able to call TestConnection();
The issue I am having is that Server is the base class and there are several derived classes of Server, i.e. SqlServer2005Server, OracleServer and ODBCServer that I want to use
I want to be able to pass in a Server Object and then determine its type, cast it and then use the method
public string TestServerConnection(Server server)
{
if (server.ConnectionType == "SqlServer")
{
SqlServer2005Server x = (SqlServer2005Server)server;
// Tests connection to server and returns result
return x.TestConnection();
}
return "";
}
'Server' the base class implements IServer
I am unable to cast it, can you advise?
Much Appreciated
Phill
As Daniel Pratt said, in the end, you are only shuttling XML (not always the case, but most of the time you are) across the wire.
If you used a proxy generator to generate the definition of the Server type, then you aren't going to be able to make calls on the methods of Server, because only properties (semantically at least) are used in the proxy definition. Also, you can't cast to the derived types because your instance is really a separate type definition, not the actual base.
If the Server type is indeed the same type (and by same, I mean a reference to the same assembly, not just in name and schema only), then you can do what Steve said and use the KnownType attribute on the Server definition, adding one attribute for each derived class.
However, like he said, that convolutes your code, so be careful when doing this.
I thought that using inversion of control would work here, but you run into the same situation with generic references to specific providers.
You need to add the KnownType declaration to your service contract for each derived class. There are ways to automate this (since it obviously convolutes code and breaks inheritance), but they require a lot of work.
Does the object you're passing represent a "live" connection to a DBMS? If the answer is yes, there is no hope of this ever working. Keep in mind that despite the pretty wrapper, the only thing your web service is getting from the caller is a chunk of xml.