Java跨Web应用程序的通信设计？

Question

We're designing two distinct systems which can be simulated by the following typical example.

Web App #1 - Course catalog (allows updating / populating the course catalog)

• Professors
• Course (courseCode, professorId, list of Prerequisites, grade scale used)
• Prerequisites (courseCode and minimum grade required)
• GradeScale (ie AF, 1-100, pass/fail)

Web App #2 - Student catalog (handles students registering for new courses, seeing their transcript, etc)

• Student
• Transcript (what courses did they take and what final grade)

Data that needs to pass between the two systems (there will be more calls and stuff that needs to be handed back and forth, but this gives the idea that it's a 2-way flow of questions and answers):

1. Does a student have the pre-reqs needed to take a particular course?
2. Pulling details from the course catalog to create a full transcript

From reading, it seems our options are:

1. Create EJBs for the underlying data model, then have the web applications use the EJB interface.
2. Use a REST or Web Service interface between the two applications.
3. RMI or other Java remoting?

Which way would you cut this up into JARs/WARs/EARs?

Answer 1

This was initially a comment but it's actually too long.

If you got only simple imperative services (set this, do that, is this valid?), then you can go for an AXIS2/SOAP based web services solution. (you probably won't need the whole bloat of SpringWS). If the app logic is not too twisted, I'd follow KISS principle.

I don't know your system scenario, but if you're using a full fledge RDBMS, it's high probable that the database will reside on its own machine, thus having different pools connecting to it, is not much of a burden. (if you're using a local db on each AS, you're probably going to face some scalability problems later on).

In modern Java EE app servers you can actually use connection pools of one server from another (via jnp:// urls), it's just a matter of JNDI lookup.

If the db engine supports it, oracle alike db links are also a good way to share a database between apps.

You can spare code times by having a business/data layer in a simple java project with all the ORM stuffs, shared across the 2 web dinamic projects, so eventual changes in business logic will reflect onto both apps.

You can also tryout the mixed way (simple imperative Web Services and database share), it really depends on what messages are exchanged between the two applications. You can provide a layer of web services API (SOAP or jsonp based), but take into account execution time of the web service itself (it's not so good to have time consuming ws).

Web Services and EJB are good and probably can do what you need, the real question is: do you really need them ? lately I've seen lots of project starting with the full REST thing, and in many cases it was like killing flies with a bazooka.

If the requirements are simple, then keep it simple.