Please help me to choose right (stable and safe) approach for my task. I have web application implemented with Spring MVC on Apache Tomcat.
To provide some service I need to make a connection to an external application over network. Also, I have to support specific network protocol with this software.
In this situation my web-app is a client, external application is a server. And also, external application could be run in many instances, so my web-app has to open many sockets.
Each connection should be supported asynchronously, so it seems to I should create a thread for each connection.
I thought I could create a ContextListener for dispatcher servlet of Spring and implement events of life-cycle: init and destroy. So here I could create and start my exotic service on initialization stage and shutdown it on destroy stage.
I realize that my solution might be not accurate enough. May be I should use TaskExecuter or something else. I'd be interested to know what would you advise me.
Thanks a lot!
Since you are already using Spring MVC, it may be easier to simply use Spring's lifecycle callbacks to do the initialization and the cleanup.
You could create a singleton service bean for each external peer (or multiple ones with different configuration settings if they would be identical otherwise) and use them as standard Spring-managed services.
why are you trying make a Service for it? your web application (client) can simply use a Abstract Controller to call/request data from external application and show response on browser, upon any given event...
please be more specific about what you are trying to do
Related
For my Spring-based web application, I now have the requirement to send out weekly e-mails to my application's users.
What are elegant solutions to this requirements?
Up until now, I have come up with the following possible solutions:
a dedicated cron job that I schedule to run once a week, running independently from my web application JVM process and outside of the web application Servlet container. This process takes care of sending out those weekly e-mails. To accomplish sending personalized e-mails, it reuses domain classes (such as my User class) that I have already developed for my web application. This dedicated process accesses my application's MySQL database concurrently to the running Spring Web MVC servlet?
a scheduled mechanism inside my Spring Web MVC servlet or inside my Servlet container.
In this setup, the e-mail sending happens inside the same JVM and the same servlet container as my web-serving Spring Web MVC servlet. Maybe this setup has (irrelevant?) advantages such as "database connection pool sharing" and "transaction sharing" "class sharing" with the servlet hosted inside the same environment.
Using or not using Spring Batch, for any of the above conceived setups. I have no experience right now with Spring Batch as to judge whether Spring Batch is or isn't an adequate tool for my requirement.
Maybe there are other solutions as well?
I am especially interested in answers that can give insights and guide in making an educated decision.
It is irrelevant for this particular question whether e-mails get sent with my own infrastructure or with a third party e-mail SaaS service.
From your description, the code for generating newsleters must share common code base with your main application. So the natural solution is to develop this code withing your main application. The open case is how this code is triggered:
From CRON. You start a script from CRON that would trigger the function within you application somehow. This somehow may be a process listening on specific port, or, what is quite natural for web application, a dedicated URL that would trigger newsletter. Just make sure that URL can't be run from outside, only from localhost (check caller IP, for example). You must, however, deal with the situation, that your app is down (restarting for example) when CRON launches the script.
From within the application. For example, using Quartz. The minus is that you need to include new library, create database tables for Quartz. The plus - Quartz will handle situation, when the task was scheduled on the moment when the application was down, because it stores the information about what was launched in DB.
We always use cron to fire a JMS message to a queue and have a dedicated process which consumes these messages. You can add the email contents to the message or just use the message as a trigger. The nice thing about this approach is you can fire in a JMS message from anywhere and have multiple handlers lots of different email scenarios. The only downside is installing a JMS broker, if you don't already have one...
I am building a Spring-MVC based web application which is required to send a weekly newsletter to a small group of people. I am using Spring's built-in scheduling mechanism. http://static.springsource.org/spring/docs/3.0.x/reference/scheduling.html‎
Yes, in this setup, the e-mail sending happens inside the same JVM and the same servlet container and it is quite easy and handy to implement the solution. I am observing the stability and reliability of this mechanism and cannot feedback more about it now.
I'm doing a project, splitting the whole application into frontend and backend (skipping database part first) and use jms as frontend and backend communicating platform. Frontend will be web-based, so we write jsps and servlets, packaging as war and deploy to application server(oracle weblogic). But for backend, since it has no user interface (just pick message from jms, new a thread to do db operation using JPA and do business logics and send result to jms), should I use application server to run my code?
I've tried putting code into regular application server, wrapping backend thread starting code in servlet context listener, storing started thread into servlet context, and everything seems to be fine. Spring part seems to work too. Is this the right way?
If I choose not to use the servlet way, how should i package my code and deploy to application server? The entry point of the code will be what class?
Please refer Spring components for handling JMS.
In short, you can define JMS Listeners and use Message-Driven POJOs. This is the simplest way I can think for a project which is already using Spring.
EDIT:
You can define you own start up class which will start on the start up of the server e.g. documentation for Weblogic Startup Class.
I am a little confused about the roles of a java application server and its differences from a web server.
I found many sites explaining the same difference between the two but not to my satisfaction.
So please explain me about the two following cases:-
1)App. Server and its difference with web server:
From these two links:
Difference between an application server and a servlet container?
What is the difference between application server and web server?
web server: It handles everything through http protocol by accepting requests from clients and sending
responses to them with the help of its servlet container(e.g Apache Tomcat)
App. Server: An application server supports the whole of JavaEE like JMS,JPA,RPC etc.
Now what I am confused with is that how can I use a lot of JavaEE APIs like JMS,JPA etc. with my Tomcat
by adding their jar files in my web application ?
Does that mean that if I use an appliation server I don't have to add those jar files?(I don't think so)
2)The roles of an appl. server (This is very important to me)
From Wikipedia
http://en.wikipedia.org/wiki/Application_Server
An application server provides services such as security,transaction support etc.
"The term is often used for web servers which support the JavaEE" -- It sounds like if we add the required jar files of JavaEE APIs a web server becomes an appl. server.What about it.
Now my question is how an application server performs the tasks of security control or transaction management by itself ?
E.g. in my web application using Spring framework I am providing security by using spring-security and transaction management by using #Transactional annotation and all those things you know.
So does the appl. server have anything to do with my security or transaction management or it has its own ways ?
Forgive my ignorance.
Using Spring, you're in fact embedding some kind of Java EE container inside your application. But even when using Spring, if you need JTA support (because you need distributed XA transactions), you'll need to use an additional transaction manager. If you need JMS, you'll need to install an additional JMS broker. If you need connection pooling, you'll need to use an additional connection pool. Sometimes it's as simple as adding additional jars to the classpath and properties or XML files. Sometimes it's harder.
A Java EE app server comes with everything bundled. You have less flexibility, but you don't need to install, configure and make everything work by yourself.
When you use the Java EE framework, that is a specification. So the application server, if it is Java EE compliant, needs to implement this. So once it is implemented the specification, then it will address Security,transaction etc because it is mentioned in the spec. So it is a contract. Whereas, in a web server, it will just pull out your static resource. There is no need for handling other stuff.
In case of the Spring framework, the framework knows how to handle transaction, security etc. So particularly the developer need not look into these aspects which are implemented by the Application Server in the other scenario.
how an application server performs the tasks of security control or transaction management by itself
It is rather the specification that address these issues, not the application server. So, the duty of the app server is to implement these.
So, if your application is Java EE compliant, then these areas will be addressed and the implementation would have been done by the app server.
May be this is oversimplification,
A web server is basically a HTTP server serving contents over http protocol. So a web server is simply about serving the contents over http protocol. A typical example would be Apache web server. This is simply a file server.
Now the question is where does the web server gets the contents from ? Possible sources are
Static contents (the contents like images/css etc) which are not generated on request but statically served.
Dynamic contents: Simply put, the contents to be served are generated upon the user request.
For the static contents, the web server does not need anything as it simply reads the file and serves it.
For dynamic contents, the web server might need help of additional components which will generate the contents to be served.
Here the Application Server comes into picture.
Now these additional components referred earlier, might interact with database or some other system etc.
In a web environment where your website is exposed to huge number of users (intended/unintended), you need typical services like transaction/security/concurrency etc. so that the user get expected responses and do not see inconsistencies in the behavior of the application.
An application server has inbuilt abilities to manage transaction/security/concurrency/resource management. generally these are referred as Managed services and environment offered by them is called Managed Environment where these basic services are managed by the application server and programmer does not have be bother for them.
Application Server needs web servers or we can say Web servers use Application server's services to generate dynamic contents.
For example, JBoss uses Tomcat as inbuilt web server. Whereas web logic has its own web server. Tomcat again can be called as application server (in principle) as it also offers managed environment for servlets (it manages concurrency and instance pool of servlets/JSPs ).
Coming your your example of Spring:
An Application server will come inbuilt with transaction/security etc whether you need it or not. The Spring offers a very nice way handling this. Spring has all these things BUT you use what you need. Not just these, but just a Java Web Sever like Tomcat is sufficient to build a full fledged services that needs an application server.
I have currently two wars files in which one war has to send notification to other war file using spring.Both of the wars are implemented using spring and web service.
My requirement is first war has to send notifications to other war file.
Could you please provide some pointers to implement the same using spring ?
I do not know exactly your requirements but I'd suggest you to use RestFull web service for this notification. Spring has a perfect support of this kind of services.
Internally the first application will send HTTP POST (or GET) request like http://thehost/webapp2/mynotification
Other way is to communicate using JMS. This way is good if you have to make the communication asynchronous. Spring supports JMS using JMS templates.
You can use:
JMS
a webservice (or spring http invoker) in the target app and invoke it from the notifier
You can use RMI to export your beans and make them visible from other modules, better than other alternatives in this case because:
JMS is asynchronous and needs a middleware.
Webservice are less efficient (since it is mostly conceived to communicate heterogeneous platforms).
Take a look here on how to do it:
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/remoting.html#remoting-rmi
But I would first of all review the architecture you are using, in case you can refactor it for a better integration of business logic.
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.