I've started a team project were each team needs to create a web service which will need to expose various methods. Our team has created a WCF web service and have had no problems with the other teams consuming our services except for one team, which I'll refer to as Team B. Team B created their web service using an older version of Java (no clue what version) which doesn't support metadata exchange.
Since we are all new to WCF, and web services in general, does anyone know of a way to solve this problem?
Thanks in advance
There are 2 types of metadata exchange - one is WSDL, and the other is MEX. WCF supports both. As long as you can open the web service url in a browser and see a WSDL file I'm in doubt if there is such an older java version that does not support it. MEX is a different thing but as long as you work with WSDL not interesting. You need to check with the Java team how their version supports generating clients from WSDLS (typcally there are command line tools like wsdl2java or IDE plugins) and then give them the WSDL url. It may be that there is a specific construct in the WSDL which they do not support in which case ask them for the error message.
Related
I am trying to come up with a way to accomplish something but haven't been able to find what I am looking for yet.
4 Developers
1 Development webserver
1 Development WCF server
We each have our own website for testing/debugging on the one server using IIS6. We each have our own port number that distinguishes what site we are connecting to.
When our websites make a request for the WCF server the hosts file on our dev webserver points it at our dev WCF server. Likewise, the production webserver's hosts file points it at our production WCF server. This way we never have to worry about changing the Address of our service references in Visual Studio.
Recently we have a need for multiple developers to be working on multiple branches of the WCF code at the same time. Currently we have to take turns using the WCF server.
We want the ability to have our individual websites on the dev webserver point at individual WCF websites on our dev WCF server.
I have tried several ways I thought of but they all require us to update the Address in the service reference in Visual Studio. (currently if we update/add a service call we point our local machine's host file at the dev site after the new WCF code has been deployed to it.)
Does anyone have any idea, or a direction of where I can find common configurations for this type of thing? I have to assume that Microsoft has a best practices setup for multiple developers with multiple dev environments for websites and WCF sites.
Requirements of the setup:
We only get a single webserver for website testing.
We only get a single webserver for WCF testing.
We need a solution that doesn't require us to update the Address in the service reference in Visual Studio when developing on the WCF code.
If worse comes to worse we may have to think about changing the requirements.
Thank you in advance!
You can simply change the address of the service in configuration file for each deployment. You don't need to change the address of service reference until the service has changed in the way that would produce different client proxy code.
i am new in wcf and started learning. i got one confusion like that i create a small wcf service and just do not host it in IIS,console apps or win service but from another apps i can add the service reference of svc file and found it is working. if wcf can work without hosting in any place like "IIS,console apps or win service " then why people would alway host wcf service in IIS,console apps or win service. can anyone tell me the reason.
people use IIS and windows services in general because they are simpler to setup and run more consistently. they can also be hosted more easily on servers where the services can be configured to start automatically, and as usually wcf is used as a server communication method it is usually this that you want to do.
hosting in console applications is generally easier to setup for simple examples for testing purposes, when you want to test your services locally.
Whilst hosting in applications as possible it's a less common scenario to use wcf to communicate between 2 applications on the same machine.
EDIT:
Your original question asked why people always talk about IIS, services etc. The point I was making was that usually wcf is used for web services, and is usually run on a server other than the local machine. Even though it can be used for inter process communication on the same machine this is not the most common use case. This is why you see a lot of examples using IIS and not too many hosting it in a Windows forms app.
I am new to creating WCF services. I have created a WCF service that is using TCP. The service is running on IIS 7. From within the solution file I have a client project that I have used to test my service. I've run the client project using a TCP endpoint and it accesses the service and everything is fine.
Now, I want to access my TCP service from a new standalone project, one that is not part of the service's solution like the client project. I created a new project in VS 2008. I clicked on Add Service Reference, entered the net.tcp address (net.tcp//.......) and clicked go. An error is returned saying that the "Metadata contains a reference that cannot be resolved."
Is there something further in IIS 7 that needs to be configured? Am I correctly adding a reference to a service that is using TCP? If needed I can supply more information but at this point I am not too sure what I need to post. As I said the service works perfectly from the client project but I can't even access the service from a standalone project.
Thanks in advance for your help.
Look at your Web.config file. Do you have an entry that starts out like
<endpoint address="mex"...
and then specifies a contract="IMetadataExhange? If not then you need to add a meta data exchange endpoint.
If you have $29 to spare, you can save yourself a LOT of time and watch some great videos by Aaron Skonnard on WCF (in the beginner examples there is an 8 minute video on hosting WCF in IIS), The $29 gets you a one month subscription so you can watch anything in the library. Money very well spent in my opinion. [Edit] I forgot to mention you can get a free trial, I think it's good for a month or 4 hours of viewing whichever comes first.
In Visual Studio 2010, there are two options to create a WCF Service. The first one is File | New | Projects... | WCF | WCF Service Application. The second one is via File| New | Web Site... | Visual C# | WCF Service. Both of them looks like the same. What exactly are the differences between the two projects?
Info on the above mentioned link is here:
A service application includes a website host already setup for you. A service library is a library of services that a host can reference and startup.
If you start with a service library (recommended) you can then choose any host you wish (a windows service, IIS/ASP.NET, or even a console application) and you'd just reference your library from your new host. Choosing a Service Application limits your host to just IIS/ASP.NET (though this might be ok for your purposes, but will limit the protocols you can use).
Edit: Changes in IIS since I wrote this allow for a wider variety of protocols on ASP.NET activated services, so choosing a service application is much less limiting than before.
all you have is the one project I see only added complexity if you separate for the heck of it. I used a library when I had some particular use cases where I had to host in both a windows service and in IIS.
For IIS you you can move the classes and interfaces to a library but keep your .SVC files in the web project. You must edit the .SVC files to point to the properly qualified classes.
Regards
Karan Shah
One is a Web Site for creating WCF Services from File | New | Web Site...| Visual C# | WCF Service and another is a Project for creating WCF service Application.
A service library is a library of services that a host can reference and startup.A service application includes a website host already setup for you.
If you start with a service library you can choose any host you wish, for example a windows service, IIS/ASP.NET, or even a console application, and you'd just reference your library from your new host. Choosing a Service Application limits your host to just IIS/ASP.NET.
this is B2B scenario, one client (at least for now).
Server environment:
WCF service, IIS6, .NET v3.5
Client environment:
dev shop is .NET 2.0/VS2005. Will be calling my WCF service.
Question: should i
(a) open WSDL gen for the client(not desirable for security reasons)
(b) send a WSDL file(s) to the client
(c) pre-compile Proxy into dll (on my side) and send it to the client
(d) ???
?
Any suggestions on what would be the best practice for this scenario, any pros/cons?
Thanks in advance,
Igor
Why is a publicly available WSDL not desirable for security reasons?
I may be willing to admit that publishing an API (which is basically what you are doing with WSDL) makes you a bit more vulnerable than if you didn't, but it would be wrong to assume that hiding the WSDL constitutes any kind of security. This is ironically called security by obscurity, and it will be broken by any determined attacker.
The web service should be secure in itself. WCF offers many security features, but that is perpendicular to your question.
I'd prefer publishing the WSDL. If you don't want to do that, or if there is a policy in place that says that you can't do that, then send the WSDL to the client team so they can use it as they wish.
Precompiling the proxy will only enforce your coding conventions on the client team, and they may not appreciate that - for example, I often prefer my proxies to be generated with the /i switch that makes the generated classes internal. I also like to be able to specify the .NET namespaces so that they fit the rest of my code. That would not be possible if I got a precompiled assembly (I would be able to use it anyway, but it would just annoy me).
If you don't want to actually publish the WSDL and make it available online for calling clients, then I would prefer the "send me the WSDL and XSD" approach.
That way, you still give the client calling you the ability and flexibility of creating the proxy the way they see fit.
I would only consider using a pre-compiled proxy in an assembly if the calling party was unable or unwilling to create the proxy themselves, and only if they asked me to supply that code in assembly form.
Marc
In order of preference I would be inclined to:
Have the service expose the WSDL (with security enabled)
Send a WSDL file to the service consumer
I was going to list option 3 as sending a proxy DLL but on second thought I wouldn't even list it as an option. It seems to me that shipping your client a proxy DLL opens up a big can of worms that I would not want to deal with.
The main problem is that you end up having to support executable code that is deployed at the client site. The proxy code could be generated by svcutil but if there is some sort of problem invoking the service I can just see the client calling you for support and telling you that your proxy is not working. Now, their claim is probably not correct but it's hard for you to prove it since you don't know what they are doing on their side. e.g.
Maybe they didn't install the proxy DLL?
Maybe there is some permission problem?
Maybe they don't know what they are doing (yeah, I know that never happens. :) ).
Maybe a .NET upgrade on their side affected your proxy?
You might even run into some versioning headaches when sending them new proxies.
If your customer is not that savvy instead of trying to help them by creating proxy DLL perhaps putting some time and effort into assisting them in getting the correct configuration and usage of your service would be a better approach?