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.
Related
My project is looking to deploy a new j2ee application to Amazon's cloud. ElasticBeanstalk supports Tomcat apps, which seems perfect. Are there any particular design considerations to keep in mind when writing said app that might differ from just a standalone tomcat on a server?
For example, I understand that the server is meant to scale automatically. Is this like a cluster? Our application framework tends to like to stick state in the HttpSession, is that a problem? Or when it says it scales automatically, does that just mean memory and CPU?
Automatic scaling on AWS is done via adding more servers, not adding more CPU/RAM. You can add more CPU/RAM manually, but it requires shutting down the server for a minute to make the change, and then configuring any software running on the server to take advantage of the added RAM, so that's not the way automatic scaling is done.
Elastic Beanstalk is basically a management interface for Amazon EC2 servers, Elastic Load Balancers and Auto Scaling Groups. It sets all that up for you and provides a convenient way of deploying new versions of your application easily. Elastic Beanstalk will create EC2 servers behind an Elastic Load Balancer and use an Auto Scaling configuration to add more servers as your application load increases. It handles adding the servers to the load balancer when they are ready to receive traffic, and removing them from the load balancer and deleting the extra servers when they are no longer needed.
For your Java application running on Tomcat you have a few options to handle horizontal scaling well. You can enable sticky sessions on the Load Balancer so that all requests from a specific user will go to the same server, thus keeping the HttpSession tied to the user. The main problem with this is that if a server is removed from the pool you may lose some HttpSessions and cause any users that were "stuck" to that server to be logged out of your application. The solution to this is to configure your Tomcat instances to store sessions in a shared location. There are Tomcat session store implementations out there that work with AWS services like ElastiCache (Redis) and DynamoDB. I would recommend using one of those, probably the Redis implementation if you aren't already familiar with DynamoDB.
Another consideration for moving a Java application to AWS is that you cannot use any tools or libraries that rely on multi-cast. You may not be using multi-cast for anything, but in my experience every Java app I've had to migrate to AWS relied on multi-cast for clustering and I had to modify it to use a different clustering method.
Also, for a successful migration to AWS I suggest you read up a bit on VPCs, private IP versus public IP, and Security Groups. A solid understanding of those topics is key to setting up your network so that your web servers can communicate with your DB and cache servers in a secure and performant manner.
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.
My company has plans to implement a clustered system with a lot of services that will be deployed automatically in different machines and will interconnect with each other (SOA style). Sometimes the services will have interdependencies.
For example:
Service B (application) can be started up only when the Service A (Database) is up and running.
Each service is planned to be run as a different java process, possibly deployed as a WAR (inside dedicated tomcat) or even without web at all.
For now we have all the services in the same WAR and only single tomcat that deploys the WAR.
All the services are defined via Spring and Spring manages dependencies for us.
So I'm asking myself whether exist some frameworks that will help to manage the services in a distributed environment as I've described above?
Thanks in advance
Use ZooKeeper.
Correction, use Netflix's Curator, a framework on top of zookeeper which simplifies the work with it.
Where I work I recently implemented a Coordinator class which has two methods:
waitForDependencies - a synchronic method that checks for the liveness of the current service's dependnecies and blocks the current thread until notified that all dependency services are alive. The liveness check is done by verifying the existence of nodes which are created by the depenedency services, at the end of their initializing process, by calling notifyUp
notifyUp - a synchronic method that notifies the world that the current service that calls that method is alive. The notification is done by creating an ephemeral (temporal, stays alive just as long as the connection in which it was created is alive) node in the zk cluster, which is looked for by other services which depend on it, using waitForDependencies
Netflix released their open source tool - Asgard that manages and deploys instances to a cloud. It is tightly coupled with EC2 (the last time I checked). Depending on whether you deploy to the amazon cloud you might find that useful. I'm unaware if it supports dependencies but it does manage deployments on a distributed environment. Netflix does talk about service dependencies a lot on their blog, so the deployment solution might have a feature to solve for that.
I'm not aware of any other service / framework that does this. If you were to write this on your own I guess you could configure a couple of Jenkins tasks that deploy services. One task can depend on another to simulate the service dependency. Pinging URL endpoints can check if Service A exists before B is deployed.
There's another way to look at this. You would not need to check for dependency if you ensure your services are all running properly. Monitoring tools like Nagios can help here. Troubleshooting faulty services immediately can help you focus on deploying Service A instead of checking your dependencies on each deployment.
We are working on a SOA Project consisting of multiple web services.
Each web service is based on Metro JAX-WS Framework and internally uses spring and hibernate.Each web service loads as a web-application inside a separate spring container.
This means that our deployment architecture consists of multiple web-applications each running a different service.
However we are facing some performance issues because each web-application loads its own spring container/hibernate session factory.
Possible alternatives:
Single web-application single spring context
Multiple web-applications single spring context
All our web services will always run together on a single server. What will be the best architecture for our case? And how to achieve the same i.e. how to use a single spring context with multiple web services?
The "best" in "the best architecture" is quite subjective, as it depends on your current architecture, which you haven't defined very well.
However, I have some suggestions:
Consider the impact on maintenance that consolidating all the business logic related to your services in a single web app will have, not to mention all the spring-configured-beans that you will have to inter-mangle to re-factor all you services. In that sense, keeping separate web apps tends to be better according to my experience.
Consider to move the hibernate session factory away from each service and to a centralized location, for instance, in JBoss, you could create some type of "hibernate interface" in the way of a .HAR file, each service will only have to "ask" for a hibernate session. Maybe you could do something like that in your particular application server. There are several patterns to efficiently retrieve a Hibernate Session that apply here.
Most web services performance issues are also associated with the way they are used, sync or async. We solved one such issue at my company by implementing a messaging systems under the covers to handle the web service requests asynchronously, whenever a request comes in you place them in a Queue, there are other services waiting for certain types of requests to process them. This can be easily implemented with Spring and ActiveMQ.
That's enough for the moment.
Regards.
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.