I am relatively new to web development, but I have some C++/Java experience. I have got the following conversion to do:
Current:
Desktop Application (Automation Software) developed in C# that communicates with remote PLC (Controller that overlooks different sensors in realtime) using TCP Sockets over the Web.
My Idea:
Convert the application into a server side software that will still communicate with the PLC over TCP/Socket. And use a browser to operate it, so the remote site can be monitored and controlled from any computer in our Intranet (possibly Tablets in the future).
Motive for doing it:
We had a computer fault which left the operators without control.
The new app:
I am planning on writing the server app using Java and OOP (so far no problem). And use HTML/CSS/Javascript for the WebApp and AJAX to update the page.
But I am still lost at how can I transport all this data between them in a proper and decent manner. I have read about SOAP and JSON in this Post. Although, I am not sure if I need to use them at all, is it a good solution to use either JSON or SOAP? Or is there any other solution that you may recommend?
Cheers,
Leo
If you consider skipping the development work to convert your app into a server-side software and just go for a third party solution, I suggest you take a look to Thinfinity VirtualUI.
"...offers a GUI remoting solution for in-house Windows desktop
developments, allowing them to be delivered as Windows/HTML5 dual-platform applications
simply by adding one line of code.
These Windows applications can keep their standard desktop environment behavior and,
alternatively, be accessed remotely from any modern web browser in a multi-user,
multi-instance fashion when hosted on a Thinfinity VirtualUI Server environment."
https://www.cybelesoft.com/docs/thinfinity_virtualui_whitepaper.pdf
SOAP is for defining public APIs that are published on the internet for other people to use, which does not seem like your use case. It is not particularly awesome to have to deal with it from inside a browser either, although there are javascript SOAP-client libraries. There is also going to be a fair bit more overhead on the server side parsing and validating XML than de/serializing between JSON and POJOs.
JSON is much easier to deal with in a browser, being natively understood and all that. Everything you need is built into the core of jQuery, no dependence on plugins that may have unknown levels of future support.
Related
I have to deploy some Java servers in a bunch of different networks. For each server, I need to monitor its status and send it tasks to be executed in that specific server. Something like distributed workers.
This servers would be used from different platforms and languages so I need to find a way to communicate with them and obtain the needed information. Which is the best way to do this? I've been reading about use JSONs to communicate with my servers but I'm trying to figure out if there is a better approach.
Another solution could be to have a web dashboard and control all through web petitions but I prefer the servers to be standalone. Any ideas on what I can do?
At the moment I would suggest REST interfaces for your Java server. Since REST with Json is easy to implement in other languages too and you can even use HTML and JavaScript to write a Monitor client. So from my point of view this is the most flexible solution.
An other solution would be to use XMPP to "talk" with the server and "ask" them about there state. I remeber this as a solution for machine to machine communication, but this was before the Json and REST boom so I would not suggest to go with this.
When your other platforms consists of Java and C# mostly SOAP could also be a solution, since there are good code generator for both languages which can create the WSDL from code and vice versa. But its kinda difficult to use SOAP in JavaScript (as far as I experienced) and maybe other languages have the same problem with SOAP.
If multiple platforms are involved, web services are probably your best bet. You can have you java servers expose web services (for status and task execution) and you can call them from anywhere/any system.
I am new to mobile application development and wanted to know from experts here on how they approach the server-side design. I need to support cross platform clients (iOS, Android, Windows) and require a scalable backend architecture.
What are the widely deployed server-side strategies
Are there any Mobile specific open source server-side technologies available.
What factors people consider for mobile application back-end.
I agree with half the answer above. You should use REST architecture - it is the most straightforward way to go. I use Ruby on Rails for my mobile projects. It is quick to start building the server code and see it working in somewhere like heroku.com almost instantly.
So I'd pick the following:
ruby on rails - worth your time picking up
heroku.com for deploying / or EC2 if you pick the Rubber gem
Google App Engine is another great option if you know some python / java
REST architecture
store all your heavy images etc with Amazon S3. They have some great SDKs to work with.
get yourself some JSON libraries to communicate with your server
on iOS:
use MKNetwokKit (it will save you lots of trouble down the road. it helps you cache and its a nice architecture all around).
if the app is small, try a data model based on NSArchiver instead of CoreData (SLOWWW). Mogenerator is a good start (this isn't server related..)
If you hate writing server side, I'd advice you to checkout Parse.com. Completely mobile only development with all server code handled for you. For big projects, you really should write your own server stuff.
Some extra things I'd consider:
how would the security work? just a session token in the HTTP header?
tier your app -- networking / MVC
what happens when you're offline? - this is currently something we're dealing with after not having thought early - pain.
I've had good success with creating a server using REST web services and XML data, but would recommend JSON instead. You can create this using Java and host it using Tomcat. This is widely deployed and widely consumable by multiple mobile and even non-mobile technologies.
A couple of factors to consider:
* You'll probably want it in a DMZ and being Internet accessible so think about firewalls, reverse proxies, and encryption via SSL.
* Will you host the server or sell the server to customers? Hosting is easy. If selling, there are many more considerations.
The company I work for has a powerful Java based server component framework for interacting with special control systems.
We have a UI framework but this is also Java based. A customer can use a Java Applet to access control information etc.
I've recently started working on a rich JavaScript API to access this control system information remotely. It's currently a prototype. It's nice because anyone who's familiar with JavaScript can access our Components remotely. So far it works really well. I've written some prototype applications that use this API. This gave me an introduction to jQuery - great! I've also added the ability for the JavaScript API to make RPC calls to Java as well as a session based Component architecture for when you really need something held on the server.
So far so good. I have to admit though that I'm not really a 'web developer'. I've never used Structs, Spring or any of the MVC based architectures for serious Enterprise based web development (I AM very familiar with design patterns though). My background is application development.
I'd like to know from the pros whether this is the right approach or whether I'm missing anything. Someone I work with has created a really neat Server Side Include architecture. However, I'm wondering now whether this is really necessary? After, I think I can create just about anything using my JS API and jQuery. Should I consider any other 'server' based architectures in this new age of open web apps?
As far as browser support goes, I'm not concerned about the older generation of browsers (please no lectures here, the old technologies we've got will do for IE6 and alike).
By using this open client side technologies, I'll be able to write sophisticated open web apps. Very little server side code will be needed in reality because of my API. I'll be able to take advantage of HTML 5 features etc. But am I missing anything? Should I be considering other server side based Java technologies like Server Side Includes? Am I too client focused?
Well there are four ways to create modern RIAs: HTML5/Javascript, Java Applets, Flash/Flex and Silverlight. Only the first two are open.
Applets are a nuisance and not really liked by people. Personally I'd go with HTML/Javascript.
Since you are a Java shop I'd recommend going with GWT for the following reasons:
It's open source with business-friendly license.
It creates minimum-size browser-optimized javascript.
It's actively developed and used by Google. This is a guarantee that it'll be supported for some time.
There are a lot of developers with knowledge of it.
It has good documentation and very active user group.
I'm sure there are many opinions on this, but my take is that with HTML5, faster Javascript interpreters, client side persistent storage, etc. it makes it pretty compelling to put all the UI application login in the client (browser), and just use some form of RPC (with JSON serialization) to the server. Therefore templating engines, SSI, or any server side generated markup is no longer required for interactive applications. It's still fine for semi-static documents. For that I use sphinx document generator.
Fast-forward two years, and you now have TodoMVC at your disposal to help answer this question. GWT is still mentioned, though as far as server-side technologies go, The Holy Grail is probably what you're looking for to maximize code reuse on client and server.
I was looking for some opinions on the best remote method invocation practices when developing iPhone applications that communicate with Java (java EE) servers.
Many iphone applications these days typically talk to a server back end. I typically prefer to write my servers in java using some Spring libraries. So far I have not found or stuck to a definitive practice for iphone->java server communication.
What are some technical solutions and libraries that you have used to implement this kind of client-server communication?
One thing I always keep in mind is that I want the communication protocols to be simple so that multiple platforms can be added for example, in future adding Android and possibly Blackberry clients, that can use the same protocol to talk to the server.
I'd go with JSON. If you want to use Spring, go with restful webservices. Do some googling on "webservices restful spring json" (without the quotes) and you'll get some pointers.
JSON will suit you fine with other languages as well. I've written an iPhone application that uses JSON, and that was quite easy with the use of
http://code.google.com/p/json-framework. I'm pretty sure that both Android and Blackberry should be capable of reading JSON just fine as well.
Edit: I forgot to mention that I have put this iPhone application under an MIT license and you can browse the code on google code:
http://code.google.com/p/accountadmin/source/browse/#svn%2Ftrunk%2Fiphone%2FFrittRegnskap%2FClasses
I'm currently doing this for work as well. Our backend is Java EE (with Spring) and then of course the front end is iOS. We use JSON as the payload format, as Knubo suggested. All of our web services are also RESTful to make dealing with URL construction and authentication on the phone easier.
I would highly recommend you check out RestKit, which is a pretty comprehensive framework that allows you to easily integrate your RESTful, JSON-based web services with CoreData. We also use YAJL for parsing JSON manually in the rare cases where that is necessary.
Thus far, that tooling has made it a breeze to work with our web services.
http://code.google.com/p/json-framework is really useful.
Are there any what in the Java community would be called "application servers" for .NET? Similar to Tomcat, Resin, and Jetty. I'm not interested in a JSP equivalent, I'm looking for a servlet-based technology for XML/HTTP transaction processing (no UI).
If there is not a product like this, what would a good stack be to emulate this?
Microsoft appears to have dodged this by saying that Window Server + .NET + IIS + your code = app server, but it seems there is a lot of plumbing code that has to be written in order to get to an equivalent place as say Tomcat.
WCF or web services (ASMX) both seem like good candidates for what you want. WCF is probably more appropriate if you don't want to go the full SOAP route. You can host WCF in IIS, a console app, or a windows service. Depending on what you need it can use SOAP, simple XML, or even Json for encodings. As for transports you can use HTTP, IP, or Message Queues.
Dublin will be what you’re looking for, I guess.
I think you are looking for Http Handlers. You can handle the request at a low level without an aspx page. MSDN Reference
Since Microsoft enteprise applications are not targeted to run on any platform like Java, there is less of a need for a .NET equivalent to the Java app server like WebLogic or WebSphere. Many of the technologies provided by the Java app server are provided by either the Windows operating system or the .NET core library. You can draw direct comparisons between individual technologies such as JMS vs. MSMQ, but less so in the overall architecture.
I'm not interested in a JSP equivalent, I'm looking for a servlet-based technology for XML/HTTP transaction processing (no UI).
Sounds like what I do all the time. I use WCF for communication and host the program as a Windows Service. Windows Services have lots of nice things like remote monitoring and the ability to automatically restart in the unlikely event it crashes.