I have a background in protocol stack - for 3g handsets. Now I need to communicate from an Android slate PC to a server, and I will code both sides of the interfacet.
Update: I ought to have said, from Android (multiple) slate to local server (multiple), then over satellite to a single central master server.
And now I think that I might not be implementing, just designing so looking for something easy for junior engineers to handle
SOAP looks ok, but are their any good IDEs to develop something for SOAP (or GSOAP) for Android (not sure yet which o/s the server will run; with luck I will get to choose).
Or should I just roll my own and use TCP/IP? (I have feeling, which I can't justify, SOAP might be quicker to develop and easier for others to maintain).
If I roll my own, I can just use C or C++ at both ends. IF SOAP, can I use C/C++ on Android (I know that I can if it's non-SOAP), or do I go with Java? And, if I do, should I then go with Java at the server, for maintainability?
Final note: I guess that SOAP will add an overhead and I will be doing this over a satellite link, where every byte costs.
Does any of that make sense, or do I need to explain it better?
Don't use SOAP if you control both ends. Think about JSON (or JSON-RPC) over HTTP or roll your own using prtocol buffers
SOAP is OK for B2B (remember that term, eh?) communications, but is very heavy and not pleasant to deal with. It might make sense to expose a SOAP interface to the outside world, especially in a Microsoft environment, but it is not ideal for internal use.
UPDATE:
If using SOAP both ends do not have to be the same language/library. There are some quirks, I'm sure, but generally interoperability while not great, exists. So you can use Java on the device and C++ on the server, or the other way around, doesn't matter. Regarding IDE -- for Java Eclipse has some relatively bad but usable plugins.
Now on to the satellite links... ARE YOU KIDDING ME? Seriously, depends on the size of your objects. If your requests and responses are going to be big, it might be tolerable... maybe. But if you are going to do a lot of small requests with short responses you are looking at 90% overhead. Check out these sample SOAP messages: http://www.w3schools.com/soap/soap_example.asp
Related
I am currently decide what kind of communication method/network protocol I am going to use for a new project.
What I can tell you about this project is that:
- It is Android/java based, using X amount of Android devices
- These devices should be able to send strings to each other over a local network. We are talking about small strings here. Small as in less than 100 characters.
- The amount of packages/transmissions being sent can vary "A LOT". I can't say how much unfortunately, but the network protocol needs to be as scalable as possible.
I have researched different kinds of possible solutions and is now deciding wether to use "Sockets" or "RMI"
As I have understood about RMI:
It is easier than Java sockets to implement and maintain (smaller amount of code)
It is "a bit slower" than sockets, as it is a new "layer" build on top of Sockets
There may be some scalability issues (if this is true, how "serious" is it?) as it creates a lot of new sockets, resulting in Exceptions.
Obviously the system needs to run as smooth as possible, but the main objective is to make it scalable so it can handle more Android devices.
EDIT: The system the system is not "peer-to-peer". All of the android devices should be able to be configured as the server.
None of your concerns are the real issue, in my view.
RMI has a pre-defined protocol, raw sockets do not.
If you use raw sockets, you have to do all the work to define what messages and protocols are exchanged by client and server.
There are so many good existing protocols (RMI, HTTP, etc.) that I'd wonder why you feel the need to invent your own again.
Android devices communicating over HTTP - tell me why it won't be fast or scalable enough. HTTP is good enough for the Internet - why not you and your solution?
I would suggest you to expose some kind of webservice (SOAP or REST) in your application server. For example, people frequently expose their data to mobile devices as a REST webservice API returning some kind of JSON format in order to make it easier to marshal it again in the client device.
This way you take profit of the underlying implementation of HTTP communication in every application server; any other way, you would have to write your own worker thread pool using nio primitive operations in order to achieve performance... Not a thing to be done in a real production environment - maybe in an academic one?
I'm a networking newbie and have explored a few frameworks such as Jersey and CXF for building RESTful web services in Java.
I have a new application that requires sending large amounts of binary data over the internet (between client and servers), and it needs to be extremely fast. I'm wondering if there is such a thing as a pure "TCP/IP (non-)web service", and if there are any open source Java libraries for building such things.
If all network services have to sit on top of TCP/IP, then I guess I'm looking for something that still uses binary data, but that introduces extremely little overhead for speedy service.
I always associated REST with XML or JSON; if it can be configured to be super-fast and work with binary data, I'd even be into that since I'm already somewhat familiar with Jersey.
I thought RMI might be a good choice, but not sure if it's not appropriate for this use case.
I need speed and I need a binary protocol, and not sure where to start. Any ideas? Thanks in advance!
Can´t you go with Java Sockets?
That is how low level you can go.
http://docs.oracle.com/javase/tutorial/networking/sockets/
Yes RMI is way faster than any high level transport abstraction like CFX. You have two options, raw sockets or RMI, RMI is easier to work with.
REST is an architectural pattern whose distinctive trait is using the HTTP verbs for what they were originally intended to. Even if the majority of deployed REST services use JSON to serialize objects, the entire HTTP transaction looks like this:
PUT /user/foo HTTP/1.1
Host: example.com
X-Auth-Token: foobarbazanythingyouwanthere
{"fist": "Jeff", "last": "Atwood"}
And the response is:
HTTP/1.1 200 OK
So, there is no real "overhead". Instead, you exploit the capabilities of existing libraries to deal with routing, authentication, serialization, and so on. Since HTTP uses MIME-like envelops, it has no problem with binary content, and even if this adds some overhead, it's very difficult to come up with a super-efficient, yet effective protcol, not to mention that you need to design it, implement all the libraries and -well- nobody else will ever be interested in your work.
Since you state you are a "network newbie", and since you seem to use terms like REST and RMI in a random manner, my strong suggestion is not thinking about performance and just go with standard technologies. You can use HTTP, there are lots of pre-built framework, servlet containers, server stubs, you name it.
Come back when you measure real performance bottlenecks, so that we'll have the figures to better assist you.
We want to write a UI that consists of HTML, Javascript (JQuery) and CSS. Although the initial starting point will be served up by a web server, there won't be any sever side templating. The browser will interact with the server via a restful interface and render its UI.
What are the risks of this approach?
Ideally I'd like a nice, straightforward javascript OO api which underneath makes http calls to the server to get JSON representations of resources. Any suggestions as to how this could be structured?
Anyone have experience with browser side templating?
Is there a framework to make this style of development easier?
We will also be defining the server side resources and my thoughts are to follow ruby on rails conventions. For example, if you define a Users resource in routes.rb, you have 7 uri templates. Any thoughts?
By the way, the server side functionality will be developed in java.
I have plenty of experience with this approach. I can guarantee you that it works - how well in the long run, I don't know yet but I'm extremely happy with it (as a developer).
You do need to make sure that you've mastered Javascript. Read up on the state of the art, at least check Douglas Crockford's work, and most notably JSLint.
As for frameworks, this is where your vision comes in. We've built one from scratch because we need a combination of tools that existing frameworks don't and because we think we have the vision and expertise to carry it through. You have to compare the pro's and con's. If you use an existing framework you have very little control over it's direction or the speed at which bugs are found and fixed. If you build one yourself you could run the risk of making wrong decisions and ending up with a framework that doesn't quite work.
I have noticed that in our applications the custom server side code is only very small. This means the importance of the backend is only very small (validation, sanity, authorization). We use PHP, but simply because we have loads of experience with PHP.
There are definitely risks. In the startup and early transition I have noticed that 'lesser' programmers have trouble catching up. There is a very steep learning curve for anyone not too familiar with Javascript and it's many elegances.
Another risk is performance. We're advising our customers to use Google Chrome, simply because
And then there is compatibility. The idea of a framework is that it's able to hide this complexity. Luckily browsers are increasing in-tune in accordance to standards but backwards compatibility with (for instance) IE6 is incredibly difficult.
I would advise against using jQuery. I find jQuery more of a 'plugin' than an actual framework. jQuery really shines when you have a website and you want to sprinkle on some fanciness. It has some very good general tools (DOM manipulation and all that) but it's very lacking in the business-modeling area.
I would also advise against an OO approach. For some very small number of domains OO is the perfect solution. For most businesses, it's not. And Javascript is capable of so much more than just OO.
The #1 problem (and, perhaps, the only problem) is search engine. It is not sure how well will your content be recognized/crawalble/searchable. The underyling cause is that the search engine is not necessarily going to understand your content (since it is only revealed once Javascript gets executed).
Other than that, it is a great approach. I tried it several times and it works great (assuming you're not intimidated by Javascript). The resulting web-site is usually much more responsive than traditional web-sites since the server -> client traffic is quite small - only the raw data is transmitted. All the UI stuff is generated, by Javascript, on the client side.
I have done some searching but haven't come up with anything on this topic. I was wondering if anyone has ever compared (to some degree) the performance difference between an RPC over a socket and a REST web service. If both do the same thing, which would have a tendency to be the better performer? I've already started building some socket code and would like to know if REST would give better performance before I progress much further. Any input would be really appreciated. Thanks indeed
RMI
Feels like a local API, much like
XMLRPC
Can provide some fairly nice remote
exception data
Java specific means this causes lock
in and limits your options
Has horrible versioning problems
between different versions of clients
Skeleton files must be compiled in
like CORBA, which is not very flexible
REST:
easy to route around firewalls
useful for uploading files as it can
be rather lightweight
very simple if you just want to shove
simple things at something and get
back an integer (like for uploaders)
easy to proxy security behind Apache
and let it take the heat
does not define any standard format
for the way the data is being
exchanged (could be JSON, YAML 1.0,
YAML 2.0, arbitrary XML format, etc)
does not define any convention about
having remote faults sent back to the
caller, integer codes are frequently
used, but method of sending back data
is not defined. Ideally this would be
standardized.
may require a lot of work on the
client side caller of the library to
make use of data (custom serialization
and so forth)
In short from here
web services do allow a loosely
coupled architecture. With RMI, you
have to make sure that the objects
stay in sync in all applications
RMI works best for smaller
applications, that are not
internet-related and thus not scalable
Its hard to imagine that REST is faster than a simple socket connection given it also goes over a Socket.
However REST may be performant enough, standard and easier to use. I would test whether REST is fast enough and meets your requirements first (or one of the many other existing solutions) before attempting your own Socket solution.
I have a bunch of Java code which was written using the Hibernate framework, originally destined to have a front end written using JSPs. However, the requirements for the front end have changed, and we've decided that a desktop client (which will be written in .NET) is a better match for our users.
I don't really want to waste the code that's already been written - can anybody suggest a good set of tools for writing a document-based web services interface that we will be able to access from .NET?
Thanks,
Jim
If you truly want a document based service interface (rather than an RPC style web service architecture), your best bet is going to be creating a SOAP based web service interface.
A quick glance at the Java site shows that the Metro stack might help a bit:
Java Web Services at a Glance
We're developing an application with the exact architecture you describe for a finance application. We reviewed several different options, and have finally landed on using compressed CSV over HTTP.
CSV was chosen since the vast majority of data was going to be displayed in a grid on the front end, we had very large result sets >250k rows on a regular basis, and it compresses really really well.
We also looked at using:
ICE, but declined on that due to licensing costs and the need to reinvent so much.
Google's protocol buffers via servlets, but declined on that due to lack of C# support (as of last fall).
Compressed XML using WOX, but declined on that due to lock-in to a small thesis project for support and XML being too verbose.
The industry supports a couple of different options as well:
SOAP, but that has its own well documented issues.
IIOP, J-Integra has a product called Espresso which will allow you to do RMI from a front end.
I'd personally use some lightweight RPC protocol, be it XML-RPC or a homegrown one. SOAP, IMO, is way too fat and is not as interoperable as it's supposed to be. The simpler the better.
We have a quite large application using a Java RMI server and IIOP.NET for interoperability. We have used IIOP.NET with the Sun RMI and the Bea Weblogic (now Oracle) without major issues.