We have two already running applications one is internet Java EE application and another one is intranet spring based application deployed in two different servers which need to communicate with each other for some functionalities.
1) What is the best way to communicate between these two applications?
2) In future after merging both functionalities, if we want to sunset one among these applications and make other use for both Intranet and Internet users what is the best suggesion to follow?
Option 1: Best option in my opinion:
Both the internet and intranet applications are running in your network. So take the libraries out of the spring intranet application and embed into the other Java EE application. There will be wiring required. If the internet application also uses spring for wiring then it should be smooth. Now all you have is one application running on same jvm. This might need time for integration and consolidation of data transfer objects.
Option2:
Within the intranet spring application create a wrapper service that exposes the service as a REST API. This should be quick to achieve and can serve as a short term solution. Later, use option 1 to merge them into a single application when you are ready. Another approach is to append modules in the intranet application into the internet application and expose the functionality.
Related
I am new to applications deployments in web servers altogether. Is it OK to add different instances of jetty webserver for two application - One data service and another angular UI application. Or Do I need to deploy the two applications from the same jetty instance.
Suggestions
Single jetty server hosting both applications
Use this approach when you own both the services and understand the RPS/throughout/latency/memory requirements of both the services. A bottleneck in one service can cause issue to another service
If the available memory/cpu/capacity is limited and hence don't want to waste additional memory for server by running another server instance
Both services are light weight
Both services are not deployed frequently or there is proper a BCP
Separate jetty server per application - preferably containerized(Docker?)
Provides good isolation to services
Control over resources per application
Easy to manage/scale independently depending on load
Easy to identify and fix issues
Personally, i would prefer to run them independently with or without containerization.
I have an application implemented in JavaFX and it will be migrated to the web platform, but it will take some time for that.
Meanwhile, I am struggling with some problems regarding its uses. Some users need to launch the jar from a network drive because their machines do not have access to the the database. Only the drive where the jar is located has access to the database.
My doubt is whether running the jar from the allowed network drive will solve this problem. In addition, can JNLP be a solution for this ?
I'd appreciate any help about this.
Some users need to launch the jar from a network drive because their machines do not have access to the the database. Only the drive where the jar is located has access to the database. My doubt is whether running the jar from the allowed network drive will solve this problem.
It won't work directly.
JavaFX is a client technology, it runs on a client PC. If the client PC does not have direct access to a database, then neither does a JavaFX application running on that client PC.
In addition, can JNLP be a solution for this ?
No, not for direct access to the database from the client if this isn't permitted in your network architecture, you would need a middle tier in addition to the JNLP based client to accomplish this.
Discussion of some solutions to this problem
Typically, the architecture of what you are describing would be built as a multi-tier app.
A client tier, which is the the JavaFX application or HTML javascript application running on a client machine.
An application server tier which handles server logic.
A database tier which hosts the DBMS.
There is a reasonable high level overview of such an architecture here.
Often, nowadays, the application server will serve REST APIs of JSON data, which a HTML based JavaScript web application can easily consume. Such APIs are also easily consumed using JavaFX applications which embed a REST client. An application server services the REST APIs and communicates with a database over JPA or JDBC as appropriate. However, than are many alternate technologies for client/server communication, and you can choose whatever you feel is a good fit for your application, development style and organization.
Spring product specific discussion
As you state your preference to use Spring, consider a JavaFX SpringBoot application.
Spring also includes a technology called spring remoting for facilitating client/server access. Spring remoting provides for multiple communication technologies. I'd advise sticking to the straight HTTP REST based technologies rather than other techniques such as RMI or AMQP as a HTTP REST based back-end can also serve as the backend for a standard HTML/JavaScript webapp which you also mention may be an eventual target client for your application.
If using Spring on client and server, checkout Spring's AsyncRestTemplate, and invoke JavaFX's Platform.runLater API inside the success and failure callbacks of the rest template. Or, use a Spring RestTemplate and control calls to the server via JavaFX concurrency mechanisms. Not sure which would be best for you, possibly the standard RestTemplate wrapped in a JavaFX Task.
Doing this in the correct manner will allow your application UI to remain responsive while it performs network activity (not block the UI thread) and also ensure that you don't violate JavaFX thread rules (don't access controls or modify data bound to JavaFX scene controls off of the JavaFX application thread).
I am learning to program Java. My objective is to create client server application based on Java and MySQL.
That would have following.
Server Application where all admin controls would be available to configure.
server application will be the only to have access rights to MySQL.
Server will have all functions and objects that clients will require and call and get that functionality. (Reason for that is "I don't want to share MySQL credentials to client apps or rather i don't want MySQL credentials to be transmitted on the network to clients"). As it would increase maintenance tough and it could be a security loop hole.
An analogy of functionality could be: client calls to server telling to add an Order such addOrder(order_id, payment,..,...,..) and so on.
What are the method in practice for such kind of application these days? A example code/or material to get in right direction would suffice
These days the universal way to expose a service remotely is via a web service. This solution was preferred by the industry over time due to its simplicity and ease of integration to the point that binary based protocols like CORBA are now seldom used.
Take the example of Android applications, they are native application mostly using REST web services.
A REST web service can be easilly integrated in the same way with a desktop application, a mobile application or a web application, even if the clients are written in different native platforms and languages.
As sample code, have a look at tutorials on the Spring stack. For the server see this tutorial for building an hello word REST web service. For the client, consider the REST template.
For security, see this Spring security hello world example. Using the Spring stack in Java will likelly give you the largest number of tutorials and online support.
This sounds like a good place to use RMI, which Java has built in support for. RMI will allow your client to call server-side methods on a local object that corresponds to the server, where all messages/commands get transparently sent to the actual server, where you have your DB access stuff and logic.
We are developing a java application which provide web services through SSL. This application is running in Tomcat server.
The purpose of web services is insert, update and select data. So under web service tier is implemented backend tier, which provide access to database.
Suddenly we were asked to build swing application which will also access the data in database. We want to use the same backend (exactly the same runtime) which is used for web service application. How to reach this goal?
I see following possibilities:
use web app instead swing application, which will be part of the same project like web service application and then it will be able to connect backend
Provide some extra web services for swing application only.
Use JMX. It is possible run JMX on Tomcat. Backend could provide functionality through JMX and Swing application could connect it.
Each of these possibilities have advantages and disadvantages. We followed solution 3 and I think it wasn't a clever selection. JMX has problem with generics, you can run only one JMX on tomcat etc.
Java world is rich and there should be some optimal solution for this situation. Could you help?
Add a web service client to the Swing app and let it make exactly the same calls to web services that a browser based UI would.
You're certainly free to add extra, Swing-only web services if you choose.
I didn't think JMX was anything other than a way to allow you to monitor MBeans using a JConsole. What does that have to do with Swing?
looking for someone to verify whether this approach is good or not . let say i have web app A run on tomcat. By deploying one webcache web app on the same tomcat. will that minimum the likelyhood that my web app crash due to overload by web visitors? if yes, what webcache should i used to implement this technique? or should i forget about webcache deploy this way and user service like akamai instead..? low cost is my main priority. looking forward to hear from you all
By duplicating on the same server/machine you gain nothing. When many users rush to the website, you would need more system resources to serve them and since these are shared by all web apps the second installation will be in as bad situation as the first one.
To properly cluster a web application you need more servers. You install Tomcat and your web application in each one and then use a load balancer to share the traffic. This is usually implemented with Apache Web Server and mod_proxy or mod_jk. Of course you need to pay for the extra server. One solution would be to deploy your app in a cloud environment (like Amazon EC2) and start the second server only when needed.
Another solution is to scale up, that is use a more powerful machine.