Scenario:
I have been using Java SE for quite some time, working with threads etc, though I have little experience with Java EE.
I have a 3rd-party Java library that connects to a remote server (at the 3rd-party company). The library creates several threads and is keeping the connection alive by itself.
I am not allowed to open new connections over and over (by creating new instances of the library). I need to keep the same instance of the library which will keep the connection up at all time.
This is quite easy in a Java SE application.
Now, I want to create a web service (perhaps using GlassFish or similar) to use internally at my company to be able to use the functionality of this library with its connection.
In other words, I need a custom remote connection (that is not created by or managed by my code) to be kept alive between request instances.
Question:
Is this possible to achieve? If so, which technology should I take a look at?
you can do that using connection pool.when ever a connection required to remote server, get the connection from this pool instead of instantiating every time.This will help you in maintaing better memory foot print and efficiency.If connection is no longer in use, you can return the connection to pool.
I have recently implemented a similar system, using Tomcat as the Servlet Container and Metro 2.0 as the JAX-WS implementation. My service maintains socket connections to backend components (implemented in C++) and communicates with them using a proprietary network protocol.
I used a 'Component Manager' thread to manage the high-level communication with the Components (connection establishment, handshaking etc.) and a 'Network Selector' thread that managed the actual communication with the Components. This 'Network Selector' used asynchronous non-blocking sockets using the Java Socket Selector family of classes - using a single thread to interact with the Socket Selector class is an important point as some Java platforms exhibit bugs when multiple threads are used.
It's working very well so far, so I can tell you that it's certainly possible. If you require any clarification then please post here or e-mail me (see my profile).
You need to have a factory maintaining the connections, and then provide it through JNDI in the same way that e.g JDBC connection pools are provided.
You then need to ensure that the connections are returned to said factory and then integrate it in the application server life cycle so that it is pulled up and down programatically.
Note that there is a nasty classloader problem lurking here if you are not careful. You will have to have a common class to the factory and the clients and if it is not one in the standard runtime library you will need to figure out a way to have it correctly shared unless you want to use reflection to get to the methods.
Related
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.
So my most basic question here is: how do you build TCP interfaces into your Java EE applications? Instead of interacting with a legacy EIS, I need to interact with a block of TCP/IP ports. Ideally, I'd like a message-driven bean to have it's onMessage method invoked by an incoming TCP request and also be able to respond back over the same connection.
JCA seems general enough to be capable of something like this within a Java EE environment. Would developing a custom connector be the appropriate technique for integrating inbound/outbound TCP interfaces in a Java enterprise ecosystem?
As far as what I've tried so far: we're currently utilizing a lifecycle module which starts by kicking off a number of TCP listeners; this invokes a message-driven bean which calls a business method, and it all returns over the same TCP stream. This is actually working alright, but the lifecycle support in my application server (Glassfish) feels like it has been added as an afterthought. So, JCA seems like a first-class solution to this sort of problem and it seems to enable us to communicate over TCP.
However, from the initial research we've conducted, it does seem like the connector architecture is 'targeted' towards legacy information systems, not generalized TCP communication. So, my question could be rendered: are people using custom JCA's to integrate TCP/IP into their Java EE applications -- or is there a better technique for accepting TCP connections from my EJBs?
MXBeans and JCA (MXBeans are easier, have implemented both) but basically you only need 2 things start/stop and possibly to rely on other MXBeans/JCA/JNDI to carry out your services w/ the AppServer generating the needed proxies for you.
Real application: hacked tomcat w/ the NIO acceptor that can trap connections on 80+443ports and still use the web-server normally.
Followed by full platform (incl. own (re)deployer) to manage sessions/messages and all the jazz.
It seems you already resolved your initial problem. It's nice, but to help people through, this is a nice sample on the matter: http://code.google.com/p/jca-sockets
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.
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.
I am building a small website for fun/learning using a fairly standard Web/Service/Data Access layered design.
For the Data Access Layer, what is the best way to handle creating Connection objects to call my SQL stored procedures and why? Bearing in mind I am writing a lot of the code by hand (I know I could be using Hibernate etc to do a lot of this for me)...
1) Should I create one static instance of the Connection and run all my querys through it or will this cause concurrency problems?
2) Should I create a Connection instance per database call and accept the performance overhead? (I will look into connection pooling at a later date if this is the case)
You should use one Connection per thread. Don't share connections across threads.
Consider using Apache DBCP. This is a free and standard way of configuring database connections and drawing them from a pool. It's the method used by high-performance web servers like Tomcat.
Furthermore, if you're using DBCP, since it's a pool (read: cached), there's little penalty to creating/closing connections frequently.
The standard way is to set up a DataSource. All application servers are able to do so via their admin console. The pool is then accessible by it's JNDI name (e.g. "jdbc/MyDB").
The data source should, in fact, be a connection pool (and usually is). It caches connections, tests them before passing to the application and does a lot of other important functions.
In your code you:
resolve JNDI name and cast it into DataSource
get a connection from the data source
do your work
close the connection (it goes back to the pool here)
You can set up the pool yourself (using any of freely available pool implementation), but it really doesn't make any sense if you're using an application server.
P.S.
Since it's a web application a good way to make sure you have closed your connection after the request is to use HttpFilter. You can set up one in web.xml. When the request comes, acquire the connection, put it into ThreadLocal. During the request, get the connection from ThreadLocal, but never close it. After the request, in the filter, close the connection.