i need to create a slideshare to introduce JCA in an easy way. right now i'm trying to understand the whole thing but i'm still stuck in some places. I'm reading an IBM tutorial and in its example code it doesnt implement the transaction and security contracts but instead it uses an Interaction, an InteractionSpec, a RecordFactory, and IndexedRecords interface/classes (Thats CCI i suppose).
well in a share i found they stated that the contracts from JCA v1 specification need to be implemented and in this example only the "connection management contract" is being used if i understand it right.
(ConnectionMetaData, ConnectionFactory, Connection) or (ManagedConnectionFactory, ManagedConnection, ManagedConnectionMetaData) <- Whats the difference between those and are the interfaces prefixed with "Managed" the so called "Managed Connection Contract"?
Also i'm not quite sure yet but is the CCI only used for the creation of the Resource Adapter? Or can i use it as a "framework" inside my application-server to communicate with the resource adapter. In the Bean example they use a JNDI lookup to get an instance of the ConnectionFactory and use the overloaded methods of the extended CCI classes.
I understand what the contracts "do" but when do i use system contracts and when do i use CCI. I'm not getting the purpose of it.
Is the CCI some sort of "API methods" inside my resource adapter, i can then use in my application-server implementation?
The first look of JCA is so complex.
How would i communicate with a Resource Adapter inside a JBoss, Tomcat setting for instance.
Yes, JCA is quite a complicated machinery. The objects that are manipulated by the client (i.e. the EJB, Servlet) are not the internal ones in the JCA adaptor.
From what I recall, one of the reason for this "split" is that connection pooling is managed by the applicaton server. Obtaining connections is thus an interaction between the client, the application server and the internals of the resource adaptor. I haven't been using JCA since long time, so I don't remember sharply the details. However, I had dumped down in a blog post my understanding of JCA few years ago, maybe it will help you.
Related
I have a requirement, where a front-end application (written in spring MVC) needs to communicate with another backend application. Both the applications are going to be WAR running within the same tomcat instance. For understanding purpose, lets name it frontend.war and backend.war.
I have gone through many posts across various forum, and found many different strategies, some of them are as below:
1) Using EJB - Ruled out, EJB's are maintenance overhead and we have no plan to create a dedicated EAR to accomplish this; because we have plan to add more different forntend wars (application modules) which will communicate to same backend.war.
2) Using JNDI : Looks promising, but it needs to have one war to know about the 'interface' being exposed by 2nd war, its signature. So, it is making it tightly coupled with each other. Future change in the service contract can become nightmare.
3) Using REST API : This looks an ideal approach, with only one caveat that the communication is over HTTP call, hence it could be slow.
Other approaches like common parentContext (in Spring). ContextSwitching within application does have their own issues.
I am getting inclined to use REST API approach for this solution; as it is cleaner and easy to maintain. Further the http protocol is mature and has lots of know-how available for future development.
My query:
A) Is it possible to make a tomcat aware that a particular webservice call is indeed a call on the application running same JVM/Server (kind of 'internal'); rather than an 'external' webservice call?
B) If I use url like 'http://localhost:8080/rest/...' (note that backend.war is not intended for external world, so a domain name is not needed) ; will it do the trick?
I am looking for an approach, which gives me performance of JNDI (communication within same JVM) and flexibility of REST (You can change anything, anytime as long as public URLs are intact).
If you have thousand of war, maybe try the Enterprise service bus approach. WSO2 would be a good candidate. You could always change your entry point definition while keeping the backend intact.
Added benefit: your war can be deployed on multiple server and / or moved, but you keep only an entry point; only one address to change.
Create a jar file of the common functions, package them up as a dependcy to both projects - a service layer !
Alternatively, use rest and stick on different tomcat instances/servers - microservices!
I would use any "remote invocation" approach like Java RMI or CORBA. The latter applies also outside the Java world. Those have some benefits over others: they use TCP but not HTTP, therefore are lighter, serialize objects instead of creating new objects (like json or others). Additionally, I think RMI is simple to understand and use quickly.
I am implementing an android based chat. I want to make it almost as low level as possible.
The reason for that is simple - i want to gain more knowledge on how things work.
I am using sockets to connect to a server. With a single socket everything is working quite well but my question is:
Will i need multiple connections when the user using the application opens multiple chat windows. If so - what is the best aproach for making those connections.
I was thinking about using something like a Util class that opens a connection when needed but i'm still not quite sure what architecture this class must have. For example would it make sense to make it a singleton class? Will i be able to keep track of all the opened connections and close them when they are no longer needed.
Any help would be appreciated.
P.S. If i missed something feel free to tell me what and i will try to edit the question to be as clear as possible.
This is clearly more of an architectural question, but I'll offer some thoughts. I would say this depends on your setup.
It sounds like you are connecting to your "contacts" directly, instead of using a central server. I assume you are determining and using the IP address directly to initiate a chat session. If this is the case, then yes, you will need to open a connection for each chat session you have going on.
If instead you are using a chat server, then theoretically, you only need one connection to that server. This server, of course, will require a connection to each user. Using a chat server requires more work on your part, but it could allow for a more user friendly experience. For example, registering your user name on the server would allow you to speak with other people via their usernames instead of having to know their IP. You still need to connect to your server via a well known IP address or DNS name, however.
As for class architecture, I highly recommend you check out something called "Dependency Injection". Dependency injection in practice usually means you interact with services and providers through an interface. The actual class that implements the interface is also written by you, and "injected" at run time. This allows you to decouple your application from a specific technology or protocol, which means that someday, you can replace your custom sockets implementation with, say, a web service implementation without having to make changes to the code that uses the service. In addition, most dependency injection frameworks allow you to specify how classes are instantiated and used when they are injected. You can use configuration to specify if one and only one class will ever be instantiated (effectively a singleton), or if a new class will be instantiated each time the service is requested.
I am reading the Enterprise JavaBeans 3.1 book and I wonder if I have understood the concept of EJB proxy object correctly. I now know that it follows the proxy pattern and I have read some about it.
When we make the interfaces for the beans, we are doing it because we want to have the proxy pattern implemented. This helps us because the clients are only concerned about what we can do and not tied to directly to a class but rather a interface that can act as if it where the real object.
So, the container probably instantiate the proxy objects implementing the corresponding interface and add some magic code (networking code) before invoking upon the real EJB for us, because the proxy object is automatically made right?
Have I misunderstood the concept? If thats the case could someone tell me whats wrong?
Correct. The interfaces you're writing for your beans would have been sufficient if your application was confined to a local JVM. In this case no proxy would be needed, as the implementing class could be instantiated and supplied directly.
Clients of EJBs cannot work on their implementing classes, as they don't have them in their classpath. EJBs are location-transparent, you can call them across the network, or from another application located on the same server, but isolated out by different class loaders. In such cases, you need to have proxy objects to marshal, send over the network, and unmarshal the parameters you supply to EJB calls and results of these calls that you receive. And on the client side, you need a dummy EJB interface implementation, that forwards your calls to the server where this EJB is installed.
Proxies also handle other functions, such as starting/ending transactions around EJB method calls.
EDIT: if you're curious what EXACTLY such proxies could do, take a look at overviews of RMI in Java and AOP (either in AspectJ or Spring). It will give you the idea what kinds of tasks can be implemented this way.
Are you referring to the proxy interfaces to stateless (and stateful) session beans and message driven beans?
If so, I think your understanding is correct. The only thing you seemed to have missed is the concept of instance pools for stateless beans. The container does not instanciate these per request, but instead provides an implementation when needed.
Also, using proxies allows the container managed things to take place: transaction management, asynchronous thread management etc.
I am writing a JCA resource adapter. I'm also, as I go, trying to fully understand the connection management portion of the JCA specification. As a thought experiment, pretend that the only client of this adapter will be a Swing Java Application Client located on a different machine. Also assume that the resource adapter will communicate with its "enterprise information system" (EIS) over the network as well.
As I understand the JCA specification, the .rar file is deployed to the application server. The application server creates the .rar file's implementation of the ManagedConnectionFactory interface. It then asks it to produce a connection factory, which is the opaque object that is deployed to JNDI for the user to use to obtain a connection to the resource. (In the case of JDBC, the connection factory is a javax.sql.DataSource.)
It is a requirement that the connection factory retain a reference to the application-server-supplied ConnectionManager, which, in turn, is required to be Serializable. This makes sense--in order for the connection factory to be stored in JNDI, it must be serializable, and in order for it to keep a reference to the ConnectionManager, the ConnectionManager must also be serializable. So fine, this little object graph gets installed in the application client's JNDI tree.
This is where I start to get queasy. Is the ConnectionManager--the piece supplied by the application server that is supposed to handle connection management, sharing, pooling, etc.--wholly present on the client at this point? One of its jobs is to create ManagedConnection instances, and a ManagedConnection is not required to be Serializable, and the user connection handles it vends are also not required to be Serializable. That suggests to me that the whole connection pooling machinery is shipped wholesale to the application client and stuffed into its JNDI tree.
Does this all mean that JCA interactions from the client side bypass the server-side componentry of the application server? Where are the network boundaries in the JCA API?
Does this all mean that JCA
interactions from the client side
bypass the server-side componentry of
the application server? Where are the
network boundaries in the JCA API?
AFAIK, yes. There will be a local JNDI and the local JNDI will return local connections. Same if true for other kind of object in the JNDI, such a configuration value (env-entry). Of course, if you look up an EJB, the factory returns a proxy to the remote bean, but the JNDI is still local to my knowledge.
The client embeds its own pool. This means, as you pointed out, that connections obtained in the client will escape the server-side machinery.
It gets even worse when we start to play with distributed transactions. A client may obtain a UserTransaction to start and stop distributed transactions on the client-side (not all app. server supports this, though). The transaction context will be propagate during calls to remote EJB. A distributed transaction may then span client-side connections and server-side connections.
According to the J2EE philosophy, an application client should normally not use transactions and obtain connection directly; it should solely communicate with remote EJB.
The specs are not really clear about more complicated scenario and there isn't that many information around. The spec do for instance not mandate the application server to expose the UserTransaction to the client.
What I wrote here applies to Glassfish at least, but I would not rely on a consistent implementation of such features across all application servers.
We use Tomcat to host our WAR based applications. We are servlet container compliant J2EE applications with the exception of org.apache.catalina.authenticator.SingleSignOn.
We are being asked to move to a commercial Java EE application server.
The first downside to changing that
I see is the cost. No matter what
the charges for the application
server, Tomcat is free.
Second is the complexity. We don't
use either EJB nor EAR features (of
course not, we can't), and have not missed them.
What then are the benefits I'm not seeing?
What are the drawbacks that I haven't mentioned?
Mentioned were...
JTA - Java Transaction API - We
control transaction via database
stored procedures.
JPA - Java Persistence API - We use
JDBC and again stored procedures to
persist.
JMS - Java Message Service - We use
XML over HTTP for messaging.
This is good, please more!
When we set out with the goal to Java EE 6 certify Apache Tomcat as Apache TomEE, here are some of the gaps we had to fill in order to finally pass the Java EE 6 TCK.
Not a complete list, but some highlights that might not be obvious even with the existing answers.
No TransactionManager
Transaction Management is definitely required for any certified server. In any web component (servlet, filter, listener, jsf managed bean) you should be able to get a UserTransaction injected like so:
#Resource UserTransaction transaction;
You should be able use the javax.transaction.UserTransaction to create transactions. All the resources you touch in the scope of that transaction should all be enrolled in that transaction. This includes, but is not limited to, the following objects:
javax.sql.DataSource
javax.persistence.EntityManager
javax.jms.ConnectionFactory
javax.jms.QueueConnectionFactory
javax.jms.TopicConnectionFactory
javax.ejb.TimerService
For example, if in a servlet you start a transaction then:
Update the database
Fire a JMS message to a topic or queue
Create a Timer to do work at some later point
.. and then one of those things fails or you simply choose to call rollback() on the UserTransaction, then all of those things are undone.
No Connection Pooling
To be very clear there are two kinds of connection pooling:
Transactionally aware connection pooling
Non-Transactionally aware connection pooling
The Java EE specs do not strictly require connection pooling, however if you have connection pooling, it should be transaction aware or you will lose your transaction management.
What this means is basically:
Everyone in the same transaction should have the same connection from the pool
The connection should not be returned to the pool until the transaction completes (commit or rollback) regardless if someone called close() or any other method on the DataSource.
A common library used in Tomcat for connection pooling is commons-dbcp. We wanted to also use this in TomEE, however it did not support transaction-aware connection pooling, so we actually added that functionality into commons-dbcp (yay, Apache) and it is there as of commons-dbc version 1.4.
Note, that adding commons-dbcp to Tomcat is still not enough to get transactional connection pooling. You still need the transaction manager and you still need the container to do the plumbing of registering connections with the TransactionManager via Synchronization objects.
In Java EE 7 there's talk of adding a standard way to encrypt DB passwords and package them with the application in a secure file or external storage. This will be one more feature that Tomcat will not support.
No Security Integration
WebServices security, JAX-RS SecurityContext, EJB security, JAAS login and JAAC are all security concepts that by default are not "hooked up" in Tomcat even if you individually add libraries like CXF, OpenEJB, etc.
These APIs are all of course suppose to work together in a Java EE server. There was quite a bit of work we had to do to get all these to cooperate and to do it on top of the Tomcat Realm API so that people could use all the existing Tomcat Realm implementations to drive their "Java EE" security. It's really still Tomcat security, it's just very well integrated.
JPA Integration
Yes, you can drop a JPA provider into a .war file and use it without Tomcat's help. With this approach you will not get:
#PersistenceUnit EntityManagerFactory injection/lookup
#PersistenceContext EntityManager injection/lookup
An EntityManager hooked up to a transactional aware connection pool
JTA-Managed EntityManager support
Extended persistence contexts
JTA-Managed EntityManager basically mean that two objects in the same transaction that wish to use an EntityManager will both see the same EntityManager and there is no need to explicitly pass the EntityManager around. All this "passing" is done for you by the container.
How is this achieved? Simple, the EntityManager you got from the container is a fake. It's a wrapper. When you use it, it looks in the current transaction for the real EntityManager and delegates the call to that EntityManager. This is the reason for the mysterious EntityManager.getDelegate() method, so users can get the real EntityManager if they want and make use of any non-standard APIs. Do so with great care of course and never keep a reference to the delegate EntityManager or you will have a serious memory leak. The delegate EntityManager will normally be flushed, closed, cleaned up and discarded when a transaction completes. If you're still holding onto a reference, you will prevent garbage collection of that EntityManager and possibly all the data it holds.
It's always safe to hold a reference to a EntityManager you got from the container
Its not safe to hold a reference to EntityManager.getDelegate()
Be very careful holding a reference to an EntityManager you created yourself via an EntityManagerFactory -- you are 100% responsible for its management.
CDI Integration
I don't want to over simplify CDI, but I find it is a little too big and many people have not take a serious look -- it's on the "someday" list for many people :) So here is just a couple highlights that I think a "web guy" would want to know about.
You know all the putting and getting you do in a typical webapp? Pulling things in and out of HttpSession all day? Using String for the key and continuously casting objects you get from the HttpSession. You've probably go utility code to do that for you.
CDI has this utility code too, it's called #SessionScoped. Any object annotated with #SessionScoped gets put and tracked in the HttpSession for you. You just request the object to be injected into your Servlet via #Inject FooObject and the CDI container will track the "real" FooObject instance in the same way I described the transactional tracking of the EntitityManager. Abracadabra, now you can delete a bunch of code :)
Doing any getAttribute and setAttribute on HttpServletRequest? Well, you can delete that too with #RequestScoped in the same way.
And of course there is #ApplicationScoped to eliminate the getAttribute and setAttribute calls you might be doing on ServletContext
To make things even cooler, any object tracked like this can implement a #PostConstruct which gets invoked when the bean gets created and a #PreDestroy method to be notified when said "scope" is finished (the session is done, the request is over, the app is shutting down).
CDI can do a lot more, but that's enough to make anyone want to re-write an old webapp.
Some picky things
There are some things added in Java EE 6 that are in Tomcats wheelhouse that were not added. They don't require big explanations, but did account for a large chunk of the "filling in the gaps".
Support for #DataSourceDefinition
Support for Global JNDI (java:global, java:app, java:module)
Enum injection via #Resource MyEnum myEnum and
Class injection via #Resource Class myPluggableClass and
Support for #Resource(lookup="foo")
Minor points, but it can be incredibly useful to define DataSource in the app in a portable way, share JNDI entries between webapps, and have the simple power to say "look this thing up and inject it"
Conclusion
As mentioned, not a complete list. No mention of EJB, JMS, JAX-RS, JAX-WS, JSF, Bean Validation and other useful things. But at least some idea of the things often overlooked when people talk about what Tomcat is and is not.
Also be aware that what you might have thought of as "Java EE" might not match the actual definition. With the Web Profile, Java EE has shrank. This was deliberately to address "Java EE is too heavy and I don't need all that".
If you cut EJB out of the Web Profile, here's what you have left:
Java Servlets
Java ServerPages (JSP)
Java ServerFaces (JSF)
Java Transaction API (JTA)
Java Persistence API (JPA)
Java Contexts and Dependency Injection (CDI)
Bean Validation
It's a pretty darn useful stack.
Unless you want EJB proper, you don't need a full stack J2EE server (commercial or not).
You can have most J2EE features (such as JTA, JPA, JMS, JSF) with no full stack J2EE server. The only benefit of a full stack j2ee is that the container will manage all these on your behalf declaratively. With the advent of EJB3, if you need container managed services, using one is a good thing.
You can also have no cost full stack server such as Glasfish, Geronimo or JBoss.
You can also run embedded j2ee container managed services with embedded Glasfish for example, right inside Tomcat.
You may want an EJB container if you want to use session beans, message beans, timer beans nicely managed for you, even with clustering and fail over.
I would suggest to the management to consider upgrades based on feature need. Some of these EJB containers might just well use embedded Tomcat as their webserver so what gives!
Some managers just like to pay for things. Ask them to consider a city shelter donation or just go for BEA.
If you are being asked to move to a commercial J2EE server, the reasons may have nothing to do with the J2EE stack but with non-technical considerations.
One thing that you do get with a commercial J2EE offering that you don't get with Tomcat is technical support.
This may not be a consideration for you, depending on the service levels your web applications are supposed to meet. Can your applications be down while you try and figure out a problem with Tomcat, or will that be a major problem?
Cost isn't necessarily a downside as there a few free J2EE servers, e.g. JBoss and Glassfish.
Your question assumes that (J2EE = Servlet + EJB + EAR) and therefore, there's no point in using anything more than a Servlet container if you're not using EJB or EAR. This is simply not the case, J2EE includes a lot more than this. Examples include:
JTA - Java transaction API
JPA - Java persistence API
JMS - Java messaging specification
JSF - technology for constructing user interfaces out of components
Cheers,
Donal
In truth, with the vast array of packages and libraries available, there's little an EJB container provides that can't be added to a modern servlet container (ala Tomcat). So, if you ever wanted any of those features, you can get them "ala carte" so to speak with the cost being the process of integrating that feature in to your app.
If you're not "missing" any of these features now, then from a practical standpoint, you probably don't need them.
That all said, the modern EJB containers are really nice, and come with all of those services pre-integrated, making them, somewhat, easier to use should you ever want them. Sometimes having the feature nearby and handy is enough to make someone explore it for its potential in their application, versus seeing the integration process of a feature as a hurdle to adoption.
With the quality of the free EJB containers, it's really hard to imagine how buying one can be at all useful, especially given that you have no real demand for one at the moment.
However, I do encourage you to actually get one and play around with it and explore the platform. Glassfish is very easy to get started with and very good, and should easily take your WARs as is (or with very minor tweaks).
As a rule when it comes between running Tomcat vs an EJB container the question is really why NOT use one? Speaking specifically for Glassfish, I find it easier to use than Tomcat, and It's primary difference is that it can have a moderately larger memory footprint (particularly for a small application) than Tomcat, but on a large application you won't even notice that. For me, the memory hit isn't a big deal, for others it may be an issue.
And it gives me a single source of all this nice functionality without having to crawl the net for a 3rd party option.