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.
Related
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.
I'm debating whether I should use java RMI or standard Java networking for an application i'm working on.
The app will be a networked system that has heartbeat sensors and failsafe-features. So it's a 3-tiered system, with at least a DB and java application.
So if my Database fails on one machine, I'd like the 2nd machine to "sense" this.
I'm a bit confused about Java RMI, whether it's worth it to learn it.
Or if I use standard Java networking , I can do the same as RMI? I mean, if I really know the Java networking well.
Thanks!
These days it is pretty easy to set up web services using SOAP or REST. With REST you can use XML or JSON messages without really having to know all about it. All these types of services can be accessed from .NET code or PHP or Javascript. (Well ... SOAP is sort of a pain except in .NET and Java. //personal opinion )
Spring can help you set up a service and a client interface to it is pretty easy. Fairly close to standard Annotations on bean classes and business methods define the interfaces and Spring does the heavy lifting. (I'm talking about Spring Web Services and not the Spring Remoting, though that would work as well. Spring Remoting isn't much better than RMI IMHO.)
You can also use Jersey (JAX-WS) or Jackson (Parse JSON) to do the remoting. Standard Annotations on bean classes and what-not build the interfaces. CXF will do JAX-WS and JAX-RS as well. Those are Java standards for building services and clients that communicate via remote messages.
Alternatively there are eclipse tools for generating both sides of the remote interface. All are tied to some framework (Axis-2 or CXS are some). Its sort of a code generation thing.
You might want to look into these a bit and see which one resonates with the way you look at things.
I know that I prefer all of these over using RMI. But I haven't used RMI directly in a long time.
RMI is higher level protocol compared to the bare TCP/IP support in Java via Socket class that you seem to refer to as "Java networking". If the only thing your system does is sending heartbeats and there are just few nodes you should choose RMI for simplicity reasons. As all of the participants are JVMs there is no need for any interop and extra libraries to support that and as the number of participants is limited there is no need to consider anything fancy.
I'm writing my first client/server android app, and need an advice regarding server architecture.
My app is not a browser based app, but a stand alone client.
On server side i use hibernate/JPA and would like to transfer objects to client side.
What should I use:
Implement MVC- meaning writing servlets that will handle http requests (via Apache for example).
Write my own stand alone primitive server, meaning using simple sockets connection(in java for example), and handle each client in a different thread.
if you can think on a better way, you're more than welcome to share..
HTTP is definitly your choice since many carrier will block other protocols, since application servers/containers will take care of handling the multiple connexions and since it will also be a base if you decide to have a browser-based version some day ...
REST + JSON based webservices are well suited for android, given its simplicity, lightness and readability, but SOAP is also available via kSOAP2.
In my opinion. writing your own socket server is only warranted if you are required to implement your own wire protocol.
Most likely it's not a case for you.
So stick with http since it's widely adopted and has excellent client support in Android.
As for specific server side technology, you need to enumerate your requirements and do some research.
Don't start with Apache if plan to use Java, though. Pick Tomcat or Jetty. For framework, my personal choice would be Spring MVC.
Well, I have some experience in this very sphere and we used apache + php "covered" with nginx. I believe it's better to use standard approach, such Apache + PHP or Tomcat + servlets, cause it's easy to scale if needed and support... Of course it interesting to write your own application, but you might have some troubles with when traffic grows or server is down etc.
Where, when and why did you use ESB in a PHP-project?
Where, when and why do you think that it would make sense to use ESB in a PHP-project?
Does ESB (and ESB-facilitators like Mule) do provide any capability PHP and native LAMP-technologies are lacking?
Edit
My motivation for this question is stemming from my assumption that you actually never really need Mule. Mule will facilitate communication with external services which you could handle without mule. At the end of the day also Mule will create costs and overhead. So my question is steering at having somebody tell me about scenarios where you really benefit of ESB and tools like Mule or to second my guess with solid knowledge.
Edit 2
regarding Houcem's reply to my comment to his post ... what would be a native LAMP-answer to ESB/Mule?
Edit 3
Seems like Tuxedo might be a more PHP-native alternative to Mule/ESB. Somebody got experience using this tool?
ESB could be used in different ways :
Providing asynchronous processing : Example : If you have a web site that does a lot of emailing .. and sending an email takes a lot of time which may block the execution of your page : you may use an ESB to send the email data to Mule and route it to an Email outbound channel, this way you can say that you have implemented a mail message queue. Another form of asynchronous processing : using mule to execute php scripts (using command line) in a non blocking way.
Integration with java applications : You can send Messages to mule using php and implement some java business using mule API in java, php messages will be received by your java business components. This is used in big web sites which does a lot of complex processing and need flexible and powerful language like java.
What you need to know : ESB should be used like a Bus which means collecting data from heterogenous environments in a standard form (Mule messages) .. do business logic and then output data (after routing) to different environment
There is no native php integration with Mule in PHP world. To do it you should use web services (SOAP)
An ESB is a general solution to a scalability problem; a problem in managing the overhead, cost and complexity of a large number of application interfaces. I wrote a short article about the rationale for ESB/EAI solutions at http://psicom.com.au/solutions/eai
Admittedly, most PHP sites are small scale and would usually find it difficult to justify the administrative and technological overhead of an ESB. But it is now quite feasible to meet all of a business's application needs with OSS PHP products, and there is also increasing cost pressure on organisations, so I expect there will be increasing numbers of PHP shops that will start to feel the kinds of growing pains that I wrote about. This may make them re-evaluate their application integration issues, and an ESB is a good solution to that problem.
As far as I know there are no ESB products developed in PHP, and I don't expect to see this in the near future. But FWIW, many ESB products provide bindings for PHP and other OSS platforms, so the platform that the ESB runs on isn't crucial.
The ESB (Enterprise Service Bus) is a kind of backbone for the integration of the several heterogeneous applications of the enterprise, that may originate from different vendors, technologies, and even be redundant.
The fact it seems more linked to Java world than PHP or any other language is that usually big companies information systems are made of :
Mix of opensource development and software editors tools (including ERPs). Development are often made using Java EE in order to rely on Java EE stacks (and its vendors IBM, Oracle, ...)
Full Microsoft (no need of ESB, Microsoft provide EAI/ESB like tools)
PHP is most used for web application (even for big companies, but web oriented).
An ESB is a big cost, and is only usefull/needed when the number of interconnected application is raising.
When you have only few connections (between Java, PHP or whatever), you can handle it at a network level, using DNS, and at application level using configuration keys and performing protocol exchanges and small business integration for each point to point connection.
A potential use case for a PHP application would be an internet site of a travel agency quering multiple flight/train/hotels companies. And even in a such case, it won't be mad to develop a full cross quering system since it is the core of the business for such a site/company.
I would recommend Windows Azure Service Bus, which provides a PHP SDK here
https://github.com/WindowsAzure/azure-sdk-for-php
service bus is great but maintaining one is not. Windows Azure Service Bus solved all the maintenance overhead for you, and it is PHP compatible. You can even communicate with apps that are written in Java, C#, VS C++ from PHP easily.
To put it simple, I've written a JSE Swing app that needs to talk to a GWT server I've written earlier.
I absolutely love the way GWT does remoting between it's javascript and server sides and wish I could utilize this mechanism.
Has anyone managed to use GWT-RPC this way? Should I just go Restlet instead?
If you are doing Java-to-Java communication, RMI would be simpler and more expedient. Serializing data to/from some XML or URL-based format doesn't add a lot of value.
With EJB3, it is dead simple to deploy remote objects and to call them. You can then turn those EJBs into web services if you need to later, but for Java-to-Java, I can't think of a good reason to not use some sort of RMI-based communication.