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.
Related
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.
I want to implement such logic: Client sends request to a server that has single controller. That server parses url and according to endpoints chooses another server to process the request. And the second server sends response back the same way.
I want to use Spring Controllers (MVC). I also can have several tomcat servers.
So: Client -> Main Controller that can determine the necessary server with micro services included -> the end server that process request, goes Database etc. -> Main Controller -> Client.
How to make tomcat knows about another tomcat?
How to make tomcat knows about another tomcat?
If that url(url containing another server details) coming from client, then you need to extract it from request and create another httpRequest and send it to another server(it will be server to server server1>server2) or initiate the redirect request(it will be server1>client>server2) depending upon the requirement.
See example here to send server to server http request
I also can have several tomcat servers.
You can also consider having multiple webapp with in same tomcat but that depend upon your requirements. Difference will be in this case there will be single jvm process . with multiple tomcat there will be as many number of jvm process.
I have multiple Java web applications deployed on the same server (Wildfly).
They all should use a single WebSocket implementation to send messages (object, not plain text) to the user.
Edit: WebApp1-3 are the applications with the business logic. The only purpose of WebApp4 is to update a Primefaces panel in the browser based on the messages generated by the other WebApps. Sorry for the missleading illustration.
WebApp1
WebApp2 --> ??? --> WebApp4 (WebSocket-Server) --> JS/Browser
WebApp3
Which is the best way/pattern/implementation to make WebApp4 available to the other applications? (RMI, JMS, WebSocket, WebService, ....?)
My advice, for a general way of exposing services, is to expose REST services since they are simpler than SOAP web service and easily allow interoperability (if in the future a PHP or a RUBY webapp needs to consume your services it's much easier with a REST interface than with one base on RMI or JMS). The content of the REST service may vary, I suggest you to look at XML or JSON as a way of transmitting information over http REST services.
If all webapps are in the same server, you should forward requests from one to another. From the point of view of webapps 1-3, they would not need to be aware of whether their incoming requests were coming from webapp 4 or from outside (to which it appears that they are not connected). Of course, you are free to alter requests before forwarding them - or to drop them altogether, for example if authentication fails.
To do this in tomcat: https://stackoverflow.com/a/8951090/15472
When forwarding requests, the external client is completely unaware of the existence of webapps 1-3 -- as far as the client is concerned, it has sent a request to webapp 4, and it will think it is receiving a response from that same server.
You may need to configure your web server to allow these kinds of calls, but I am unfamiliar with WildFly.
I have a system where several (20 or so) web app servers (hosting a website) talk to the same 2 - 4 EJB servers (through a VIP). I'd like to know if it is possible to identify which one of those app servers generated a specific request.
For example: Website example.com works by sending HTTP requests to any of 20 app servers to handle the request. These servers are named (internally) app01 through app20. It is ensured that all requests with the same session ID will be routed to the same app server, thus enabling us to logically track all requests from a single user. Some requests will need some extra data not available directly, for which there is an EJB (2.1) application on another cluster of 3 servers, named ejb01 to ejb03. Connections to the EJB servers are made through a VIP (ejb00), which routes the requests round-robin style to the three EJB serves.
Within the logging (we use Apache Log4J) of the EJB servers, it would be really nice if I could identify which of the 20 app servers a request originated from. The alternative is checking the logs on each server separately - but I don't have a good way to grep through the logs on 20 different boxes.
My question is: is this possible within Standard EJB? I'd be willing to do something non-standard, if there was nothing else, but it's gotta be reliable and work on my system. We use Weblogic 11g, both for the web-app and the EJB servers.
I've seen suggestions to pass the identity of the caller as a parameter, but that would mean an extra parameter for each of 20+ EJB methods, and that's rather unwieldy.
Any solutions, anyone?
There is no standard solution. There was a proposal in JSR 149, but it was withdrawn. Adding an extra parameter to the remote methods is probably your best option. If you're using RMI remote, you might be able to write an ORB interceptor to add a custom context on the client side, receive it on the server side, and set a thread local around the method invocation on the server.
WebSphere Application Server has a non-standard solution called work areas, which does work for remote EJB.
I am not familiar with WebLogic, so I don't know if they have a similar solution. Searching for similar terms finds a WorkContextMap that looks similar, but I don't know if it works for remote EJB since all the examples I can find are for webservices.
Can someone please let me know if we can use Restful web services or something similar to that to service HTTP requests without using a web server
All the Http requests are processed or identified by the servlet or ejb component in java.
1.We must deploy restful services server side code in webserver otherwise we cannot expose our functionality over the network
2.To access the rest resource we can use normal java program or any servlet or other.
3.Without using webserver you cannot expose your rest resource over the network at serverside.