In a very popular ecommerce store, I'd imagine the actual processing of the credit card would be moved to some sort of dedicated application server, and made into more of a asynchronous process.
What sort of java application type would that be? i.e. a service that would take a message of the queue, and start processing the request and update some db table once finished.
In .net, I guess one would use a windows service. What would you use in the java world?
It is typically a J2EE application that uses a HTTP web service interface or a JMS messaging interface. HTTP interfaces are accessible via a URL, and JMS connects to a queue to pick up messages that are sent to it. The app can run on any one of the major commercial (WebSphere, Weblogic, Oracle) or free (Glassfish, JBoss) servers.
In Java you already have great open source projects that do all this for you like Glassfish, Tomcat etc.
For a mission critical system, you might want something like IBM MQ series as the middleware, and a straight Java application that uses the MQ interface to process the requests.
At a few banks that I know of, this is their architecture. Originally the application servers were written in C, as was the middleware. They were able to switch to java because the code that was actually doing the critical work (sending and receiving messages, assuring guaranteed delivery, protecting against interruptions if a component went down) were the IBM MQ's.
In our case we use an application server from Sybase that can house Java components. They are pretty much standard Java classes that have public methods that are exposed for calling via CORBA. Components can also be scheduled to run constantly or on a schedule (like a service) to look for work to do (via items in a database table, an Oracle AQ queue, or a JMS queue). All of this is contained in the app server and the app server provides transaction management, resource management, and database connection pooling for us.
Or use an OSGI environment.
Related
I am looking for a better logical solution of a situation where one core Java EE (Web) application will call/execute many other Java applications/workers (which can be core Java or J2EE(web) application (don't know what will be the best)) at a certain time.
Those other Java applications/workers will basically connect (individually) with different Data sources (can be from remote DB or REST or SOAP, etc...) and populate/update local DB at a certain period of time.
I was doing research on Java Quartz Scheduler recently. Do u have any good suggestion to me for this Enterprise level architecture?
Btw, I am using Spring 4, Java 7
Thank you as always for all good and professional ideas.
Sample diagram can be as follows:
You can connect your java application with others easy with spring's httpInvoker or rmiInvoker.
More information here: http://docs.spring.io/spring/docs/current/spring-framework-reference/html/remoting.html
Not sure to understand good, but you can look at a messaging mechanism. Typically, the WebApp will send a message that will be received by all the Workers.
Have a look a JMS which it designed for this kind of use, and integrates well with both JEE (it is a part of the JEE spec) and Spring.
There are basically two parts to your question:
How do I schedule jobs on a Java EE server?
How do I invoke remote services from that scheduled job?
Job Scheduling
The trick with job scheduling in a Java EE environment is that you are typically running jobs in a cluster, or more than one server. Thus, only one of the nodes should be running that job at a time "on behalf of" the cluster, otherwise, you'll get multiple calls to those remote resources for the same thing.
There is a standard out there for this, JSR-237, which covers Timers and WorkManagers. Each Java EE vendor has its own implementation. WebLogic has one, WebSphere has one, and JBoss has one (the JBoss one isn't compliant with the JSR, but it does the same thing).
If you are running one of the servers that only runs the web tier of the Java EE spec (i.e, Tomcat or Geronimo), then Quartz is a good choice.
How to invoke remote services from timed jobs
Echoing #Alexandre Cartapanis' answer, probably what you'll want to do is create a JMS Topic in your Java EE server, and then when the job runs, post a message to the topic. The remote services (whatever Java EE servers) subscribe to this topic, and then you can run your queries.
The big advantage here is that if you ever need to add another service that needs to populate the local DB, all you have to do is have that server subscribe to the topic - no code changes needed. With JSch or remoting, you'll have to make a code change every time a new service comes online. You also have to make code changes if DNS addresses or IP addresses change, etc, where as the JMS way is just configuration on the server. There's a lot more that you can do with JMS, and the support is much better across the board.
Spring has adapters for Quartz and I think there's one out there for WorkManagers and Timers too.
You can make use of JSch - Java Secure Channel to trigger remote ssh calls which can start a JVM and run the Worker class.
Here are some examples.
I have to develop enterprise level application using Java technologies. I decided to develop client side environment with swing and server side related things using Java EE components. My planned way could be described as following
First swing client makes request to application server. And application server has business logic and it has ability to decide which way should transfer my requests. Database server has my DBs.
these technologies I willing to use.
swing for client side
servlet for HTTP request handling in application server
EJB for handling business logic in application server
Hibernate to access my DBs form EJB.
Could you tell me above architecture is compatible with JEE enterprise level system architecture?
Swing <==>Socket<==>JEE (Application) REST based <==>Hiberate (DAO)
Yes its good but.
But if your application is going to be used by different end user devices then you need to think different way of client side.
Using JNLP you can deliver your SWING client items to your end users that will give you better upgradation and later customization also possible without any intimation to your clients.
This is my points only.
I have a client software that is written in C++/C# and a database. Now I don't want the client to access the database directly, so I thought about placing an application server in the middle. This one should get a short request from the client, ask the database for new data, do some filtering (that can't be done in sql) and then return the data to the client.
My search for this kind of software brought me to Glassfish or Tomcat but my problem in understanding is, that these always want to talk http with html/jsp. Because most of my data is encrypted anyways, I don't need such plain text protocols and would be totally happy with something that just takes a byte stream.
On the other hand would it be nice to have a server handle the thread pool for me (don't want to implement all that from scratch).
After more than a day of searching / testing I'm even more confused than at the beginning (ejb, beans, servlet, websocket, ... so many things to google before understanding just the simplest tutorials).
TL;DR: how do I get Tomcat/Glassfish to just open a socket and create a new thread for every request, without any HTML/CSS/JSP involved?
Jetty and Tomcat are so called servlet container and thus primarly targeted at HTTP exchanges. Glassfish is an application server that uses a servlet container as one of its modules. I would stop thinking in that direction - that's all more like web applications and web services - some levels too high what you are asking for.
I think you should more look into sth. like Netty which is merley a "high performance protocol" server. Take a look at the documentation here (even some sort of tutorial there which might fit your use case).
GlassFish is an "enterprise application server", targeting the Java EJB specification. That's surely overdone for your purpose. You can give Tomcat a try. It is a "servlet container", targeting Java Servlet specification. Servlets have one purpose: listening to an incoming URL (request), executing Java code and returning a response, usually over HTTP.
For sure, you may start your own (plain) ServerSocket, for example using a ServletContextListener (which will be started once your application starts). But you should go for a higher protocol to send the data, like Hessian and Burlap, which is implemented in both, Java and C++ and easy to set up.
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 to design a distributed application composed by one server (developed in Java) and one or more remote GUI clients (Swing application with windows).
As stated before the clients are Swing GUI application that can connect to the server in order to receive and send data.
The communication is bidirectional (Server <=> Clients).
Data sent over the network is mainly composed by my domain logic objects.
Two brief examples: a client calls the server in order to receive data to populate a table inside a window; the server calls client in order to send data to refresh a specific widget (like a button).
The amount of data transmitted between server and clients and the frequency of the network calls are not particularly high.
Which technology do you suggest me for the server-clients communication?
I've in mind one technology suitable for me but I would like to know your opinions.
Thanks a lot.
The first technology that came to my mind was RMI - suitable if you're communicating between java client and java server. But you may get difficulties if you want do switch the client technology to - say - a webinterface.
I would go with RMI but implement the whole architecture using Spring framework. This way it is independent of technology used and can be switched to other ways of communication (such as HTTP or other ) with almost no coding.
UPDATE: And Spring will allow you to have none of RMI specific code.
I believe sockets should do the trick. They are flexible and not especially hard to code/maintain. Most entry level programmer should also be able to maintain them. They are also fast and adapt to any kind of environment.
Unless, your server is going to be off-site or you expect to have firewall issues. In that case, web services are the way to go since your basic communication happens through port 80.
I would second msparer's suggestion of RMI, except I would just use EJB3 (which uses RMI as the communication protocol). EJB3 are very easy and even if you don't use the other feaures EJB gives you (e.g., security) you can still leverage Container Managed Transactions (CMT). It really does make development easy.
As for the server->client communication, you would probably want to use JMS. Again, using EJB3 this is pretty e3asy to do with annotations. The clients will subscribe to the message service and receive update notifications from the server.
And yes, I am currently working on an application that does this very thing. Unfortunately we are using EJB2.1. Still, it is my opinion that this is where EJBs really shine. Using EJBs in a web app is frequently overkill, but in a distributed client/server app they work very well.
You can try using ICE http://www.zeroc.com for establishing server-client connection.