Related
I am trying to identify the correct set of technologies to develop an application that supports the following.
Provide web service capabilities (preferably REST)
Be able to handle updates to multiple data resources in a single transaction
Have some of form persistence capability.
Based on these basic requirements, my current plan is to build a REST based service using JAX-RS and JPA to handle persistence and use EJB to be able to handle multiple updates to different resources in a single transaction.
Are these the correct set of technologies or am I making my application bulkier.
Thanks for any suggestions. Finally, the application will be deployed on Websphere Application Server v8.5
Yes, those sound like reasonable technology choices for your project. There are all part of Java EE, which provides a ton of other nice features, too, so it provides some room for your application to "grow" without having to worry about being bogged down with huge numbers of libraries from different vendors. In my opinion, using Java EE is not alone a cause for worry about "bulkiness".
Since the application is going to be deployed onto WebSphere Application Server V8.5 there's no need to constrain yourself with available technologies if they are already a part of the runtime environment.
Having said that I however thought about the developers who will develop the application and may suffer from the time it takes to do frequent restarts, redeployments and such. It's not to say WAS 8.5 can't handle them, but since it's a full-blown application server meant for production environment, it might be too much for your development environment. If so, read on.
There's a lighter profile of WAS available - WebSphere Application Server 8.5 Liberty Profile. It's based on WebSphere AS's codebase, has a small footprint, and is precisely for customers who know the deployment platform is WAS, but they need a lighter solution on their development laptops.
It might be very well-tailored for your needs and if Eclipse is the IDE you may be pleasantly surprised how much slimmer the development environment became with Liberty Profile.
I want to exchange data between two applications JEE6/JSF2.0 and i'm looking for the best solution. I thought of the below solutions :
by using a JSON file.
by using XML file.
by using GSON file.
by using Remote interface (EJB 3.0).
For you, what's the best solution to use ?
edit : This two applications will be always running on the same network (but can not be on the same JVM)
I want to provide an alternative to David's answer, as I feel that there are some drawbacks to RMI that he underplayed.
This is a Java specific technology. If a third server needs to be introduced and it is a Microsoft Reporting Services server for example, then it cannot talk in the same language.
RMI is an OLD technology and doesn't particularly look well on a CV. Web services are the future. Experienced RMI developers are more uncommon than experienced web service developers.
Cumbersome and heavy framework
A better solution in my opinion would be to use SOAP XML based web services. Here are some advantages to this approach:
Universal acceptance in nearly any development framework. No matter the technology, nearly all have helpful libraries for interacting with web services.
Java has good support for object serialization into XML. This means objects can be quickly serialized into a SOAP XML request, sent to the other server, and deserialized back into a Java object by the other application server for processing.
A service layer can give you the decoupling interface between the two applications just as RMI can.
I hope you reconsider the use of SOAP XML based web services in your application.
There's two options really as you yourself stated.
Using RMI to connect to a EJB or using a webservice and communicating by JSON/XML etc...
From my experience RMI can be favorable if your applicaitons are on the same network, if not then you might get problems with firewalls etc and be forced to tunnel the RMI using HTTPS... which pretty much makes the RMI calls webservice calls.
If your on two different machines then webservices are nice as they dont cause as much trouble with firewalls. Also as they use the HTTP protocol you dont have to worry about the data being transfered.
These examples are kinda generalised but should give you some insight.
GSON vs XML vs JSON is a completely different subject... Non is superiour to the other, and all are fairly easily read by the human eye.
UPDATE
From what I've understod you wont have to worry about firewalls and such, I would recommend using RMI. It usually results in cleaner code and somewhat better performance.
Since I have seen both in action, I can make a comparison between the two technologies, EJB and WebServices. I can confirm that EJB is way more efficient, has support of transactions (including distributed transactions, if that is your requirement), exception handling, and binary streaming out of the box. In terms of performance EJB may exceed SOAP by a factor of 5 times in speed, and REST for about 3 times.
However, EJB is not an integration technology. In fact, it has never thought to do so. The biggest flaw of EJB is that it is very coupled to the Java Platform. Therefore, both endpoints must be written in Java and should use the same Java EE version.
Another problem is that EJB is not a protocol per se, so the implementations from two containers/vendors is probably different. If you need to access a remote EJB from JBoss AS on an Oracle WebLogic server, you must bring JBoss EJB client implementation with you.
Another big problem related to integration with EJB is a lack of data exchange format. Since it uses Java Serialized objects for communication, the data types must be shared on both ends. If you create a new exception type on the server that is classified as an Application Exception, if the client who consumes this service triggers the exception, his code will break. Note that, in this case the remote API was not violated, but another unknown type was introduced.
And, of course, by depending solely on the class type as an exchange format, you are giving the programmers opportunity for doing very stupid things. If you have many different teams in large projects using EJB as integration technology using different versions of Java EE, prepare yourself to experience uttermost pain. I've seem a programmer including a JPA entity on the client, who was annotated with named queries, the table which was accessing, its columns, etc, essentially giving away all the database layout to the service consumer. But it can get even worse. I've already seem a programmer returning a data structure that belonged to a dependency, namely Eclipselink 1.0. However, if you access this from a JBoss server, Eclipselink is also a JPA implementation technology, which conflicts with JBoss' hibernate. So, now you have to include Eclipselink jar in your JBoss APP classpath and configure the container for not loading JPA related packages, which otherwise will break your application completely. Even so, it can get WORSE than before: some other service you need to connect had also the bright idea of using the same datastructure, but now from Eclipselink 1.1.1, that has a different implementation, but the same class signature. Now you are in a very bad situation.
The bottom line: NEVER, EVER, use EJB as an integration technology. Use SOAP using a contract-first approach, where you define a canonical data model for the application, mapping java datastructures to a XML exchange format that can be used by any client, be it written in any language or using different stacks. Or use REST implementing a resource based, using HATEOAS principles. These days I rarely seem a reason for using EJB at all, since CDI is now on the market, support many features that EJB does and does not include any RPC related technology.
I've recently been given a project to work on that involves writing a web application. I've never done Java EE before. A lot of resources on the web are dated and I'm having trouble figuring out what the current differences are between the various standards and Java technologies.
Originally I thought I really needed EJB 3.1 due to dependency injection, JPA, session management, and web services. I started experimenting with Glassfish but was told that we had to write the thing in Tomcat. So I've been trying to figure out what I need as well as what and how to put into Tomcat to get there. I've begun to question whether I even need EJB at all.
I want to use JFS, I think, for the MVC architecture. In learning about that I've run into both ManagedBeans and CDI, which according to some renders the former obsolete and also seems to provide all the dependency injection stuff I want to enable unit testing. I've also come to realize that I can get JPA outside of EJB in the form of Hibernate and maybe a few others. Additionally it seems that web services, which I don't know that I need anyway, come in the form of another standard I can't think of the name right now and this also can be installed independently.
My major issue here is session management and state. It seems to me that all which remains for EJB to do is provide #Stateless/#Stateful and #Local/#Remote. However, as I understand it, some of this is already exists in the form of session management in the servlet container...but I don't know how much or what the major differences are that I need to account for in order to decide if I need these things at all.
So my question is, what are the basic, essential differences that I need to know in order to decide if EJB is worth looking at or if I have enough in the form of other libraries and technologies? I've been all over google and Usenet and have not been able to find this information anywhere.
Just thought of another bit. As I understand it, the #Stateful bean annotation provides me thread-safe state saving. I'm probably not going to directly use threads, but I know Java does so behind the scenes a lot and suspect EE especially so. When I need to keep state I don't want to be dealing with threads if this already provides it.
ManagedBean
Java EE 6 has three different ways of defining beans that are managed in one way or another:
#javax.faces.bean.ManagedBean
JSF 2.0 introduced this annotation declaring managed beans in faces-config.xml. This annotation is used to access a bean from the Expression Language.
#javax.inject.Named
In an EE 6 container CDI this annotation is a built-in qualifier types to provide a name to a bean, making it accessible through EL.
#javax.annotation.ManagedBean
This annotation attempts to generalize JSF managed beans for use elsewhere in Java EE.
If you deploy in an EE 6 container (If you use Tomcat or another servlet container, you can also get CDI by adding the Weld jar to your web app), then there is really no reason to use #javax.faces.bean.ManagedBean. Just use #javax.inject.Namedand start taking advantage of CDI sevices.
CDI
One of the objectives of CDI specification is to bring together the Web tier and the transactional services, making easy for developers to use EJB along with JSF in web applications of the Java EE platform.
With CDI you have the following services among others : well-defined lifecycle contexts(influenced by seam 2 and conversation scope), Dependency injection, loose coupling facilities like interceptors, decorators and events and portable extensions, which allows third-party frameworks to integrate in the Java EE 6 environment like SEAM 3 extensions
Managed beans and EJB Services
First of all CDI applies to any managed bean. Some managed beans are EJBs. When we need to use the EJB services in a managed bean, we just add a #Stateless, #Stateful or #Singleton annotation. IMO they act as complementary technologies allowing you to have a flexible and gradual development just only adding some annotations.
So, when should we use a session bean instead of a plain managed bean?
When you need some EJB features that CDI is missing : declarative transactions, concurrency management, pooling, remote or web service invocation ,timers and asynchronous method invokation.
Of course you could also get all aspects using third party libraries - but this would introduce additional complexity to your project. In terms of functionality IMHO EJB are the place to implement :
Business logic, allowing you to have a cleaning separation of busniness logic and web tier logic (implemented by "JSF backing beans" which are CDI managed beans but no EJB)
Functionality which makes most sense for components which are entrypoints to the application (endpoints for remote invocations delivered via RMI or HTTP)
Finally if you need EJB services then you need an Aplication Server (eg. GlassFish or Jboss AS) if you only need CDI services you need a Servlet Container(e.g Tomcat) plus CDI libraries.
Do you need the features provided by EJBs, i.e. security and transaction management? If the answer is yes, EJBs might be a good option.
If the answer is no, and you only need dependency injection, CDI could then be a good option.
You can also get similar capabilities with other 3rd party products, like Spring (dependency injection, Spring security, etc), but deciding whether you use one (EJB) or the other (e.g. Spring) is in many of the cases a matter of previous skillset.
In my opinion, if there are no previous constraints, going Java spec compliant is a good investment.
I would suggest you to start with the CDI and proceed to the EJB's (which is really adding one annotation on top of your POJO) if the requirements needs them (just as it was told - transactionality, web services, JMX, timers, EJB asynchronous invocations).
It's quite reasonable to develop an application in which your entry point is an EJB which encompasses your call in the transaction and allows you to define multiple entry points. The EJB then invokes the CDI beans with the business logic in them.
It's also worth noticing that the TomEE is a certified Java EE 6 Web Profile developed on top of the Apache Tomcat.
My question is very simple, my intention is to generate a repository with your responses so it could serve to the community when selecting frameworks for developing enterprise general purpose applications.
This could apply very well for general purpose languages such as C++, C# or Java.
What Framework do you recommend for generating Layered Architectures?
Based on you experience why do you prefer the usage of some Framework versus your own architecture?
How long do you believe your selected Framework will stay as a preferred option in the software development industry?
This is indeed an overly general question, especially since there are so many interpretations of the very word framework, and within the world of frameworks many different kinds for different tasks. Nevertheless, I'll give it a shot for Java.
Java
Java EE
The default overall enterprise framework of Java is called Java EE. Java EE strongly emphasis a layered architecture. It's a quite large framework and learning every aspect of it can take some time. It supports several types of applications. Extremely small and simple ones may only use JSP files with some scriptlets, while larger ones may use much more.
Java EE doesn't really enforce you to use all parts of it, but you pick and choose what you like.
Top down it consists of the following parts:
Web layer
For the web layer Java EE primarily defines a component and MVC based Web Framework called JSF - JavaServer Faces. JSF utilizes an XML based view description language (templating language) called Facelets. Pages are created by defining templates and letting template clients provide content for them, including other facelets and finally placing components and general markup on them.
JSF provides a well defined life-cyle for doing all the things that every web app should do: converting request values, validating them, calling out to business logic (the model) and finally delegating to a (Facelets) view for rendering.
For a more elaborate description look up some of the articles by BalusC here, e.g. What are the main disadvantages of Java Server Faces 2.0?
Business layer
The business layer in the Java EE framework is represented by a light-weight business component framework called EJB - Enterprise JavaBeans. EJBs are supposed to contain the pure business logic of an application. Among others EJBs take care of transactions, concurrency and when needed remoting.
An ordinary Java class becomes an EJB by applying the #Stateless annotation. By default, every method of that bean is then automatically transactional. Meaning, if the method is called and no transaction is active one is started, otherwise one is joined. If needed this behavior can be tuned or even disabled. In the majority of cases transactions will be transparent to the programmer, but if needed there is an explicit API in Java EE to manage them manually. This is the JTA API - Java Transaction API.
Methods on an EJB can easily be made to execute asynchronous by using the #Asynchronous annotation.
Java EE explicitly supports layering via the concept of a separate module specifically for EJBs. This isolates those beans and prevents them from accessing their higher layer. See this Packaging EJB in JavaEE 6 WAR vs EAR for a more elaborate explanation.
Persistence layer
For persistence the Java EE framework comes with a standard ORM framework called JPA - Java Persistence API. This is based on annotating plain java classes with the #Entity annotation and a property or field on them with #Id. Optionally (if needed) further information can be specified via annotations on how objects and object relations map to a relational database.
JPA heavily emphasizes slim entities. This means the entities themselves are as much as possible POJOs that can be easily send to other layers and even remote clients. An entity in Java EE typically does not take care of its own persistence (i.e. it does not hold any references to DB connections and such). Instead, a separate class called the EntityManager is provided to work with entities.
The most convenient way of working with this EntityManager is from within an EJB bean, which makes obtaining an instance and the handling of transactions a breeze. However, using JPA in any other layer, even outside the framework (e.g. in Java SE) is supported as well.
These are the most important services related to the traditional layers in a typical enterprise app, but the Java EE framework supports a great many additional services. Some of which are:
Messaging
Messaging is directly supported in the Java EE framework via the JMS API - Java Messaging Service. This allows business code to send messages to so-called queues and topics. Various parts of the application or even remote applications can listen to such a queue or topic.
The EJB component framework even has a type of bean that is specifically tailored for messaging; the message driven bean which has a onMessage method that is automatically invoked when a new message for the queue or topic that the bean is listening to comes in.
Next to JMS, Java EE also provides an event-bus, which is a simple light-weight alternative to full blown messaging. This is provided via the CDI API, which is a comprehensive API that among others provides scopes for the web layer and takes care of dependency injections. Being a rather new API it currently partially overlaps with EJB and the so-called managed beans from JSF.
Remoting
Java EE provides a lot of options for remoting out of the box. EJBs can be exposed to external code willing and able to communicate via a binary protocol by merely letting them implement a remote interface.
If binary communication is not an option, Java EE also provides various web service implementations. This is done via among others JAX-WS (web services, soap) and JAX-RS (Rest).
Scheduling
For scheduling periodic or timed jobs, Java EE offers a simple timer API. This API supports CRON-like timers using natural language, as well as timers for delayed execution of code or follow up checks.
This part of Java EE is usable but as mentioned fairly basic.
There are quite some more things in Java EE, but I think this about covers the most important things.
Spring
An alternative enterprise framework for Java is Spring. This is a proprietary, though fully open source framework.
Just as the Java EE framework, the Spring framework contains a web framework (called Spring MVC), a business component framework (simply called Spring, or Core Spring Framework) and a web services stack (called Spring Web Services).
Although many parts of the Java EE framework can be used standalone, Spring puts more emphasis on building up your own stack than Java EE does.
The choice of Java EE vs Spring is often a religiously influenced one. Technically both frameworks offer a similar programming model and a comparable amount of features. Java EE may be seen as slightly more light-weight (emphasis convention over configuration) and having the benefit of type-safe injections, while Spring may offer more of those smaller convenience methods that developers often need.
Additionally Spring offers a more thoroughly and directly usable security API (called Spring Security), where Java EE leaves a lot of security details open to (third party) vendors.
To specifically answer the second question:
Developing your own framework gives you the burden of having to maintain it and educating new developers in using it.
The larger your framework becomes, the more time you have to devote specifically to it and the less time you thus have to solve your actual business problem. This is okay if your business problem is the framework, but otherwise it can become a bit of a problem, even for very large companies that can dedicate a group of people to such a framework.
If you're a smaller company (say ~15 developer max) this can really become a huge burden.
Additionally, if your own framework is the kind of framework that can take advantage of third party developments (e.g. third parties can develop components for JSF), then your own framework obviously won't be able to take advantage of that.
Unless of course you open source your own framework, but this will only significantly increase the burden of supporting it. Just dumping your source code on sourceforge does not really count. You will have to actively support it. All of a sudden your framework becomes their framework with maybe 'weird' feature requests and awkward error reports for environments that you have no personal interest in.
This also assumes that your framework will actually be used by external users. Unless it's really very, very, good and you put lots of energy in it, this will probably not happen if it's simply the umpteenth Java web- or ORM framework.
Obviously, some people have to take up the job of creating new frameworks, otherwise the industry just stagnates, but if your prime concern is your business problem I would really think twice of starting your own framework.
Very vague question, I'm not really sure it's ever a good idea to "write your own" at this point for a work project (unless writing your own, IS the project). If it's a learning exercise, fine, but otherwise go use one of the libraries written by people who have been doing it far longer. If you really want to get involved, read their code, try and contribute patches etc.
For .Net there is Sharp Architecture Which is a pretty popular framework for layered applications.
Here's some of the stuff I use (I don't use Sharp Architecture)
First, the infrastructure stuff
For Dependency Injection, I use StructureMap. I use it because it's way more robust and performant than anything I would or could write, and it's very well supported within the .Net community. It also sticks to being DI, and doesn't venture out into other things that I might want to use other libs for (AOP etc). The fluent configuration is fantastic (but many .Net DI Tools have that now)
For AOP, I use Linfu Dynamic Proxy. I know a lot of people that like the code weaver variety for performance reasons, but that's always seemed a bit like premature optimization to me.
For a DataMapper, I use AutoMapper. This is one where I'm on again off again. If you can do your mappings based just on convention, then great, I'll use it. Once I have to start tweaking the configuration to do special things.... to me that starts to get into the gray area where the code might be more clear with just some left=>right wrapped in a function.
Web/UI
Asp.Net MVC. Although to be quite honest, I'm having a falling out lately and may soon be moving to FubuMvc. Asp.Net MVC seems like it has split personalities in terms of API design (dynamic over here, static over there, using blocks to render forms, but System.Actions to render other things etc). Combine that with the fact that it's not really OSS (you can't submit a patch), and to me there's a compelling reason why the community should come up with something better that's OSS.
Persistence
NHibernate, Specifically Fluent NHibernate. Sure I'd love to write my own OR/M, but at the same time I'm certain that the hordes of developers who have worked on NHibernate are way smarter than me.
Services/Distribution etc
WCF for Synchronous calls
NServiceBus for Messaging and most async calls.
Most of this stuff is OSS, so how long will it be around, well, I would imagine a good long while.
This question doesn't work very well. Selecting frameworks is difficult, and very context specific. For each selection process you might end up with a simple shortlist and a simple list of questions to answer, but those lists do not transfer well to other selections.
The number of parameters and the parameter sensitivity influencing a decision is very large, and at enterprise level a lot of them are not technical.
Currently, there are no frameworks available that are ready to support these near-term enterprise needs:
the switch for most of the workforce from pc to tablet and phone;
the switch from web client and rdbms to p2p/disconnected based storage and distribution
I'd like to create a simple Google Web Toolkit application which makes uses RPCs. For persistence, I'd like to use something like the Java Persistence API.
Does this mean I have to use an application server like Glassfish? or can I stick with a simple web container?
In terms of concrete libraries, how should I proceed? TopLink? Hibernate? ...
I believe the GWT RPC stuff is implemented as simple servlets. Assuming that, you totally can use JPA in a web container like Tomcat and don't need a full blown J2EE app server.
To do that, you will need to do a bit of manual setup to make access to the PersistenceContext simpler. Hibernate suggests using ThreadLocal, and I have an entry on my blog that details how I did that for Tomcat here
I would personally recommend Glassfish, as being more stable, better implemented and generally higher quality that Tomcat. I don't want to start a flame war (by saying that putting J2EE into Tomcat is like putting lipstick on a pig), but I will tell you how we deploy all of our applications:
We use Glassfish as the web container, TopLink as the persistence provider, generally connected to a MySQL 5 database. We use the JPA POJOs all the way from the EJB layer, through the web tier, and the GWT layer as well, via RPC. We also use Stripes and JSPs for all the presentation logic that doesn't require AJAX functionality. We've never had any problems with this approach, and have so far done at least 10 large-scale projects this way. It's the best architecture that we've had to date, and we've had a lot (tomcat, jboss, hibernate, struts, spring, etc, etc, etc).
You can user any container you like, i mean servlet and jpa containers.
The key point is that GWT doesn't suport jpa, so you have to use DTO design parten.
This will keep everything organized and you will not have problems with lazy loading.