Jboss for three-layer client server architecture
I am developing a system in which I have 2 nodes: 1 node with a web server that serves up JSP pages and forwards requests to web services to another node. In this other node, these web services redirect eequests to the business logic layer, which then interacts with the DBAcccess layer.
Is JBoss the right fit for this layout? Do I have to deploy 2 copies of JBossAS, one in each node?
thank
source to share
You have two nodes, which means two separate machines? [There is another meaning of the word "node" common in WebSphere-land, just to make sure we are using the same terminology.]
First node needs to do servlets and JSPs. Java EE servers do this, JBoss does Java EE, so use JBoss wisely. You can use other Java EE servers, but the little you said doesn't give you any reason to avoid JBoss. So one copy.
Second node, WebServices and some business logic and some DB access. Again Java EE does things like this. There are alternatives, but if you already know JBoss, why not? If you are using JBoss in node 1, I would not choose another Java EE server in node 2. [I have no experience with non-Java EE solutions in this layer - no doubt Spring afficionados could comment.] So if here used Java EE, then JBoss, another instance.
This leads to the question, why are the nodes separated? One reason might be that you can scale the Presentation and Business tiers separately. Hence, in the long run, you can have at most two JBoss instances.
Strong tip: Design right from the start, assuming you can scale that way. It's too easy (for example) to create huge Http sessions that don't work in clusters.
source to share
This is an old question about where to implement the "business logic layer"
Observe the checklist and if you have most of the yes answers then use EJB (aka JBoss), otherwise think of simple beans over DataAccessLayer by java code.
- There are dull or dynamically changed rules in your business.
- You are unsure if a DB or product can change the DB engine during its lifecycle.
- Scalability means to you.
- Your product needs to be exposed to functionality via an interface (not over the Internet) to third-party components.
- Your database lacks functionality to implement complex business logic (eg derby - fast but limited).
source to share
Thank you for your responses! Let me explain a little more about the project.
We are developing a geographic information system for a client who asked that the core functionality is a group of web services that provide the processing of CSV files according to some business logic. The client also requested that we create a web interface to use this service (although they (web services) may be used by some other application). They also told us that these 2 servers could be on separate nodes / machines. In the area of database access, another limitation has arisen: 2 servers work with 2 databases, and these 2 can also be on separate physical machines, which gives a total of 4 nodes!
So my question was whether it made sense to use 2 instances of JBoss or Spring AS on two servers, and which of those two technologies would be the most appropriate for it.
source to share