Sorry, One other thing......
Where should I start, if I wanted to start developing on this system. It seems like I need to get proficient with EJB's first and it's foundation, since it seems this technology is what is used to deploy and integrate the programs. Would this be a correct assumption?
It's not that no-one wants to answer but this is quite a wide scope.
Yes, JBoss (and J2EE) can encompass much more than just CMS or ERP, although these are some of the applications that can run in the J2EE framework.
For example, in your case, say you wanted a daily dump of server logs or stats from a particular server commited to a central database - you could build a custom conventional program to process it, creating the custom client-server communication, developing the database write routines and so on. As things progress, you find that you need to add more servers to the list. Now you need to have some scalability to handle load, and you need to protect the database from being overwhelmed. Things become a bit tricky now.
Or you could build a handful of EJBs that link together to handle your database writes, and define a connection pool that will throttle the maximum number of simultaneous connections to your database. Build a simple client that runs on your remote servers, triggered by say the OS cron. It connects to the EJB container, requests a worker unit, and sends the Java data. As more systems need to connect simultaneously the container just creates more work units to handle the load. You don't need to worry about the low level communication handling, the server-like qualities, etc. And you can grow your sophistication as things progress, adding security, authentication and the like as J2EE provides this infrastructure as well - so you can define connection authentication.
I've seen people build the type of system described here from Perl and I'd choose J2EE development for this type of work. And you can extend the EJB infrastructure and couple it with web services or a web front-end easily (for example some systems want to send HTTP or a SOAP message with stats), re-using the existing EJB infrastructure - try doing that easily with Perl scripts.
Each EJB has a well-defined and specific task and is an autonomous unit. You can chain them together to perform quite complex pieces of work.
You can develop using WebSphere. However, there are certain things that are WebSphere specific and IBM specific in the Integrated IDE and the App Server. They both are resource hungry. And they hide much of the inner mechanics (such as deployment descriptors, packaging, etc).
It might be tougher initially developing with JBoss (having to learn how J2EE components are bundled up for deployment), but I think it is worth it. At least if something breaks when projects become complex, you will be able to figure out what is happening. I tend to think JBoss is a better development environment. Deployment is quick, easy and transparent - drop your package in the deployment directory and watch the deployment messages. The just choose an IDE - Eclipse, NetBeans or whatever you are comfortable with. A working knowledge of Ant is going to be useful too.
An EJB book is required as too a book on servlets and JSPs. Usually, as EJBs work with data, you will at some stage want user output and servlets and JSPs give you that capability. I've still got my Mastering Enterprise JavaBeans by Ed Roman (covering EJB specs 1.0 and 1.1). It was a good book on the mechanics of EJB but I'm sure others have better recommendations.
Again, this is not an authorative recommendation but just a starting point. I'm sure there are others with more specific information on things such as IDEs and so forth.
My apologies for being so broad. It was a pretty generic question, and my thanks for your attempting to answer it.
You did a great job! Thank you!
Mostly, I'll have to just keep an eye out to the JBoss development, as I learn the J2EE specification. Mostly the differences between JavaBeans and EJB.
One other quick question, and this is a pretty specific one :)
I would use this, for the most part, intranet/extranet applications (CMS, helpdesk, Expense Reports, MainFrame reporting, etc). Would JBoss (J2EE) still be a better fit, or should I just stick with Jetty or Tomcat (JSP/Servlet) applications?
The jury is probably still out on this. There is hot debate with some claiming EJB is dead and others saying that everything you need to do for most applications can be done with servlets and JSPs.
It comes down to personal opinion. My thoughts, for what it is worth, is that servlets and JSPs are suitable only for the simplest applications where you know with certainty that you will only ever consume information via the web browser.
When your input and output channels may spread, say you need a subset of the information for WAP, a subset for web service consumption and so on, it is best to build the data assembly with EJBs. It enforces a separation between business logic (data management) versus presentation (formatting and delivery). It also helps factor and delineate your transactions.
Unless you are very disciplined, there is a tendency to start mixing formatting with the data streams when coding pure servlet applications. I've seen commercial applications with some very smart code in it, that also contained data with HTML tags in the database. Worse, the managment console was built using a Java GUI, that used different data management routines to those in the web application because the data management factorisation was too messy to use or even adapt for the Java GUI channel. To top that, the transactional code was not well constructed in the web application so that it was apparent and enforced.
So there are a lot to good reasons to use EJBs, particularly if the data is transactional (all or nothing) and you expect the same data to be consumed by multiple clients or injected from multiple sources.
As always though, nothing is absolute - which is why engineers still get paid to make the decisions.
Your thoughts have been well thought-out, and fully justified. I thank you for your inputs and advice! What really impresses me, was your thoughts on both-sides of the coin. Trying not to be biased (although we know you are, being on JBoss forums ;) ) and still giving me the facts.
I appreciate it, very much! Thank you
I would just like to add some more points about how to go about it in terms of development.
As an IDE I recoomend ECLIPSE which is far better then others available and moreover no cost involved.
As it is a framework, you can add various plugins for your particular need.
If u want to write perl scripts, then there is plugin for that and if u want J2EE devlopment there are plugins for that.
You might want to look at Lomboz plugin for Eclipse, which has wizards
for development of different componenst of J2EE including SOAP.
Uses XDOCLET for rapid development and deployment.
Example If u dont use Xdoclet, just to develop a small bean you have to write atleast three java classes (bean class, remote and home interface), and if required then few others helper classes. And then to add deloyment descriptors.
But with Xdoclet you have to write only business methods in bean class, no remote and home interface, no helper classes. As xdoclet genartes these files for you and deployment descriptors as well.
I am not waare of any other IDE which provides thees features and believe me it really speed up the process of development.
I hope this info helps in your decision making.
This is not quite true. Both JDeveloper and JBuilder allow you to concentrate on just the Bean source. Both of these IDE's also have great Ant integration as well. With these IDEs you can also track multiple deployment targets at some cost. XDoclet does appear to be a useful tool, but it is not the only one.
In answer to the original question, moving from PHP to Java J2EE is a quantum leap. There is a lot to learn and it will take time, you cannot go from Hello World to EJB in one step. As for ROI, it would depend on the value to your organisation of the Intranet applications you envisage developing.
Well, thats a good info on IDE's, obviously i am too much focussed on open source tools :-), but dont you have to pay licencing fee for these tools mentioned.
Anyway, and on other query about ROI and from moving to PHP to J2EE.
No doubt its a big step, beacuse not only you need skils in JAVA but some exposure to J2EE technology, therefore there is a learning curve. But has some amzing solutions available with this technology or say standard.