I have a Client Server Application which is Java based with Spring for the server.
Now I have to replace the Java client with a web client.
I have three different achitectur concepts for implementing the webserver and linking it to the appliation server. But I'm not sure which I should use. I'm not really firm with web applications, but I think this is not a pure decision by the web client.
Can someone please give me some pros and cons for the different concepts or please tell me if my concepts have mistakes.
These are the concepts:
Useage of an embedded web server in my application server.
Pro: I must not implement any session handling between the web server and the application server. The webserver can use the data storages of the application server for requests. Cons: The customer must decide if an application server is allowed to start their own web server. And I'm not sure if it is a good style to mix the web ui logic with the business logic of the application server
Embedd the business logic with the web ui in a war for a stand alone web server.
Pro: Basic Security stuf like https handling will be done by the web server. Maybe more accepteable for the customer regarding the deployment. I must not implement any session handling between the web server and the application server. The webserver can use the data storages of the application server for requests.
Cons: The application server has a lot of memory and cpu useage. The is maybe a problem for the web server.
Embedd the web ui in a web server and link it to the application server via socket connection. Pro: strict separation between ui and business logic. The application server must not be changed, because the socket connection between web server and application server can use the existing socket connection for the fat client. Cons: The handling of user sessions must be handled two time. First the web session and second the session to the application server. Furthermore the web server must set up his own storeages for data and must keep them in sync with the storeages in the application server.
My first thougt was to take the first concept because I have every thing in one application.
But my second thougt to use the third concept because of the strict separation and the benefits of a real web server. But here my problem is the handling of two sessions for each user. Or are there better concepts?
Thank you for giving me input!
Your 3rd approach is better. Keeping application server separate will better serve different clients like Java clients, web clients etc.
It will separate 2 different concerns. If there is a UI related issue , then you can bring down the UI server and fix it. But your other Java clients will work fine. Moreover it will be better from development perspective as well.
Related
I am working on a project where I have two servers (tomcat), Server A gives initial snapshot of information from DB(MySQL) to the frontend. Server B to serve updates to server A, both servers need to communicate. How do I connect them? Thank you very much for your help.
There are many ways two Tomcat instances running on the same host could be set up to communicate with each other. It's quite common to implement a REST service in the "server" Tomcat instance and have the "client" Tomcat instance send the REST request to the other instance. It's common to use either the Jersey or CXF framework to implement a JAX-RS REST service, or you could use the Spring framework to implement a more general web request handler.
Tomcat typically accepts HTTP/S requests. So you could program your own servlets in Tomcat A (and publish them as URIs) to accept data which shall be updated to the DB. Then, Server B must act as a client to server A, initiating communication whenever it wants, and sending the data to Server A as HTTP requests.
Taking security into account, I'd also suggest that Server A should forbid any requests to the updating URIs which do not come from Server B. For instance, securizing the updating URIs through standard JEE security.
I have my server side plugin, i have to send some value from my server to another server hosted on 2 different locations.
1. Server Side plugin - Hosted on some server i dont know where it is.
2. Web Application - is my application and hosted location i know.
How to exchange data from that server to my application.
We have the privilege to deploy the plugins in some folder but i dont know where it is hosted. But i can use approach to send data.
Please let me know!!!
Regards,
Chandan
There are many solutions to exchange data between different servers:
Shared database
Shared filesystem
exposure of restful web services
exposure of soap web services
rmi
socket connection
shared application that operates as a bridge between the two servers
Each solution has pro and cons. Some needs polling (shared database and filesystem for example), some others not. Some needs just an exposure of a port (web services, socket, web services) other needs additional requirements (for example a shared database needs a database and that database must be visible to both applications).
Generally if you need very fast communication with high traffic load the best solution is a socket (as for client server in databases for example).
Otherwyse choose a solution more human readable and simpler to code.
I have developed a Java database application that has been deployed to users via a web server. Now, all is good but it has been requested that some of our external clients would also like access to the software. Is there any way that I can make the application work for these clients? The application has been put on another web sever that is accessible for external users and also has visibility to our SQL server but the application is not working, it will load in the browser but users cannot login to the system which works by database authentication. Am I missing something simple here or is this something that can't be done. I would imagine the latter since I think the web start application downloads to users machines which would explain why you can only login when a VPN connection is active.
Any help on this matter would be greatly appreciated.
Most definitely your firewall blocks the connections to your database when they are initiated from the outside. This is a good thing because you generally don't want to expose a database to the Internet.
One hacky way to do it would be to implement some kind of JDBC over HTTP to tunnel the database requests. Basically you'd use a JDBC driver that redirects the SQL requests to a web server.
A better way would be to refactor your code (I presume that would be a lot of work though...)
If you manage to abstract the data access layer, you can replace it by something more suitable for a web access, for instance a Web Service.
Finally a drastic option is to transform your client/database application into a webapp.
We are currently are at a stage in our product lifecycle where we are thinking about moving to Web Services. Our system is written in Java which consists of a number of client and server applications which talk to one another over TCP Sockets and also has in-line SQL to perform data retrieval and updates (yuk! I know) which uses our own SQL Connection class which then uses the java.sql.Connection to connect to a SQL Server database using the Microsoft JDBC driver.
The applications bind to one another using TCP sockets. They request data from and push data to one another. Which works perfectly fine.
Thought
So we are looking at converting all data access and TCP communication to a web service.
The web service would be designed to run on a companies secure internet site. The idea would be that users could connect their clients to the web service from home - when they are not on the company network - or at work, when they are.
The client applications would send/recieve the messages to/from the server side applications using the web service.
The client applications would retrieve and update data in the database using the web service.
Question
I would just like to know what peoples experience is of doing anything with 2 way communication (request and push) over a web service (if possible) and what the thoughts are about doing this.
Converting the data access to a web service seems straight forward enough - I can forsee some issues with performance where large data sets are retrieved in some parts of the system.
I am looking through various reading materials on the matter as it is a while since I have touched web services (using C# and ASP.NET). Currently reading "Building Web Services with Java™: Making Sense of XML, SOAP, WSDL, and UDDI". I must admit I thought web services were always stateless but have just read that they are not!
Thanks,
Andez
It helps to think of WebServices as being the same as any other web application on the transport layer. It uses HTTP/HTTPS protocols in the same way, it's just that instead of sending HTML, it sends XML according to a predefined format (SOAP). As such:
It's Request/response oriented
Can be stateful in the same way as a web-page can be stateful, using sessions (assuming you have a web-service client that supports maintaining session cookies across requests)
All requests eventually boil down to good old-fashioned servlet endpoints in the server
Keeping these limitations and features in mind, think about your requirements and how they map against each other. If you need true two-way communication (push), then web services are not ideal. They are client/server, request/response oriented. The achieve push, you would have to poll from the client. A possible alternative could be to let both the "server" and the "client" act as web service "servers". That would mean bundling some light-weight servlet engine with the client (like jetty) so the "server" could make web service calls TO the "client". Another way is to look at two-way RMI/IOOP.
Yet another way would be to keep the communication layer as you have it today. There is no inherent gain in refactoring to Web Services just for the sake of using web services. If they don't add any benefit, it's just waste. As you already mentioned yourself, Web Service comes with a load of additional overhead (verbose protocol, servlet engine etc), so it really needs to balance the extra cost and development time with a clear benefit. As the saying goes "if it's not broken, don't fix it". As you say the current solution "works perfectly fine", I would probably not change it. That's just me though.
I am working on a server application that does the following:
Read data from a measuring device that is being addressed via a serial interface (javax.comm, RXTX) or sockets.
Exchange data (read and write) with another server application using sockets.
Insert data from (1) and (2) into a database using JDBC.
Offer the data from steps (1) to (3) to a JavaScript-based web app.
My current prototype is a stand-alone Java application and implements task (4) by writing the data to an XML file that is being delivered to the client via a web server (Apache), but I consider this to be a hack, not a clean solution.
This server application needs to start up and work also without any web clients being present.
I would like to integrate this server application into a Java application server, but I do not have much experience with these technologies and don't know where to start. I have tried some simple examples for TomCat and GlassFish, but that did not bring me any further because they are all built around serving web requests synchronously and stop where it would be getting interesting for me.
Is this possible to run such an app within TomCat or GlassFish?
If yes, where would be a good point to start (examples, which base classes, ...)?
Would it make any sense to split the application and implement only task (4) in a servlet, the rest in an ordinary application, communication via sockets, etc.?
Would other servers, e.g JBoss, be a better choice and if yes, why?
Edit:
The reasons I want to use a Java EE container are:
I would like to have a clean external interface for step (4).
On the long run, the application will need to scale to a huge number of simultaneous clients (at least several 10.000), so a want a standard way of scalability and application management.
In general, it's not a good idea to implement all of this in a servlet container such as Tomcat.
A servlet container is designed to service requests from a client. It sounds like you have a process which will be running all the time or at least periodically. You can do this in Tomcat, but it's probably easier to do it outside. Leave Tomcat to do what it's good at, servicing requests from browsers. It's happiest when the requests are short lived.
So I would do as you suggest, and only have step 4 in the container. You can easily interrogate the database populated in step 3, so there is no need to create web services to populate the servlet container.
For step 4, you will need to expose some services from Tomcat, either through rest, soap, whatever you like. The javascript clients can then interrogate these services. This is all completely doable with Tomcat.
For scalability, there shouldn't be a problem using Tomcat. If all it's doing is pumping data from the database to the client, there probably isn't a reason to choose a J2EE container. If you don't have need of complex transaction management or security, try using something open source. It sounds like you can get what you want from Tomcat (& hibernate & spring security if necessary). If you start to have performance problems, then the fix will probably be the same for JBoss & Tomcat: you need more servers.
My advice: stick to the simple open source solutions and move to an application server only if you find it to be necessary.
I would loosely couple the solution and not try to do everything on the Java EE/Servlet container as exchanging data using sockets (managed by the application itself) is not something you typically want to do from a Java EE/Servlet container.
Running this on a Java EE container might also be overkill as this doesn't sound like a typical enterprise application where stuff like security and transaction management is important and the app could benefit from services provided by the Java EE/Servlet container.