I am a beginner of EJB and java EE in general, but with good knowledge of Java as a language itself
Currently I am on the project of what we call "Switching to EJB3 and JBOSS"
We used Weblogic (older version with ejb 2.0) and I have to now convert everything to EJB 3 and clients to be setup with webservices.
So, the issue is: I have stripped the server side component of all weblogic related stuff, rewrote some of the code to conform to EJB3 environments.., deployed it to JBOSS. It worked out in a simplest terms.
But are there standardized patterns to how to use existing EJB server side components and writing new client with webservices. Or is it a a gray areas, where I have to develop my own architectural strategy ?
The issue is, that I can't even use the standartised eclipse/net beans tools, since our project structures/build system is a little outside on how tools would organize things. Not much, but .. still. And this can't be changed !! (unless I want to undertake a role of managing all the build support for the whole company )
Good question. Since each project has its own structure, bad practices and burdens it is pretty hard to form a 'one answer for all'.
From my experience in migrating projects, here is a list of checklist not to carry over or inherit the problem areas..
- Try to migrate some simple services (which seems like you already did) and see if it can still live next to non-migrated parts.
- One huge goal for me is to remove non-standartds in terms of development environment. IDE dependencies, build tricks, non-standard structures are the worse stuff you can keep for the future of your project. It may take some time but it will definitely take more time in future to fix if not done today (it takes time today because someone did not fix it in the first place in the past!). A project can never be dependent to an IDE (i am an eclipse commiter! but neven personally only depend on eclipse). Externalize everything to maven, gradle ant or mix match. I agree changing something company wise is a huge problem but as an engineer I personally can't accept the fact doing it the wrong way because my colleagues do so. What if doctors also followed the same way and operate an unusual way just because his colleagues do so?
- Next step is usually removing old habits. Yes, J2EE asked us to create interfaces even for other interfaces but Java EE does not (actually encourages the opposite). Keeping the old habits in a migrated project is not different than trying to keep a thick accent while learning a new language. You will definitely carry over the accent because of your past but why trying to do it worse. So just make sure to read specifications and best practices before moving to a new version/platform or framework.
- Trends shape the architectural strategy. If the project was designed early 2000s, most probably it has exaggerated SOA architecture which would be the for REST in early 2010s and micro services today. None of those are bad but needs to be used when needed, not for the favor of using it. Taking a look at the overall architecture to remove those trend overdoses can also be very helpful.
- I personally start the migration with...
+removing unnecessary interfaces and facades which were very popular in j2ee.
+implement a proper DI, specially if it is a pure j2ee project without spring
+remove any 3rd part jar which is not needed in Java EE (move quartz to timers, cxf to jax-ws, any 3rd party DI to jave.inject...)
+try to implement factories and make use of observers
+build a proper event approach
+simplify the DAOs or even remove them if not needed