Following advice on here, I am looking at whether to replace WCF with OpenRasta.
In Visual Studio, how do I consume an OpenRasta in the same way as I would a WCF/ASMX service e.g. Add a service reference, this handles the types using WSDL.
I can't find any examples which don't require a custom WebRequest and parse the xml, which for us is a significant step backwards for utilising a service in code.
OpenRasta is designed to give you RESTful services. To consume that, you might want to look at something like RestSharp which is designed to act as a client/consumer for RESTful services.
As Colin says, ReSTful services are by definition hypermedia oriented, so generating lots and lots of RPC style code a la WSDL is not doable, it would break hypermedia.
You can still happily generate datacontract-style classes from an xsd and read those from the xml, it's at most 4 lines of code.
Related
I want to make a call to a web service that is written in C#, through Visual C++ or C++ in Visual Studio 2010. I searched on web but was not able to find any point to point document. It would be a great help if you will tell me.
If you're prepared to go with managed C++ then you can use WCF.
However, if this isn't an option then your best bet is to go with a socket approach. You'll need some cross-language way to represent the data your sending from C++ to C# and back again. Google Protobuf will help here as there are frameworks for both languages, in addition to many others.
A web service uses something JSON or XML as an interface and is inherently language independent. You would have to look for libraries that can create requests to the web service. For example if your web service in C# uses SOAP (XML) which it would if you created the default web service in Visual Studio you could create your own request in XML in accordance to the specifications of SOAP:
http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
or use one of the libraries mentioned in this question:
Generic WebService (SOAP) client library for C++
Have a look at Walkthrough: Accessing an XML Web Service Using C++.
I am looking to get into doing some iOS development for a nice addition to a project i am running.
The main project is currently written in C# and is mainly asp.net with a few windows services.
I would like to incorporate this to be able to develop a basic iPhone app as a proof of concept.
From what i have read and understand, its generally best practice to use JSON as a communication medium for iOS.
I am thinking about using WCF to create the API methods so the iOS app can connect to these services to get the data.
Are there any nice tutorials to do this?
Take a look at:
Developing RESTful iOS Apps with RestKit
I do this all the time. WCF Data Services (OData) are the way to go. With OData services, you can specify that you want JSON response by passing (Accept - Application/JSON) in the HTTP Header and OData will return JSON to you.
I have used several libraries for getting OData (which are REST services) from iOS. Microsoft's iOS OData implementation is pretty lame. RESTKit does a really good job for what it handles, but is really painful if you have to do something that it doesn't. I have also used ASI - it is much more flexible than RESTKit, but is not without problems. I ended up writing my own and it suits me just fine.
For a beginner, I would recommend using ASI over RESTKit. RESTKit, while doing a lot of the heavy lifting for you, takes a bit to get working right.
There are two things that are not standard when receiving JSON responses from OData.
1. All responses are captured in a JSONDictionary with the key of "D".
2. Dates are serialized to the JSON standard (number of seconds since 1970), but they are placed in a string like so: /Date(1212353), so you will have to parse out the Date() part of the string before you can use it.
RESTKit doesn't handle either one of these issues natively, so you will have to deal with them if you choose that route. Personally, I would go the ASI route until you learn enough to write your own.
I am considering open sourcing my solution - if I do, I will update this response with the link to it.
---UPDATE----
Just to be clear - if your server side system uses WCF Data Services, otherwise known as OData, then with minor tweaking, RESTKit plays nice with it. If your services are traditional WCF Services (i.e. SOAP Binding), then you will not be able to get JSON out of them because they are bound to the SOAP protocol (Unless you create a custom Behavior to translate it - which I wouldn't do). It all depends on what your services do in essence. If your services are typically data exposure/manipulation (i.e. addCustomer), then you should expose them as OData. If they are truly operations, then you should maybe consider exposing them as actions from a MVC site. Either of them can get you REST services using your existing infrastructure and platform.
If you're using Objective-C to develop the iPhone app, I'm not sure WCF is the best web service technology to use on the server. Check out ServiceStack to create a RESTful service.
Refer following link:
http://www.kotancode.com/2011/04/26/backing-your-ios-app-with-wcf-json-web-services/
It has included comprehensive code samples as well.
I've found all kinds of information over the web, but none yet that can categorically answer the question.
This article on the MSDN is an argument against the RPC protocol, but doesn't specifically say it isn't supported.
This article demonstrates it is possible to extend the web service by hand. I'd prefer to avoid that, as it defeats the purpose of using a WSDL file.
There are sections of the MSDN with classes for dealing with RPC based SOAP messages in the framework, such as System.Web.Services.Protocols.SoapRpcMethodAttribute.
The service I need to connect to is using the RPC/literal protocol and there is no chance of changing that.
The Service Stub generating tool (wsdl.exe) will not accept RPC/literal WSDL files.
I really need to use RPC/literal in my .NET 2.0 application. Is it possible?
Yes, it`s possible. You can do RPC with .NET Remoting clickme. However, this is considered a legacy technology and it is not used anymore. Please take a look at .NET WCF if you want to do some SOAP RPC.
I'm confused about the usefulness of WCF in consuming non-UTF services. I decided to try and give it a go, in lieu of .NET 2 web services, and quickly discovered that out-of-box it cannot consume ISO-8859-1 web services. After googling a bit I learned that you need to create a custom message encoder (i.e. http://msdn.microsoft.com/en-us/library/ms751486.aspx).
Comparably, if I wanted to use .NET 2's web service model, I just add a reference and it works - no need to write a custom encoder. I've decided to use the easier of the two methods, since I can't justify writing and testing a bunch of code I don't need.
I am however curious why anyone would use WCF when they could use the faster 2.0 method. This is a rudimentary question - I'm new to web services, and just using them to pull data from several third party vendors. All I need is the ability to consume the service, throw some credentials, call methods, and get objects back - I'm assuming WCF goes above and beyond that, somehow.
Classic web services are by no means 'faster' to employ than WCF services. WCF has only a small learning curve to get going with stuff we used to do with webservices in the past.
Maybe in very simple scenarios you can accomplish the same thing with an asmx web service as you can with a WCF service using a basic HTTP binding, but among the numerous benefits of the framework (industry wide standards, multiple protocol support), is the fact that alot of the plumbing has already been done for you (in terms of communication, security etc), allowing you to focus on your business logic.
Maybe asmx provides what you need, but the technology is deprecated. If you do a google search, there is tons of websites comparing the two. I would advice to take the oppertunity to start learning WCF!
Hope this helps.
If all you're doing is consuming an existing non-WCF service, then the choice to go with WCF is probably only going to depend on other factors, like if you anticipate consuming WCF services in the future and want to have a uniform codebase.
WCF is an umbrella with a single interface for multiple "bindings" such as HTTP-with-REST-or-SOAP, named pipes, MSMQ, TCP (formerly .Net Remoting), all mixed in with different options for security, authentication, transactions, reliability, etc. So if you were consuming multiple services that were exposed in a variety of ways, then WCF would help you tame them all with a single API.
I searched a lot, apologies if I missed something obvious. And thanks for reading the looong text below.
I have a 3rd party (read: No way to access/change the source) application here. It consists of a server (Windows service) and an API, that talks to the server via remoting.
For several reasons I'd like to expose this API over WCF (see subject: One reason is a WCF client).
The problem is, the API is
unchangeable (follows 3rd party rule)
using no WCF itself (it is serializable/MarshalByRef where necessary for Remoting)
using lots of interfaces and internal implementation classes
Following 1 I cannot use the (quite intrusive) WCF attributes myself.
Following 2 the API itself can be used "over the wire" (they support remoting via TCP and HTTP), but remoting is not good enough for me.
Following 3 I have mostly interfaces (which WCF won't handle well, cannot (de-)serialize). The implementation classes could be sent over, but - I cannot access them.
The general usage for this API is based on a single interface (and its members/properties), so the typical usage is like
var entryPoint = new ApiClientEntryPoint();
entryPoint.SomeMethodCall();
entryPoint.PropertyExposingAnInterface.SomeOtherMethodCall();
and so on.
What I'd really like to do is generate (with as little effort/code as possible) a proxy (not in the typical WCF sense) that I expose via WCF and that serializes this hierarchy mapping every call/property on the client to the real thing on the server.
The closest I've come so far is stumbling upon this project, but I wonder if there are more/other tools available that take a medium to large part of this work off my shoulder.
If there are any general other advices, better approaches to wrap something preexisting and unchangable into WCF, please share.
My advice is to use a facade pattern. Create a new WCF service that is specific to your usage and wrap the 3rd party service. Clients would talk to your service and you would talk to the 3rd party. But clients would not talk to the 3rd party directly.
This would work in most but not all scenarios. I'm not sure of your particular scenario so YMMV.
BTW you can look at WCF RIA Services which is good for exposing services to Silverlight where you can avoid doing a lot of the hand coding of service stuff. But again depending on your particular scenario it might not be the best way to go.
Edit:
It's now clear that the API is too big and/or the usage patterns of the clients are too varied in order to effectively use a facade. The only other thing I can suggest is to look at using a code generation tool. Use reflection (assuming it is a .NET API?) to pull apart the API and then codegen new services using the details you gathered. You could look at the T4 templates built into Visual Studio or you could look at a more "robust" tool such as CodeSmith. But I'm guessing this would be some painful code to write. I'm not aware of an automated solution for this.
Is the API well documented? If so, is the documentation in a parseable format such as XML or well-structured HTML? In that case you might be able to codegen from the documentation as opposed to reflecting through the code. This might be quicker depending on the particulars.
Okay, hair brained scheme #1 on my side:
Use Visual Studio Refactor menu to "extract interface" on 'ApiClientEntryPoint'.
Create a new WCF service which implements the above Interface and get VS to generate the method stubs for you.
'For PropertyExposingAnInterface.SomeOtherMethodCall' You will have to flatten the interfaces as there is no concept of a "nested" service operation.
Your only other option will be to use T4 code gen ,which will probably take longer than the above idea.