So I have ASP.NET running on the server in IIS7. I think I'm going to use MVC for some static pages and basic dynamic forms - but the majority of the client side is written in Flash/ActionScript.
What's the simplest, most succint, most DRY way of building/generating proxies between client and server?
Which format should I use?
JSON
SOAP
Binary
And which comms protocol should I use?
WCF
HTTP via MVC Controller actions
I'm probably missing some format or protocol, but basically it should be relatively efficient, not require alot of plumbing code and preferably auto-generates client-side proxies.
WSDL web services are very easy to consume in Flash and simple to create in .NET.
I'd also suggest you at least look into AMF, which is Adobe's proprietary binary format for exchanging data between client and server. There are a couple of implementations for .NET, including amf.net and weborb.
I've never used it, but I've heard really great things about weborb: http://www.themidnightcoders.com/products/weborb-for-net/overview.html
i've consumed JSON in swfs .. pretty simple using a3corelib stuff
I have had a good experience with FluorineFX.net - It appears to be very similar to WebORB but its free and open source. I don't think Flash/ActionScript supports WCF..
You should note that (in the research I've done) there is no way to send a packed from the server to the client - the client must make all requests.
We use Weborb at my work. I highly recommend it. There are some gotchas with the way Weborb handles serialization on both ends. Just make sure in your .NET classes you don't have member names the same as class names.
EDIT: The free developer edition of Weborb should meet most people's needs. Weborb has the distinct advantage of speed, because it uses the binary AMF format to talk over the wire instead of JSON or SOAP.
I second WebORB. It uses the AMF protocol which is that fastest way to get data in and out. You can easily expose your .NET services and have typed objects going in and out. You can use RMI and Messaging. It's a free product and does a great job...
WCF supports Flash..! Done with "AJAX-enabled WCF Service" and WebInvoke(Method = "POST")
Related
I have been researching whether or not to use WCF for a new project we are going to be working on.
Basically the only reason which will prevent us from using it is the new project must be able to communicate with a legacy server which talks via .Net's TcpClient class with binary messages.
I am wondering if I can write a custom binding perhaps to send and receive messages from the server. I have managed to find that I can write custom bindings and encodings. But I am not sure if I can read messages as bytes and not soap messages.
One possible solution I thought of is to write a custom encoding which will transform the bytes into soap messages and vice versa. But I have not checked up on this or thought it through much.
Jason,
I'd suggest (not sure if this is an answer but I can't post comments, sorry),
you rather go with either a full sockets or a full WCF solution (meaning both client and the server).
Given you have a legacy server with via sockets - it's much easier to make a sockets client with some custom-protocol you have, and parsing, basic error handling etc.
...and you'll get it to be faster too (not sure what's the purpose, nature of the app and communication you're having with the server, or do you need some other WCF features etc.).
See this thread which is more or less your case...
WCF TCP client with Java Socket server on custom XML messages
...basically, you'd need to write a transport channel - which would again pretty much have to support everything that you'd need it to do for a 'sockets-only' client + extra work and layers.
That normally only makes sense if you're
a) going to reuse that for later on development, so e.g. you could just plug-in that solution for different servers or if you have many developers and large code base etc. (if you don't, making a sockets solution a separate lib and reusing is still easier) or
b) or you need some specific feature that ain't easily reproducible 'by hand and sockets' - still to support any of that you'd have to wrap it up pretty thoroughly anyway, or...
c) some 3rd party lib - that I'm not aware of for such cases (usually this falls into a 'too custom' work),
hope this helps some
Not sure if you've seen Carlos Figueira's series of posts on WCF extensibility but they're well worth a read if you want to understand what's possible and how to go about doing it.
http://blogs.msdn.com/b/carlosfigueira/archive/2011/03/14/wcf-extensibility.aspx
There is an example of a custom TCP based binding for JSON-RPC that you may be able to use a basis for a new transport binding in your case.
http://blogs.msdn.com/b/carlosfigueira/archive/2011/12/08/wcf-extensibility-transport-channels-request-channels-part-1.aspx
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 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.
the ways I can think of
Web service or soap
Socket
Database table
shared file
Any concise example you know of for webservice?
Web services or soap would be fairly easy, however, if the C++ application isn't a web server naturally (or the C# application), it may be easier to just use socket programming directly.
Sockets are fairly easy to use from both C# and C++. They give you complete control over the type of date transmitted, at the cost of potentially a little more work in the handling.
The biggest issues to watch for are probably endianness of binary data, and encoding of text data, if you use sockets directly. Otherwise, it's very easy.
Since you are already aware of the Web service and socket approach, I'll mention some other options. If you like simplicity, check out XML-RPC. This is what SOAP was before large standards committees and corporate interests began to control the specification. You can find implementations of XML-RPC for just about every major programming language out there. Hessian is an interesting binary protocol that has many fans and supports just about every major language as well. Protocol Buffers is popular within Google. The official version from Google does not support C#. However, the two highest rep users of SO do provide ports of protobuf for the .Net space.
I will probably be ridiculed for this, but also take a look at CORBA. It's not in vogue these days, but has many substantial technical creds, especially if one end of the communication is C++. IMHO, it's WS-* with OO support and no angle brackets required. For interop, I think it still should have a seat at the table. When engaged in C++ development, I found OmniOrb to be quite effective and efficient. Take a look at this SO Question for some pointers concerning using CORBA in .Net.
Sockets are easiest; and I would always go for that first. If database is an option, that's also trivial, but that would really depend. If it's queued events, that would make sense, but if it's request/response, it's probably not so great.
you can use gsoap to have a C/C++ program use a webservice.
You can also call a cgi program that is written in C++.
I have written a server in C that communicated with a C# client, and the endianess can be a pain to deal with, webservices is so much simpler.
Do you want it to communicate with each other (for instance, through tcp (like many others have pointed)) or do you want to be able to translate objects from C# to C++? If so, check out Apache Thrift (http://incubator.apache.org/thrift/).
What is the fastest way to share data structures between Java and C#? I want something where I can literally send a "car" object or a "foo" object and have it serialized and deserialized on both server and client.
WSDL (SOAP) is fairly interchangeable. If you want something less chatty, anything like Google's "protocol buffers", "ICE" (ZeroC), etc offer interchangeable binary serialization and code generation.
For .NET / C#, there are currently two viable protocol buffers implementations here; protosharp is essentially inactive and incomplete) - either would be fine, but neither currently has a complete RPC stack, so you'd have to handle message passing yourself.
You might be able to use IKVM, it's a Java-like environment on top of .NET; you could use Java serialization on IKVM and use interop to use the objects from "regular" .NET languages.
It looks like the IKVM seems like a good idea. But if that doesn't meet your needs especially since it is still in development. However, Uri's post points you in a good direction with the use of xml and passing messages, which can be built back together on either side.
Would you be able to use a SOAP web service on the server and have the client consume the web service?
The object's data structure would be described in the WSDL for the web service.