I'm using JBoss Seam Framework, but it's seems to me isn't very popular among java developers.
I want to know how many java programmers here are using it, and in what kind of projects.
Is as good as django, or RoR?
In our JBoss Seam in Action presentation at the Javapolis conference last year, my colleague and I said that 'Seam is the next Struts'. This needed some explanation, which I later wrote-up as Seam is the new Struts. Needless to say, we like Seam.
One indication of Seam's popularity is the level of traffic on the Seam Users Forum.
I have used JBoss Seam now for about a year and like it very much over Spring. Unfortunately, I don't use this at work, more for side projects and personal projects. For me, it saves me a lot of time developing new projects for clients. And, one big reason I use it primarily is, the tight integration with each layer and I never get any lazy load errors that I used to get with Spring (even after the filter and other hacks).
An equivalent Spring application would have much more boilerplate code within it to get stuff working. Spring does not integrate each layer very well, it more or less is a wrapper for a lot of different things, but doesn't glue itself together very well.
The other nice thing I like with Seam is they practice what they preach. Take a look at their website. Take a guess what it is running, hmm, a live example of their code. Seam Wiki, Seam Forums, etc. If you truly believe in your code, stand behind it. I would be happy to have their pager 24x7x365, I bet it rarely goes off.
While you write a lot less code, the learning curve is about twice as steep. The further I get in, the more I understand how to write good code. I would like to see more comments, but as far as coding style, it is well written.
On the negative side, just as any product you try to market, Seam was years after Spring had already become popular so Spring is by far still more popular. Search on Indeed and Seam only has a few hits. If you look on Spring, there are roughly 40k registered users, while Seam has about 7k.
Depends on what is important to you, as a Java developer/engineer/programmer, you should be able to work with both technologies and chances are, you will most likely encounter a Spring application before a Seam one. Learn both and how to leverage both. If you use both properly and know the nuances and quirks of each, development becomes much easier whether you're using Spring or Seam.
I don't agree with the statement, "Seam is the next Struts". Struts was a view technology whereas Seam integrates all layers. I will agree that it is a new concept like Struts and will bring the same impact to the Java community that Struts did. I don't think we'll see that until Java EE 6 and CDI become more popular, and of course Seam 3 is released.
Walter
Seam is fixed JSF based on annotations. No more crappy XML. I used it at work.
Hope this helps a little, but at my college our web applications course just got revamped. So now we are going the jsp, servlet, hibernate route with the second part of the course on mostly JBoss Seam. So who knows, it probably just needs time to grow in the community.
It really works for us....JSF+EJB3.0 with the help of seam framework is really fantastic.But i have a question...why this is not becoming more popular for developing large scale application.I have seen that many are using other frameworks for developing large scale j2ee application.It seems to me that seam really helps the developers to build a j2ee application...but still ...why this but coming in?
I like Seam, have been using it for the past year professionally.
However, the question concerns its popularity. I can see the following indications that it is not very popular (at least in comparison to plain JSF or Spring):
Its forum is very inactive (at least at this point, they are working hard on Seam 3). http://seamframework.org/Community/SeamCommunityForumSlightlyInactive
You can also take a look at its comparison with Spring in Google insights for search: http://www.google.com/insights/search/?hl=en-US#cat=732&q=seam%2Cspring&cmpt=q
I only know one other company here in Athens where they use it, and I know a handful of companies that use plain JSF, Struts or Spring (of course, Athens is not representative for all the world).
I would say that seam is a rather popular framework, it has great documentation, a great and helpful community and a forum with many many questions and problems answered.
It should be popular among developers who use jsf beacuse it works great with jsf, but not only that... it fixes jsf in many ways (s:convertEntity tag, and unified component model are my favourite examples).
We have been using Seam for a while in huge projects.
Easy to kick-off a new project, reverse engineering is very handy.
I have used JBoss Seam on two commercial projects for two different clients. Yet JBoss Seam is still a new approach to developing JSF Web Applications. One measure is the results from a Indeed Job Search.
Indeed Job Search
When Java was introduced in the 90s as oak the community did not embrace it because it was too powerful for its time and was appreciated later on and is now running the show. Seam will get popular soon. if not it can be rebranded just as oak to java.
I have been using Seam from Seam 1.2 since 2007 in mid-size and large projects, sometimes in small projects no more than 200 users. My main concern is the productivity. Although my team has already gained obvious productivity from Spring since 2005, for some tricky clients developers have to code javascripts which is time consuming and error-prone. Seam was really helpful in this scenario because at that time most developers in my team had no experience with JSF. Happy to see Seam being more popular.
Seam has been discontinued in 2012. However, Apache DeltaSpike is the modern version of Seam, and this project is actively maintained, and it even won the 2014 Duke's Choice Award.
Related
Ive heard bits and pieces about Seam and Weld in Java 7, and am trying to figure out how they relate to Spring. Any pointers to good references appreciated.
Spring might some day become obsolete for new projects. Still, in the last X years almost every Java EE project was done with atleast a bit of Spring technology (in my experience), so there is a lot of software out there running Spring ( I am currently on a project which uses Spring 2 ) and that isn't going to change in the near future. Corporation don't change a running system just because the new Y technology is out. (As all the COBOL software laying around painfully demonstrates)
So to directly awnser your question, I believe that Spring knowledge will remain a must for many years to come.
No. As others have said Spring is more than DI and is established.
The reality is there are three entities competing (and in some cases working together) for more users/developers.
VMware aka Springsource
Redhat aka JBoss, Seam and Weld
Oracle aka Glassfish
I would like to believe that each one of these companies doesn't have an agenda but the reality is they do and they want you to use their technology. You'll often see developers (employees) of each project vehemently trash the other project. Avoid this and make your own opinion by trying each.
Spring is much more than dependency injection, although DI is at its core and many people receive no more of it.
I worked with both Seam and Spring and found a surprising number of things possible in one, but not the other. They do not cover entirely the same area. Where they do, they are both viable alternatives. Spring is actively maintained. I cannot see it die anytime soon. That was the answer to your question heading.
To address the body of your question: Sorry. I’d be interested in a succinct but in-depth comparison as well.
I am looking to start work on a brand-new project, something I've been thinking about for a while as my first independent sellable project.
It's broadly speaking a web-based service application, and my first choice, server-language is quite easy... I know Java pretty well from working on Java web-apps in the past.
However my experience doing web-apps involved JSP, Servlets and JSTL... I know the ideas behind newer technologies like Hibernate/Spring but have never used them. So we wrote our own DAOs, handled AJAX by writing special mini-JSP pages that generated XML/JSON pages, etc.
I'm not hugely into the idea that Spring/Hibernate are the 'only' or 'right' way to do any Java web-project, but they are widely used. On the other hand, not only would trying to learn these increase initial development time, but I'd be using my learning attempts to build a production system.
I remember one of Joel's early articles said (I'll paraphrase since I can't find it)
"regardless what's cool, always use
the technologies that the lead
developer (or dev team?) knows best"
I wondered what people thought about that?
ps: should this be CW?
I work as a consultant, and I've seen a lot of projects where the devs started out with servlets+JSP because that's what they knew, and it's pretty simple to get started with. However, it gives the team an opportunity/excuse to write a platform of their own, which is more fun than using someone else's and just writing an application.
As the project grows, the team reinvents more and more wheels, quite a few of which end up square. That's where I enter the picture - adding new stuff to this semi-flexible platform has become so complicated that the devs can't keep up adding features and fixing bugs without calling in reinforcements. Just to add insult to injury, the internal devs are usually the ones who get assigned to do the boring bug fixes because bug fixes require more knowledge of the gory entrails of what has become the team's proprietary persistence-and-web framework, and so those gosh-danged consultants get to do the new, fun stuff.
Now, you shouldn't use a framework just because people have been regurgitating each other's blog posts about the awesomeness of it, but you should also realize that there are very good reasons why those frameworks exist (and why they're used). If you haven't used any web frameworks at all, I'd recommend you to take Spring MVC, Wicket or whatever for a test drive. They don't solve all problems, and they do cause some of their own, but the grand total is usually a productivity increase, especially if you're making advanced user interfaces.
I have been on projects where plain JDBC has been quite sufficient for persistence, and where no more advanced web frameworks than servlets+JSP have been needed, but those projects are a minority. Without having used a framework or two, you'll never whether your project is part of that minority that doesn't need one, or if it is part of the grand majority that does.
Don't try everything all at once - take on one new technology at a time.
Beware the lure of cool new frameworks! I'm currently hacking on a tiny little web app that just has a login, a few mostly static pages, and a few forms to request some information by email. It would have taken me maybe two days to do as traditional Servlet/JSP in MVC style. Instead, since there was slack in the schedule, I decided to use this project to get up to speed in Spring, Spring MVC, and Spring WebFlow. While it's quite possible that I'm just dense, it took me several weeks to get my head around the right way of doing things, I'm still not totally confident that I'm doing everything correctly, and the application is still not done. Fortunately, due to slack, I'm not in danger of the overall project schedule slipping, but I'm always asking myself if I'm going to have to scrap it and start over.
I have learned my lesson, though: next time, I won't be the one pushing a new framework unless its one I've used for production projects before. That said, I'm glad I now understand Spring (or at least I think I do) and will not hesitate to use it again next time.
So how would I learn a new framework next time? If there's a project lead (in this case I'm a project lead of a team of one, no help there) I'd use the framework that they put in place. If there isn't, or if I want to learn a framework that the project lead isn't using, I'd use it for a side project on my own time. Learning is good. Putting company work at risk by throwing untested technology at it is not so good.
I can say for sure that Spring is worth considering. It gives you as much as you can take, but it doesn't bother you with things you don't need.
For example, at the very beginning you probably need dependency injection only. Then you'll need help with database interactions and transaction management. Then you'll decide to apply MVC patter to your web-application. After that may be you'll realize that components of your system are to send JMS to each other. And so on and so forth.
For all this cases Spring has it's own simple, intuitive, light-weight solution.
When starting a new project limit the number of unfamiliar technologies / frameworks to use. Every framework takes time to learn and every framework has issues especially if not implemented correctly.
If you can I would recommend you look into the Play framework. It is a web framework for Java that focuses on developer productivity. You can choose to use Spring / Hibernate if you want but you are not bound by that. It has a very easy to learn implementation and you should be able to get a good idea within a day of playing around with it if it is what you are looking for.
It depends what the customer wants (in the world of consultancy).
You have to learn new technologies. Does the customer wants to pay for that?
Not all the caveats of the new ones are known, whereas the older ones are proven a lot more.
Of course, if everybody thought like this we would all be stuck with VB these days. You have to look for the right balance, and learn a lot yourself too so you can get an objective view on the technologies available, their up and downsides.
i personally would definitely recommend looking into spring, i've found it's saved me countless hours. hibernate is also useful if you need an ORM layer (and spring has nice integrations with hibernate too). they're certainly not the 'only' or even the 'right' way to do things (that's quite subjective) but they have both saved me time and effort, especially spring.
There is one major trap with any unknown technology. You do not know where the dragons are, and you do not know how to rub the new technology "with the hairs".
Learning that will take time, and you need to have that in your estimates. Also your estimates will most likely be too low...
Greetings, everyone. I consider myself to be an intermediate developer, but, to be candid, probably closer to novice than expert. In any case, I have more experience with C# and the .NET platform, but my current job has me working almost exclusively with Java. This in itself is sort of a problem, but I'm dealing with it fine and I'm not really in a position to change my role at the moment.
On the side, I am starting to work on a highly interactive, database-driven web project. I'm doing it because I feel that it's a great idea and I know that the experience of doing something like this from scratch will help me immensely.
I initially wanted to go with ASP.NET MVC and I am still leaning that direction. I'm not even sure why, but I love the community behind it and, in my opinion, Visual Studio is the best IDE around. However, doing that would be counter-productive to my current job. That brought me to Grails. Even though I realize that Groovy is not Java, it seems to be similar enough (not to mention that it runs on the JVM) that the skills I learn should still help me at my current job. The more I looked into Grails, the more I loved it, especially after having to deal with what I consider to be an extremely complex J2EE environment at work.
But with the good I found the bad. I can't help but notice that there are a lot of developers who are irritated with the amount of bugs in Grails. Being that I am starting a new project and I am fairly inexperienced, do I even want to consider Grails? Is it a liability? And what's the consensus about its longevity? I would really hate to get too involved if there is a good chance of it fading into obscurity within the next few years. And even if the bugs and longevity issues aren't a huge deal, how would you compare the ease of development of Grails with that of ASP.NET MVC? I realize this last part is highly subjective. But for the sake of comparison, let's say that someone with virtually no technical background were in the same position. Would you recommend they take a look at ASP.NET MVC or Grails?
Thanks so much. If anything needs clarified or reworded, please let me know. I sincerely hope I'm not opening a can of worms...
I am the author of this question and I can give you some shares on my own experience.
As it is stated in the question, I had no real preferences and I was opened to any technology/platform that could fulfill my requirements. After many tries of different technologies (at leats few days with PHP, Rails, ASP and Grails) and some answers from StackOverflow, I ended up with the same dilemma as yours : Grails or ASP.NET MVC ?
And I chose Grails. Why? Because of GORM. Almost only because of GORM. This is fantastic to deal only with your domain classes and have your DB schema automatically generated/updated. Of course, it has its limits but this is so powerful for querying and maintening your DB. You do not write SQL anymore and it is very easy to learn.
Now here is my 2-cents comparison of the 2 technologies:
GRAILS STRENGTHS
GORM (see above)
Complete Web Stack Framework : you can generate a website in minutes and everything is already configured
A lot to learn : You have Spring MVC, Hibernate, Sitemesh, Java, JEE, Groovy...Once you have mastered Grails you can add an additional page into your resume
Java world. Whatever you need, if it already exist in Java, you can use it.
Groovy : I really like this programming language. It takes time to get familiar but once done, you will love it.
GRAILS WEAKNESSES
Memory usage. Grails/groovy is greedy for memory and it might cost more than ASP for Web Hosting
Grails bugs : there are some and when you start a new project on a new technology, you assume that most of the problems come from you...until you find out (after 1 or 2 days) that it is a Grails bug. So my advice is to proceed by steps : test as soon as possible and don't try to twist the framework. It is rough on the edge so go after what is generally recommended. However, after 2 months, I do not encounter big problems anymore.
Debugging : due to the multiple layers of frameworks, errors are generally hidden inside tons of exception lines. Also, the only decent IDE debugger is IntelliJ but this is not as easy to debug as .NET under VS
ASP.NET MVC STRENGTHS
The community : it's HUGE ! First it is supported by Microsoft and secondly 30% of the websites out there are built in ASP.NET. You can find any snippets of code, any widgets, any AJAX components, any CMS...Grails community is very active but can you rival against millions ?
Visual Studio : I definitely agree with you : there is no better IDE. IntelliJ is very good for Grails but having using both, I prefered VS
ASP.NET MVC WEAKNESSES
The youthness of ASP.NET : this is a young framework. Built on a stable technology but young enough (less than 2 years) to have also some bugs/some bad practices. Indeed, the next version of ASP.NET MVC is strongly awaited by the community.
Microsoft : even if ASP.NET MVC is open-source, you are totally dependent on their decisions (and prices).
The Bottom Line
If you project has tight deadline and if it is crucial for you to succeed, then go for ASP (according to your background). Otherwise, give a try to Grails..don't worry, you will also succeed but it will take more time. I am also deeply convinced that Grails has just started its long journey and it has a great future (see google trends)
Update by Dmitriy: If your refer to Google Trends you have to compare the 2 of them Groovy Grails and ASP.NET MVC.
Good luck
This is something that's been pretty much asked before here...
http://74.125.155.132/search?q=cache:BpGj8RtSUIsJ:stackoverflow.com/questions/1283935/what-technology-asp-php-joomla-rails-grails-for-a-website-from-scratch+Which+technology+to+choose+%28ASP.net+or+Grails%29&cd=1&hl=en&ct=clnk&gl=us&client=firefox-a
Good Luck though!
I work in a medium to small team ( 10 people ) developing and supporting several web enterprise applications.
We have a dozen of them built with a house-made framework with asp-classic working against ms-sql server.
We are evaluating the migration to a new development stack.
We'd like it to be open (free) and simple.
I've been looking around the java web frameworks, but all of them seem to be extremely overbloated for our needs (with the possible exception of http://www.playframework.org/, which I couldn't study yet...)
We are thinking about porting our own framework to this new stack, rather than adopting a whole new stack that we are unaware of ...
so far now, we though about the following possibilities
plain java - jsp - jsf
groovy - gsp (no grails at all)
jruby (no rails at all)
we feel really comfortable working with dynamic languages (well, as dynamic as classic asp can be) and with a lean and understandable framework...
I see no small and simple web frameworks for java, like there are for php or ruby...
I really like groovy, but I see no web implementations outside of grails... Besides the language documentation doesn't seem to be quite complete (I might be looking in the wrong place, perhaps)
php could be an option, but I think it would be hard to advocate for it in my current work...
any other option, advice, pros and cons?
thanks a lot
--
edit
some related link Can anyone recommend a simple Java web-app framework?
I'd suggest you take another look at Grails. It does use hibernate and spring under the covers, but for most situations, you don't need to know the details of those frameworks. There's a large community and lots of documentation/blogs/mailing lists for support, as well as a thriving plugin community with over 300 plugins solving pretty much any need.
If you're still put off by grails, you could look into the play framework. I don't have any experience with it, but there has been some traffic recently around it on hacker news and the like. I know it uses groovy for the templating language.
I cannot recommend anything, but strongly recommend that you consider these things:
Rapid development. Basically you want to save a page file, and reload it in the browser. Instantly! It can be done, do not settle for long deployment times.
Plain, readable text files!
Convention coding instead of explicit coding - big XML files will eventually drive one or more developers insane. The less, the better.
Good tool support (just having syntax coloring may be a big help)
Consider the long term support of your choice. You are basically remarrying with your software - will it still be maintained in 10 years? By whom? Will you have alternatives (JSR's are great - look at the amount of servlet engines)?
And WHEN you choose - get the source code for it, and ensure that it builds correctly. It will never be easier than now, and some day you WILL need to fix something inside. On short notice! (You may even consider allocating resources for donating documentation/patches/time to the open source project you are building your business on).
EDIT: A few more things:
You want to be able to verify things at compile time. One of the things that make it possible to build cathedrals in Java is that the static typechecking prevents a lot of nasty runtime errors. "Oh, THAT method? Well, it's not here, sorry. Boom!"
You want good error reporting. Built in! Try throwing a NullPointerException deep, deep down and see what 1) the user and 2) the developer is told about it. Anything that requires going to a log file to get the details WILL cause calls at 3 AM eventually.
Look into scalability from the start. Any non-trivial customer will need to and the world goes to multicores, so you might as well think about it already now. What will you do when all the magic pixie performance dust has been used and it just isn't enough: The application requires more than a single box.
And read this: http://www.pragprog.com/titles/mnee/release-it
You're forgetting about the other major player in this field: the LAMP stack (linux, Apache, MySQL and mod_perl). All components are free, there are many books available on LAMP development and each of these components, and there are vast numbers of libraries and components already available.
Apache: the Definitive Guide
Learning Perl: by SO's brian d foy
Practical mod_perl
If you are afraid of Grails and need Java, try Stripes and read the excellent Stripes book (http://www.stripesbook.com/blog/). You can buy the eBook pdf for $23. The book covers the framework in amazing detail. Stripes is a very strong, lightweight MVC framework that deals with all the common problems of web development (templates, url mapping, form validation, security, internationalization, testing) but it won't automagically create the database layer for you unless you want it to by using Stripernate. You can also use Groovy with it. You can use it standalone or with Spring.
I've had great success in simple web projects using Spring MVC with JSTL JSPs. Spring MVC is a framework that can be kept pretty darn simple (1 additional XML file used for configuration). You can eschew all the fancy options and just specify a set of JSPs that you want to associate with view names, then forward to those views by specifying their names in the controller.
Spring MVC can also easily scale up and be as complex as you need, letting you switch from JSTL to JSTL with Tiles, or Struts, or JSF, or Wicket. It can also handle complex web flows using the Spring Web Flow project. But for most projects I just keep it simple -- build a JSTL JSP, create a controller that provides the objects that JSP needs, and associate them by having the controller return that view. Once you get the project set up and you're familiar with the configuration, it takes maybe a couple minutes to wire a new page into place.
If you like Groovy but don't like Grails you could try Gaelyk, which is a lightweight Groovy framework. However, AFAIK you can only use Gaelyk if you're hosting the app on the Google App Engine
If your apps won't be hosted on GAE, and you really don't want to use Grails, another option is to use Groovlets, Groovy template servlet, GSPs.
However, personally I think it's a big mistake to dismiss Grails. It really is a great framework, and you can go a long way without knowing much about Spring and Hibernate. One of your complaints is a lack of Grails documentation. I think you must have been looking in the wrong place, because in addition to all the books available, there's a very extensive reference document and a lot of other documentation available on the website. Finally, there's a very active mailing list.
My platform of choice is JRuby - Rails (3) because of its very rich and powerful ecosystem, but mainly because:
* very easy to use
* many MANY libraries
* fast support via IRC
* deep documentation
You can also check out Scala + Lift Web Framework ( imho best static typed language, nice framework )
I've been doing "plain old java objects" programming for 10 years now, with Swing and JDBC, and I consider myself pretty good at it. But I start a new job in two weeks where they use JBoss, and I'd like to get a heads up and start learning all this stuff before I start. What are good resources? On-line tutorials, books, e-books, anything you can suggest, especially ones that don't try to teach you the basics of plain Java first.
For quick getting up to speed, you really need to master EJBs and JSP/Servlets. Those are the fundamentals of Java EE technology. The Head First series on EJBs and JSP/Servlets is a good start for what has usually been a mind-numbingly complex framework. Beware that recent Head First editions have switched to teaching the simpler annotation-based Java EE 1.5 frameworks. While the newer version of Java EE is simpler and better, you probably need to know the previous versions (Java EE 1.4 = EJB 2.1 and Servlets 2.4).
At this point, you've only dipped your foot in the water. I would spend a lot of time over the next year, reading up on Java EE technologies and more generally enterprise application development for client-servers.
a) You absolutely must understand data modeling, and databases. The best I've seen are by Chris Date, Steve Feuerstein (if you're using Oracle) and Joe Celko. The better Java EE developers can keep up with their DBAs in technical discussions about the database.
b) You do need to understand how JDBC works, and why ORM tools like iBatis, Hibernate and Toplink came about. Assuming you know how to write a JDBC DAO, then be sure to understand how Hibernate works.
c) You should understand how the layered architecture of a Java EE application. Core Java EE Design Patterns has prescribed typical practice, and it's highly likely that your upcoming project will stick to those patterns. That said, you should also understand alternative points of view on architecture. I've found Martin Fowler's Patterns of Enterprise Application Architecture and Rod Johnson's Expert One-On-One Java EE Design and Development to be valuable. The ideas in the latter became the Spring framework, and has settled into mainstream for how many J2EE developers prefer to develop their apps.
d) Then learn some of the frameworks that have sprouted up around the Java EEE ecosystem. While it's a philosophical question why there are so many frameworks, and which one is better, focusing on the frameworks your employer is specifically using is more than enough.
A couple of answers come to mind:
if "plain old java" is what you're used to, you'll probably need a grounding of plain old j2EE more than JBOSS specific stuff. I'd start with the sun tutorials, but being familiar with the general structure of servlets, the servlet api, is base.
as application servers go, JBoss is (my biased opinion only) insanely large and complicated. Think "launching the space shuttle" and you won't be far off. A million services. It is specifically noted for having an unusual class loader structure (although this may have changed since I used it last, about 1 -2 years ago), among other things. It also has an extensive list of nice services, like a JMX base (management configuration beans) although documentation is likely to be spotty, as support is a paid service.
Best suggestion- familiarize yourself with the J2EE libraries. Next would be to get a basic site running in JBOSS. More specific stuff that you might want to do is likely to be very specific to their installation (e.g. there's a JMS implementation available in there but they may not be using it) as I've seen people use it for nothing but a servlet container.
i would suggest readin a book like Jboss at work
http://oreilly.com/catalog/9780596007348/
We use jboss too at work.. and i read this book and found it useful..
Sounds like me (though definitely not with 10yrs of exp). I started with Head first series for servlet/jsps. I already knew what they were meant for. If you have a good grasp of design patterns and OOPS, Ejbs and other resources would be a piece of cake, Concentrate on why they are, how and what to do can wait. App servers are a different beast, however, going through the admin manuals helped clarify quite a few things. SSL/Certificate stores/Clustering can come at the end of the list. You would also like to learn about ORM tools like Hibernet; alternative view technologies like Wicket, Tapestry etc; Containers like Spring and libraries like struts all can be learnt slowly. The best practices and review posted all over internet definitely help.
The choice of what order to follow, shouldn't be that difficult, as the work place dictates the technologies most of the time.Just remember, J2EE is a bunch of specifications and frameworks are essentially supporting libraries that are targeted to a specific group. It is the designer/developer who holds the key
Learn Enterprise Java Beans