I would like to connect to a SOAP webservice (HP Operations Manager Incident Web Service) using a .NET client based on code generated by adding a service reference. The generated proxy creates a client that implements the DuplexClientBase class. The service is IIS hosted with a self-signed certificate and I need to sign in using basic authentication.
I ran into two problems trying to connect to this service:
I have not yet been able to find the right binding configuration. Either the binding does not support duplex or https traffic with basic authentication.
When adding a .NET 2.0 web service reference (the binding issue is not there) I am able to connect to the service but the “Action” header element which is required by the service and should look like <a:Action s:mustUnderstand="1"> http://schemas.xmlsoap.org/ws/2004/09/enumeration/Enumerate</a:Action> is not included in the header. When I create a SoapExtensions and inspect the contents of the Action property of the SoapMessage object in the ProcessMessage(SoapMessage message) method it contains the right value but the property is not serialized in the message header.
I would like to know if any of you could suggest what to do:
Proceed with a 2.0 legacy reference and find a way to add the Action element in the SOAP header. (eg adding a SoapExtension)
Fix the binding a find a way to connect to the https site with faulty certificate (wsDualHttpBindingdoes not support HTTPS, BasicHttpBinding does not support duplex, PollingDuplexHttpBinding does not seem to work in a console application)
Try to generate the code in a way that no duplex communication is required. Is this possible?
It is possible to make a .NET 2.0 client support WS Addressing. You can accomplish this by downloading and installing Webservice Enhancements 3.0 (WSE). http://www.microsoft.com/en-us/download/details.aspx?id=14089
When you add a reference to the Microsoft.Web.Services3 assembly and change the code generated by adding the web service reference. Change System.Web.Services.Protocols.SoapHttpClientProtocol into Microsoft.Web.Services3.WebServicesClientProtocol and the code will support WS Adressing. The action element will now be added to the SOAP header.
Although this workaround does the job I still would prefer a WCF service reference connection.
I hav a C# web application. In that I have added a WCF Service file (.svc) by Right Click project Add New Item >> WCF Service (wcfService.svc). ( Now I have IwcfService.cs and wcfService.cs in my App_Code folder) And also added a function WCFXmlData(string id) inside that.
I am trying to access the function inside wcf service file from an ajax call in my application (in an aspx file).
But I am not able to do that.
Also I tried to browse this .svc file directly. There I got a message like Metadata publishing for this service is currently disabled.
That really depends on your binding, if you use the WebHttpBinding you can simple access the data via a browser. In best case you should modify your contract in such a way that it returns JSON, this is less overhead than XML or even SOAP (which uses also XML).
It your webpage is also implemented in the webservice you have nothing special to care about, but if your service runs under another subdomain you need to implement JSONP or Cross-Origin Resource Sharing (CORS) to manage cross domain calls.
After searching the entire day about what I should use, I'm not sure what option would be best for my needs so I hope someone with more experience could help me out.
I have a winforms application (c#) and a ASP.NET MVC 4 web application (c#).
I wish to connect these, the goal is to send and receive data from the database which I use in the MVC 4 project, but from within the windows forms application. The data I send from the windows forms application to the database, is then used by the MVC 4 web application.
I am entirely new to web services / Web Api's so I can't really decide what option would be best. Any help would be much appreciated..
If you already created MVC4 project then you can add actions to any controller
and return JSON data like below :
public JsonResult GetCategoryList()
{
var list = //return list
return Json(list, JsonRequestBehavior.AllowGet);
}
or you can create new project of MVC4 and select WEBAPI template . It will create webapi project for you .It will create with example .so it will easy for to create webapi.In webapi it return data automatically convert to xml and json as per request
The WCF Web API abstractions map to ASP.NET Web API roughly as follows
WCF Web AP -> ASP.NET Web API
Service -> Web API controller
Operation -> Action
Service contract -> Not applicable
Endpoint -> Not applicable
URI templates -> ASP.NET Routing
Message handlers -> Same
Formatters -> Same
Operation handlers -> Filters, model binders
Other Links
If you have an MVC 4 App already, it would be better to use Web API (RESTful service)
I assume you have some knowledge in building REST API (understanding of POST, PUT, UPDATE stuff)
It is simple in configuration and usage. All what you need actually is to create a new controller like:
class MyApiController: ApiController {
public Post(SomeClass item) {
....connect to db and do whatever you need with the data
}
}
You'll also should configure routing for Api.
And then in your winForms app you can simply use HttpClient class to perform api call.
HttpClient aClient = new HttpClient();
// Uri is where we are posting to:
Uri theUri = new Uri("https://mysite.com/api/MyApi");
// use the Http client to POST some content ( ‘theContent’ not yet defined).
aClient.PostAsync(theUri, new SomeClass());
Take a look at some implementation details right here:
Web Api Getting Started
Get started with WCF is not so easy as with Web API.
Given the tags you've used, my guess is that you're deciding between SOAP Web Services and WCF. Given these two, I say to go WCF. SOAP web services (as implemented in Visual Studio) are the older technology; still serviceable, but WCF can do everything an older SOAP service can do (including look exactly like a SOAP service) and more.
If you have a web service that connects your web server to your database server (these two things should be on different machines; your web server is exposed to the world by necessity, while your DB server should be locked down like Fort Knox), I see no reason why you shouldn't use that same service as-is for an internal WinForms application (using a LAN/VPN to access the service layer on the DB server). For a WinForms application that must access the data over the Internet, I would recommend reimplementing the service as a WCF service supporting secure encrypted data transfer. You can also set up the service endpoint to only accept HTTPS connections, and thus simply run your existing service through SSL/TLS.
What you choose will primarily depend on how much time-resources you can commit to resolving the problem; moving to HTTPS is a fast fix requiring little if any code changes, while reimplementing in WCF will take more time but will allow additional security measures beyond a simple secure tunnel.
Or something lightweight like Nancy: http://nancyfx.org/
We had some issues with MVC4 WebApi stuff and ended up using ServiceStack on the server side JavaScript/AJAX for web clients and RestSharp for thick clients.
One of our specific issues was the inability to auto generate documentation, significant performance differences, and better support for unit/integration testing.
Rather than advocate specifically WCF, I'd recommend WCF Data Services or OData, with the stipulation that you'll need to secure it. If you go for pure WCF, you'll see that you'll end up creating a lot of code to handle retrieving the info from a database, and then sending that information right back out to your clients. It doesn't sound that bad, at first, but after about 30 entities in a database, you'll quickly grow tired of a pure WCF solution.
OData is great, it uses Entity Framework, and it quickly opens data manipulation for an existing database or one you are going to make. It will save you a ton of development time, if you can make your service secure. The format of the data response is flexible. There are plenty of client libraries ported for other programming languages as well.
The steps for securing a service are pretty simple. Always deploy to https. Any login or registration methods , need to be post methods, that return a token (Encrypted value), or a unique secret that can be encrypted and sent back for any subsequent requests. It's better to use the token, and have an expiration on the token.. because otherwise both your service and your app whether mobile or desktop, need to have a shared encryption / decryption method.
I am trying to log the soap request and response messages of a service in C#. I have a ready made soap extension which does all this, however I am having trouble adding it to the service method.
Since I have a service reference added in my VS project and not a web service reference, when i check the reference file for this service, I don't see the method which is doing the invoking of the remote service. All the examples I saw were of adding to a web service, which has a different reference format.
How can I log the soap messages in this case?
Soap extension is only for using ASMX based service or client = Add web reference. Once you used Add service reference you are using WCF client API instead and you cannot use Soap extension. You must create message inspector instead.
If you need message logging only for debugging purpose you can use built in WCF message logging.
There is an another way to see XML SOAP - custom MessageEncoder. The main difference from IDispatchMessageInspector / IClientMessageInspector is that it works on lower level, so it captures original byte content including any malformed xml.
In order to implement tracing using this approach you need to wrap a standard textMessageEncoding with custom message encoder as new binding element and apply that custom binding to endpoint in your config.
Also you can see as example how I did it in my project -
wrapping textMessageEncoding, logging encoder, custom binding element and config.
I Want to create a SOAP proxy, that modifies the original web service SOAP header, nampespace and keeping the body the same)
What is the best way to do this? Create a SOAP provider , that consumes the original web service then modify the header and namespacs? (this seems like alot of work?)
If you have few SOAP services, your suggestion is the way to go. If you have many SOAP services you want to transform, it might be a better idea to write a HttpHandler. See http://msdn.microsoft.com/en-us/library/5c67a8bd(VS.71).aspx for more information.