Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am very confused on what to use in developing a web application. If you can develop a web service using Java se restlet, then why should you bother using Java EE. What are the advantages of the one over the other? When and why should I use each?
Using something like Restlet doesn't necessary exclude JavaEE (you can use RestLet within JavaEE platforms).
Traditionally, JavaEE containers provide standardized services to applications. If you wanted to have a way to store your data transactionally, you'd write some EJBs because you didn't have to come up with the transactional model. The container provided that. You just focused on the entity and session beans that are specific to your domain.
Spring came along and provided a lot of the same capabilities in its own implementations (sharing some specifications and coming up with their own). But at the end of the day, you're using a common model for doing stuff.
JavaEE (or Spring) aren't limited to transactional models. JavaEE incorporates Servlets which in turns supports a raft of Web application frameworks. But, then again, many applications like tomcat support servlets without supporting the full JavaEE umbrella of specifications. JavaEE containers can supply JMS servers if your application requires asynchronous messaging, as well as standard means to define JDBC DataSources.
You'd typically use a JavaEE container like Glassfish/JBoss, if you want to have a lot of enterprise-level features without having to set them all up yourself.
You can do all the same things in Spring/etc, which is just a JVM, but you're also setting up all those services yourself (kicking off your own JMS servers, for example).
Historically, JavaEE containers were seen as large, resource-intensive applications which drove a lot of the Springs of the world to piece together just what you want/need. More modern releases of JavaEE containers are starting to buck that trend, though.
You really need to know what your application wants to do and look at what tools out there will provide you with what you want. Barring that, just grab Glassfish or something similar and have a play.
Hope this helps.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
What are some major distinctions between EJB and the other technologies that perform the same function, and why is there such focus on the technologies that are, or are not supported, as opposed to other systems that refer to things such as "supporting EJB" as a feature that is either there, nor not?
The original concept of EJB was much closer to what are now called microservices, where the individual components could be deployed across a variety of different servers (EJB containers).
Whereas modern microservices mostly use HTTP calls or message queues, however, EJB communication happened over a Java-specific protocol called RMI, which uses Java serialization to route method calls across the network more or less transparently. This network intermediary is the reason for needing an interface (in earlier versions of EJB, it was even more complex!): On the "local" side, the object actually behind the interface is a proxy that will serialize your method call and transmit it to wherever the EJB implementation is deployed.
Java EE (Enterprise Edition) includes a collection of features that cover a wide variety of "enterprisey" operations, including transactions, service directories, persistence, Web (Servlets), and distributed method calls. Tomcat is calling out that while it implements the Servlet API, which is one part of Java EE, it doesn't implement all of these other components, and if you need them you'll need a different container, such as GlassFish or WildFly.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have a smaller project to organize my finance and several dates and TODOs. Know I need to create different Screens and must often connect to databases to get data. I saw that the spring framework supports some stuff for jdbc and dependency injection. The last point is very important, because I want that my Classes, which creates the screen should be loosely coupled and the code should be more clear.
Is it profitable to use Spring by small projects? I may use 3 components of the whole framework and because of that I'm not sure if it is "good" style to use a big framework like these for such a small project.
Thanks for every comment.
Whether you are going to use Spring Framework or not, that's completely your choice. But I am trying to explain you where your conception about Spring Framework is completely wrong.
You have said-
Is it profitable to use Spring by small projects? I may use 3 components of the whole framework and because of that i'm not sure if it is "good" sytle to use a big framework like these for such a small project.
From Spring reference doc
The Spring Framework is a lightweight solution and a potential one-stop-shop for building your enterprise-ready applications. However, Spring is modular, allowing you to use only those parts that you need, without having to bring in the rest. You can use the IoC container, with any web framework on top, but you can also use only the Hibernate integration code or the JDBC abstraction layer.
It is clear that, you can only use those modules of Spring, which are required for your project without having to bring in the rest.
Spring Modules
The Spring Framework consists of features organized into about 20 modules. These modules are grouped into Core Container, Data Access/Integration, Web, AOP (Aspect Oriented Programming), Instrumentation, Messaging, and Test, as shown in the following diagram.
Any way, although Spring Framework provides comprehensive infrastructure support for developing applications but for the novice user, it is tougher to use the framework quickly as it has complex abstraction and user has to spend more time in assessing the concept, function and it's uses in developing the application.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
My intent is to learn Java EE so when I start a project in netbeans, I can choose from Java EE and Java Web. The problem is, that I don't fully understand what is the difference between these two and which one to choose. I have some basics on JSP, JSF, Servlets. I guess all server side stuff is enterprise. So what are extra features of Java EE compared to Java Web?
In NetBeans, java web refers to simple java web applications that can run in a light-weight container like Tomcat or Jetty. J2EE is intended to be run in a full Application Server such as Glassfish, and contains java web components, EJBs and JPA ORM. If you're a novice and want to start with easy stuff the JavaWeb applications may be better for you. Here's a write up from NetBeans: https://netbeans.org/kb/trails/java-ee.html
Both concepts are imprecisely used but ... OK, roughly speaking: Java EE is something broader than Java web. If you intend to use only technologies which a simple web container implementation (e.g. Tomcat) provides, then you're after a Java web project. If you intend to use additional technologies (say EJBs, or other EE technologies) then you need a full blown Java EE server (e.g. JBoss/WildFly). So I guess in your case you just need a Java web project.
For a full list of the Java EE technologies, see here:
http://www.oracle.com/technetwork/java/javaee/tech/index.html
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What is the pros and cons of using Servlet Containers (like Apache Tomcat) in contrast with using NIO frameworks (such as Netty and Grizzly) for hosting a JAX-RS RESTful service?
I'm going to develop a RESTful application using Java. Java has JAX-RS API (JSR 331 and JSR 339) for building RESTful services. There is different implementation for it as you can see here. All of them implement JAX-RS API and so it should be easy (at least in theory) to switch between them. Jersey is the reference implementation and I chose it for now.
For the client part I'm going to use angularJS+bootstrap (so just html/css/js and no jsp pages).
Just for the record I say that I use PostgreSQL as my DB and EclipseLink as my JPA (ORM).
Here I think I just miss one part and that's the server part (the host for JAX-RS service). AFAIK I can either use a Servlet Container (e.g. Apache tomcat) or a customize server (using NIO framwroks such as Netty and Grizzly, or maybe NIO.2 which is part of JDK 7) for that purpose.
But I don't know which one should I use. I think a pros and cons between this two solution help me choose one.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I am currently working on a pretty large Java 6 application where we are looking to split some of our functionality out into a service oriented architecture.
It seems that the primary SOA framework for the application space is OSGi and I have been looking into Felix and Knopplerfish but I wanted to make sure that this isn't my only option.
Does it make sense to use an actual web service protocol for our application like SOAP, even though we are not building a web app? Is this even acceptable?
Have any of you used an implementation of OSGi (Felix, etc.) with your desktop application? if so, how did it go? Do you know of anything better?
We're all pretty new to SOA here so any help would be greatly appreciated.
My company uses OSGi extensively, and it works well for us, in that we can version various components and have greater control over what gets exposed from each component.
If you envision ever wanting to run different components on separate hardware, then writing using web services (REST/SOAP/etc) makes sense. But there's a performance penalty in both sending bits from one process or network to another,and serializing/marshalling that data so it can be sent, and doing the opposite on the other side. If you don't ever think that will happen, then don't use web services.
We use Eclipse RCP as our application platform, which is OSGi based (Equinox). Our application makes usage of both the Eclipse plugins as well as pure OSGi bundles. In our case we have services that are both local to the application as well as remote (via Spring Remoting) to Java EE servers.
In your case, OSGi may make sense for your app, but remote service protocols don't.
Also, a desktop application on its own is not considered SOA. You are simply componentizing your application, which is a good thing.