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 8 years ago.
Improve this question
While looking for the job, i have attended some job interviews at companies, that work at financial sphere. Every company uses Spring Framework as main framework for development. And almost everywhere I was told 'We need proved and stable technologies, that is why we use Spring.'
I would like to know, as I can't understand, why Spring is more popular and 'safer', than Java EE (for example, Spring MVC is used more, than JSF, while both provide almost the same functionality)?
How it is possible, that native Java EE functionalities are less stable, than third-libraries?
Some reasons:
Spring was already there: J2EE was ugly (no Dependency Injection, no conversion over configuration and lot of scares from EJB2, ouch). Java EE "stole" all good ideas from Spring, and it is in fact lighter and easier than previous versions. But now, everybody already uses Spring. It means a lot of production code, lot of well tested products and so on. In the end, why do people in UK/USA use English units? (There is a huge cost to change)
Spring is lighter: You do not need a heavy Java EE application server, you can deploy your application in a web container such as Tomcat.
Spring offers a ton of features which are not available as Java EE standards, such as Spring Batch or Spring Integration. You can use Spring features with Java EE standards, but it should be supposed Spring works better with Spring, shouldn't it?
Spring Aspect-oriented programming is more flexible and power that Java EE interceptors. You can use third-party AOP with Java EE but you can have this out-of-the-box from Spring.
Spring moves faster. Spring can release often and faster because it is no standard and only one vendor. So, it is not required JCP ballots, approvals, etc. The reaction to market requirements is much faster. Some current examples: cloud, mobile, social computing.
Ironically, I have "got" a lot ideas from:
http://www.kai-waehner.de/blog/2011/11/21/why-i-will-use-java-ee-jee-and-not-j2ee-instead-of-spring-in-new-enterprise-java-projects-in-2012/
While looking for the job, I have attended some job interviews at
companies, that work at financial sphere. Every company uses Spring
Framework as main framework for development. And almost everywhere I
was told 'We need proved and stable technologies, that is why we use
Spring.'
I work in financial domain since several years - so I can speak from my experience.
Many financial service providers I know had a major upgrade to their enterprise software stack at around 2006-2008, at a time when the disillusion about EJBs were at its peak after several unmaintainable and poorly written EJB projects. So in-order to upgrade their system and also to attract developers, they began to re-implement their stuffs in Spring and Hibernate, also it was a logical step for them to start new projects in the state of the art frameworks (which at that time were Spring, Hibernate and Wicket)
But since then financial crisis broke out and not many financial service companies think of investing that much money in new development unless it is very critical. Most do not care whether Java EE 6 or 7 was launched and some of the old arguments do not hold good anymore or so.
So they would like to believe that what they have is safer, faster etc (which may or may not be true)
One thing that makes Spring attractive to developers, especially at big organizations like financial companies, is that it lets them take more control over their middleware. With pure Java EE, developers are at the mercy of an operations group that has very different goals than they have. In many cases operations wants to avoid messing with anything that works, every upgrade is a chance for things to go wrong, and it's not like they're the ones who see the benefits from upgrades, so that makes their choices very conservative. That can mean developers get stuck with obsolete versions of an application server, and if a problem comes up the developers have to work with the vendor's technical support (so you have to convince the vendor you have a problem and reproduce it under the conditions they specify), then coordinate with operations to implement the fix (which of course means justifying your request to an organization with different priorities from you). Developers like to minimize this kind of thing whenever possible.
Having Spring in the application gives the developers more freedom to update more of their infrastructure on their own schedule.
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 9 years ago.
Improve this question
Evented web apps are an hot topics these days, but it appears there is not a unique solution for that. Especially for the back-end side, independently from the programming language.
I open this topics to discuss about the various solutions offered to the community.
I tried Atmosphere, but the experience was a bit frustrating.
I spend a lot of time playing with this framework and I ended up that it was not completely developer-friendly. First of all is a maven-based project: in addition to the documentation a developer has to learn (or at least to know) how maven works and what's a pom.xml is.
Concepts looks easy, but it's plenty of java annotations, that in my opinion tends the make things too complex. The strength of this framework is that is able to decide and use the protocols supported by the client.
From what I have read node.js appears to be the more developer-friendly.
What do you think about these technologies?
I am the project leader of CometD, which is a web messaging framework that is transport agnostic (websocket with fallback to http) and ships a lot of features like message acknowledgement and clustering and many others.
CometD is also based on Maven, but its artifacts can be consumed with any other build system you already have (Ant, Ivy, Gradle, etc.).
CometD concepts are pretty simple, and you can write services that are either annotated or use inheritance.
CometD scalability is awesome: a single server in our load testing was able to handle 200k websocket clients, and other people reached even more (https://twitter.com/myBuzzNight/status/388024046027161600).
The CometD learning curve is quite low, from the reports I have.
One guy setup e-chat.co in few days.
You can setup a skeleton CometD project with a one liner or even use a pre-made skeleton project used by the CometD tutorials.
JavaScript being the language it is, you'll probably find that if your project grows beyond a certain size you want to stay with a statically typed language like Java for its refactorings, tools, IDEs, etc., not to mention the tools that are available for the JVM for monitoring/management, etc.
The scalability of the JVM in multithreaded scenarios like server-side event-driven applications is well known.
Like other solutions, CometD is backed by a company in case you need professional support.
I highly recommend node.js.
It's coded in javascript, and I personally really like being able to stick to web languages.
Also, you can use socket.io, which implements websockets using node.js.
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
We are developing an application integrator which sends requests to various webservices simultaneously, aggregate data return by each webservice and format it to display on UI. Each webservice may have proprietary xml format. Also we don't wont to compromise user experience.
We identified ESB(Servicemix/Mule) and Async Http Client for this requirement.
Can anyone suggest which would be better option? Async Http Client seems good fit as it is lightweight over servicemix.
Thanks,
Amit Patel
you can also just use Apache Camel for this...
It supports a wide range of components and messaging patterns, is lightweight and has a flexible deployment model (standalone, spring, maven, webapp, OSGi, etc).
You have answered your own. Yes ESB is good option. You can use Mule.
Second option is Asynchronous messaging but it will be complicated, because You have to orchestrate the services properly.
eh, we did a productivity test on coding pure java vs. ESB (mule and spring integration). We had 3 developers do the same thing in all 3 versions (mule, SI, and just pure java with no ESB). They finsihed 6 times faster when not using an ESB and we gave alot of things in the problem that would leverage the ESB, but in the end it did not help....all the xml coding and confusion of the api usages led to really unproductive development teams. Not only that, it is hard to find ESB developers on the market as well.
NOTE: We even took an advanced spring integration guy that had been doing it and he also was faster in pure java to complete the code. He loved spring integration and after taking my test, he changed his mind.
ie. be warned of the huge productivity loss that using the wrong framework can cause. 6 times is a huge penalty. I mean 1 month vs. 6 months is a big difference.
A 6 times productivity loss is worth taking one week out and doing your own developer productivity test. Some argued with me that they didn't know the framework yet which is why we got an advanced spring integration guy to take the test.
Also, make sure your test takes at least an hour or so....just develop some fake but realistic requirements from the application that you are going to write anyways so you make progress on your application while running the study. I would be interested to see more results posted as well.
As per your requirement, I would suggest you to go with WSO2 ESB. Its and 100% free and open source ESB (Apache License 2) and unlike other ESBs, with wso2 you don't have the commercial and community versions. So, what you download for free from WSO2, comprises of all the features that are available in 'commercial versions' of other ESB vendors. Also, WSO2 offers not just an ESB but a complete SOA Platform for your SOA needs.
For the requirement you mentioned above, there is a simple sample that you can try out.
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 5 years ago.
Improve this question
I'm a java developer, not seasoned, but I am familiar with most concepts reasonably well.
I recently built a website using Tomcat/JSP (~30 dynamic pages). I made the newbie mistake of including large sections of core logic in the JSP, using the rationalization that it's "just a simple project".
I learned the hard way. So I'm re-building the app now in google app engine using servlets and planning to use Velocity to implement it using a Model-View-Controller design pattern.
I'm also looking at Struts, but haven't used the framework before.
Can someone convince me why I should incorporate struts into this project? Is it really going to buy me a lot for a medium sized project of one or two people?
There is a clear cost in an extra learning curve with strut, will the benefits outweigh the costs? Or will the use of Velocity be enough to segregate the logic? Opinions?
I would look longer term than this project. As you saw, first time you use any technology is largely about making mistakes and learning from them. So this first project won't likely be a shining example of Struts usage once you're done.
Using Struts (and Tiles from what you indicate was a main concern: JSP copy and paste) will however be an excellent delve into "proper" MVC, i.e. it forces you to do things in a particularly structured way, and one which I happened to appreciate a lot, I was a big Struts fan.
That said, there are other options, e.g. Spring contains Spring MVC plus much much more. If you're going to invest in overcoming a learning curve, think about which framework will most benefit you overall in the medium term: which frameworks do employers in your area tend to look for, for example? At this point in time, I would go with Spring where I feel the momentum is but Struts is very good at what it does.
If you're going to learn a framework then I'd recommend Spring MVC over Struts. The learning curve isn't too steep and there are lots of Spring resources available on the internet.
Once you've got Spring in place you will find your application is much simpler to maintain and support. You'll also be able to add enhancements, like security, a lot easier.
First: don't let the name confuse you: Struts2 and Struts are very different frameworks.
Second: changing from JSP to Velocity can be a good or bad decisition, but that's not exactly the point. The point is to switch away from Model1 (rather ancient nomenclature, but still useful). That is, decoupling your view layer from your logic layer. (You can use JSP or Velocity for your view layer).
Furthermore, to decide your view layer is just a part of your architecture: you still must decide who will process the request and produce the data that will be sent to the view. The most basic option is to use plain servlets, but, again, it's better to use some framework. For this, there are a lot of frameworks in Java. The "action based" ones are a subset among them, perhaps the most simple to learn. Among them, the oldest is Struts; today the most used for new projects are (in no particular order) Struts2 , Spring MVC and Stripes - they are quite similar.
Learning to separate the logic is excellent. You can do that without using Velocity, Struts or any framework whatsoever, and you'll likely learn more about what it takes to do this separation if you try it with minimal help first.
Learning a framework (in fact multiple frameworks) is also worthwhile, but I wouldn't personally choose Struts as a first framework unless it's the one used by your employer or a prospective employer. If your employer is using Struts, I hope it's Struts 2, as Struts 1 is getting ancient.
The framework I like to work with the most is Wicket, but it's a radical shift from what you're currently looking at. SpringMVC is also definitely worth a look.
If your employer is already doing web development in Java using a framework, try to learn the framework that's actually in use, and ask your co-workers for help learning it.
Why you should learn Struts? My answer is: because employers often require knowledge of it, especially for maintaining of older projects. I didn't make any precise measurements, but I think that at my region JSF and Struts are used for web application development most often.
Struts is a quite old web framework, and it's quite clumsy to write modern AJAX GUIs with it, so there were created better frameworks. JSF is for me a bit less clumsy, but also has some problems. My favourite web frameworks are Vaadin and GWT, but I'm not suggesting anything for you - you should make the decision by yourself.
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
We are a start-up, with a few (14) clients using our products. These products were developed in a closed source web development framework only maintained by one developer on the core.
Basically the framework server is required to be able to run any application built in it. So there is no code, in our layer of the application. Think of it as a CMS that allow us to develop in a proprietary language of the framework server itself.
This framework is built on Java, and is closed source. It has a layer of plugins that need to use a proprietary IDE to build them.
There is at this moment only 3 total developers in the company mother of this framework, one that is able to code on the framework itself, and 2 that are able to code on the IDE to build plugins. We are the only company holding paying the salaries of 2 of the 3 developers, the 3rd is the owner.
At this moment we don't know if there is documentation for the framework level.
We know there is no documentation for the plugin layer.
The ONLY reason keeping us developing in this framework is that we already have invested in it, and changing will cost us.
I am in the middle technology management, and I have been advising my IT Director/President of some changes, but apparently I am not getting through. I am advising to start developing new components in another framework (ASP.NET MVC, Symfony, SPRING MVC) with our own team of developers, and this components to integrate 100% with our old application, until we get comfortable to a point of porting the old applications from the old framework to the new one.
Either way there could be many variations of this plan. Any advice from knowledge of SO.
As an alternate question:
Why would you build a business on a close web development framework that only has one developer and no documentation?
Last Comment:
I think that probably Bruce is right. My upper management team is more concern about continuing to sell and support our current product than to the risk that constituted continuing with it. Probably when we grow from 14 clients to 30 clients they will see the lack of scalability that we own, and take some other actions but for now. I think this battle is all done until 2011. Thanks for your input.
Scrap it and migrate as fast as you can because you're only throwing good money after bad. This is what is known as the Sunk Cost Fallacy
Management in a small company is concerned about staying in business and satisfying customers. If the current architecture is supporting that, then the managers will be happy and resistant to change. If business is shaky, they may not have the resources (cash) to support investing in the time and tools for developing a new framework.
If the business is doing well enough to support investing resources in the new framework, it is up to you to make the case that the Return on Investment (ROI) will be worth the investment. They can then decide if they have enough time and cash to pay for the change.
The cases for changing would be:
Measurably improved development efficiency.
Measurably improved quality.
Noticeably increased functionality.
Risks associated with staying with the current platform.
From what you've said, the major road block to changing software is that the owner developed your current undocumented code.
Focus on bringing the owner on board with you. Once the owner votes for changing to new code, you'll be able to get something done, until then you're probably stuck with band-aids.
Looking at the current development on the market, the only reason is a bad strategy.
You may try to open the product on a dual-license base, but if there is no documentation, it is unlikely that developers from outside will jump on it (although maybe the IDE could help a little bit at that end).
Stipulating the change could be based on a risk vs. opportunities assessment.
From the scenario you describe, I think that a central factor to be considered seriously is Human Resources:
What happens if people come and leave?
How likely can growth be handled?
Also seriously consider the knowledge part of the picture: as an organization you need to manage a better equilibrium between tacit and explicit knowledge.
Maybe try to determine the barriers for change (individual and organizational) i.e.:
ability (can, to be aware of),
readiness for change (want, should),
shared reality,
system thinking
analyze them and integrate results to support a more informed decision making process.
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 8 years ago.
Improve this question
Since Spring is able to use transactions just like EJB. For me, Spring is able to replace the requirement of using EJB. Can anyone tell me what are the extra advantages of using EJB?
Spring was developed as an alternative to EJB right from its inception, so the answer is of course you can use Spring in place of EJBs.
If there's an "advantage" to using EJBs, I'd say that it would depend on the skills of your team. If you have no Spring expertise, and lots of EJB experience, then maybe sticking with EJB 3.0 is a good move.
App servers written to support the EJB standard can, in theory, be ported from one compliant Java EE app server to another. But that means staying away from any and all vendor-specific extensions that lock you in to one vendor.
Spring ports easily between app servers (e.g., WebLogic, Tomcat, JBOSS, etc.) because it doesn't depend on them.
However, you are locked into Spring.
Spring encourages good OO design practices (e.g., interfaces, layers, separation of concerns) that benefit any problem they touch, even if you decide to switch to Guice or another DI framework.
Update: This question and answer are five years old in 2014. It needs to be said that the world of programming and application development have changed a great deal in that time.
It's no longer just a choice between Java or C#, Spring or EJBs. With vert.x it's possible to eschew Java EE altogether. You can write highly scalable,
polyglot applications without an app server.
Update: It's Mar 2016 now. Spring Boot offers an even better way to write applications without Java EE app servers. You can create an executable JAR and run it on a JVM.
I wonder if Oracle will continue to support the Java EE spec. Web services have taken over for EJBs. The EJB solution is dead. (Just my opinion.)
First, let me say it clearly, I'm not saying you shouldn't use Spring but, because you are asking for some advantages, here are at least two of them:
EJB 3 is a standard while Spring is not (it's a de facto standard but that's not the same thing) and this won't change in the foreseeable future. Although you can use the Spring framework with any application server, Spring applications are locked into both Spring itself and the specific services you choose to integrate in Spring.
The Spring framework sits on top of the application servers and service libraries. Service integration code (e.g. data access templates) resides in the framework and is exposed to the application developers. In contrast, the EJB 3 framework is integrated into the application server and the service integration code is encapsulated behind an interface. EJB 3 vendors can thus optimize the performance and developer experience by working at the application server level. For example, they can tie the JPA engine closely to JTA transaction management. Another example is clustering support which is transparent to EJB 3 developers.
EJB 3 is not perfect though, it is still lacking some features (e.g. injection of non managed components like simple POJOs).
Pascal's points are valid. There are, however, the following in favour of Spring.
EJB specification is actually a bit loose, and therefore different behaviours can be observed with different application servers. This will not be true for the most cases, of course, but I've had such a problem for some "dark corners".
Spring has a lot of extra goodies, like spring-test, AOP, MVC, JSF integration, etc. EJB has some of those (interceptors, for example), but in my opinion they are not that much developed.
In conclusion, it depends mainly on your exact case.
Spring is meant to complement EJB, not to replace it. Spring is a layer on top of EJB. As we know, coding of EJB is done using API, which means we have to implement everything in APIs using the Spring framework. We can create boiler-plate code, then just take that plate, add some stuff to it, then everything's done. Internally Spring is connected with EJB -- Spring wouldn't exist without EJB.
The main advantage of using Spring is that there is no coupling at all between classes.