When is remoting not even necessary?

[general_pattonm]

I am working on refactoring my project to use Spring. Currently I have the following standard setup:

Remote Native Client                      JBoss
            |                    |------------------|
            |                    |   Web Client     |
            |                    |         |        |
            |--------RMI-------> |    Session Beans |
                                 |         |        |
                                 |   Entity Beans   |
                                 --------------------
                                           |
                                           DB

As I am pondering how to go about refactoring, the "normal" way to convert this would be to do this:

Remote Native Client                    Tomcat
            |                    |-------------------|
            |                    |    Web Client     |
            |                    |         |         |
            |---Hessian or-----> |   BizLogic POJOs  |
                 HttpInvoker     |         |         |
                                 |     Hibernate     |
                                 ---------------------
                                           |
                                           DB

But what I am wondering is: why do I even need to continue to access my business logic remotely from my remote native client? What is it about the GUI talking through the web tier that is so essential? The business logic is essentially an API of "static" methods that only change the state of the DB, not the business objects.
Why couldn't we have the following: the business logic will be
written once, but "deployed" in two ways: for the native app, it will be
compiled into the jar that runs natively. For the web app, the same code
will be compiled into the war that is deployed to the web server.

Remote Native Client                   Tomcat
|-----------------------|         |-------------------|
|   UI Code (SWT)       |         |    Web Client     |
|          |            |         |         |         |
|  BizLogic POJOs       |         |  BizLogic POJOs   |
|          |            |         |         |         |
|      Hibernate        |         |      Hibernate    |
-------------------------         ---------------------
                        \        /
                            DB

For me, the grand purpose of having a layered / tiered architecture is code
maintainability. A good architecture means less redundancy, more cleanly
defined classes, etc. This would be accomplished even without the web
server exposing the business methods to a remote native client.
The only issue I can see is that there may be caching issues with
hibernate. Nevertheless, even if we turn off caching, the speedup from
not having to remote our objects would most likely be well worth it. There are other benefits too: not remoting means no more DTO's (can just use Hibernate lazy-loaded objects and have a much more fine-grained API), and I wouldn't need to worry about securing my remotely accessible API.
What do you all think?

[adepue]

Just a few thoughts off the top of my head: I could see how in some projects this would be a good approach (KISS). But there are a few things that could torpedo it. In our case we have a spring-rich client delivered to remote computers across the internet via webstart. Of course the DB lives on our side of the internet fence, behind a nice firewall (as is the web server). For security reasons, and also because of our business model, we really want the business logic to reside on the server side as much as possible - so we've created a service oriented architecture. Due to firewalls and such, the only method of communication we can rely upon is that the client can connect to our server on port 80 using the HTTP protocol. Thus, all of our communication must be squeezed through this arrangement. One of the advantages of going with a rich client is UI responsiveness and interactivity... of course, if all your business logic is on the server and you use some sort of HTTP based remoting then your UI will become no faster than a web based interface for some tasks - so we've implemented an asynchronous messaging system to keep the UI responsive (based on ActiveMQ). For us, this ends up resembling:

+-------------+                             +------------------------+
| Spring      |                             | Tomcat                 |
| rich client | <--- ActiveMQ via HTTP ---> | Embedded ActiveMQ      |
+-------------+                             | +--------------------+ |
                                            | | Spring AppContext  | |
                                            | | +----------------+ | |
                                            | | | JMS &#40;ActiveMQ&#41; | | |
                                            | | | listener       | | |
                                            | | +----------------+ | |
                                            | |    |               | |
                                            | |    v               | |
                                            | | +-------------+    | |
                                            | | | JMS invoker |    | |
                                            | | +-------------+    | |
                                            | |    |               | |
                                            | |    v               | |
                                            | | +------------+     | |
                                            | | | service    |     | |
                                            | | | interfaces |     | |
                                            | | +------------+     | |
                                            | +--------------------+ |
                                            |                        |
                                            +------------------------+

There's actually a lot more to it than that, but you get the idea. The app can invoke methods (either synchronously or asynch) via this arrangement, but can also utilize a distributed event system (based on the Swing model of POJO events). Simply define your standard event listener interface and fire the event like you normally would in a swing component. A client POJO fires the event and a server POJO receives the event (it can go the other way as well). A special service handles adding the proxy listener to your POJO or adding your POJO as a listener to a distributed event. This special service is where all the hard work of distributed messaging happens, and is where you would specify all the various parameters that can be involved with messaging.

- Andy

[Maarten]

I certainly agree that you shouldn't do remoting when you don't have to. (I'm facing a similar situation)
If your "native app" runs within your private network, I think that's a good solution.

and I wouldn't need to worry about securing my remotely accessible API

But now your database has to be remotely accesible !
That might be an even bigger risk, since anyone can bypass your business logic and go directly to your db.

Just some thoughts.
Maarten

[general_pattonm]

I should have clarified that the setup is intended to run on a local network, so the native clients would have the same speed of access to the DB as the web server would.

Thanks, Adepue, for sharing about your asynchronous setup...it looks sweet.

[Ben Alex]

But what I am wondering is: why do I even need to continue to access my business logic remotely from my remote native client? What is it about the GUI talking through the web tier that is so essential?

Generally most new apps are 3-tier (at a deployment level) in that they separate client from application server from database server. Some reasons this model is popular, as touched on by other people, include:

- Deployment. You need to consider actual Java classes, XML file revisions, JVM versions and JAR versions (including the JDBC driver). With 3-tier, there is only one place where all the important configuration needs controlling. With 2-tier, there are more places to manage these various items. This is one reason webapps are so popular, as they avoid the rich client deployment issue.

- Security. In a 3-tier architecture, only one port needs to be open, being for your application server remoting protocol. There are attractive ways of addressing security customisation within your application server (ie Acegi Security). It's more time consuming implementing custom security in your database server (I'm talking here about something beyond table level security, such as where security rules apply to prevent certain business operations from being performed - in a database server you'll have difficulty enforcing that without a stored procedure and security on it).

- JDBC username/password details. Where will you put the JDBC connection properties? Usually there's a single application-specific login name and password. In a 3-tier model those details are safely stored on the application server, which is under the control of the IT Department. In a 2-tier model you put them on the client. In a 2-tier model it's common to avoid this problem by giving each application user their own database login. So you have more DBA work if you go a 2-tier path and care about this issue.

- Caching. If you have a 3-tier model, you hopefully have a single powerful application server accessing the database. In this case you have simpler caching options (eg Hibernate second level cache). If you have a 2-tier model, you effectivelly get dozens of clients accessing the database and caching at anything aside from the database level becomes very difficult if not impossible (depends on your number of clients, whether you can use multicasts to advise cache evictions etc).

- Business model support. As Andy mentioned, some of us write apps we sell on a subscription basis. In this case it's desirable to ship as little code as possible in the rich client, to save download time, discourage reverse engineering, and prevent subscribers from modifying the database connection and cutting our app server (where we enforce licensing) out of the loop.

- Location of clients. One day you might need to repackage your application for use by business partners or customers across the Internet. Or even allowing employees to access the application from home or when on the road. In a 3-tier model it's a minor step. In a 2-tier model you'll be faced with using a VPN or similar to enable the database to be Internet accessible (or of course refactoring to use a 3-tier model). I have never met an IT manager happy with making a database available over the Internet like this, so it's probably a refactoring project.

- Distributed transactions. You simply need application server capabilities in this case, and standard clients aren't suitable.

- Database connection pooling. How many clients you will have? Your database server might not be able to support large numbers of clients accessing it, as there is no connection pooling as you would typically implement in a 3-tier model.

- Difficulty. The main reason one would not do a 3-tier architecture is to save time and complexity in implementing a remoting protocol. Some remoting protocols are a lot more painful than others, but HttpInvoker for instance is simple, reliable and supported.

- Future needs. If you go a 3-tier path, you know you'll be able to accommodate anything new in the future, such as more flexible caching or distributed transactions or more complex security or a massive increase in the number of clients or making your Rich Client available over the Internet. If you go a 2-tier path, you might be up for some serious refactoring if your baseline shifts too much.

I'm not against 2-tier architectures. I'm sure they're fine for simple prototypes or applications with only a few users and a very clear future. But anything else should probably be implemented using 3-tier.

[general_pattonm]

Ben,
Thanks for your post with many solid reasons for the 3-tier protocol. At this point, I am well convinced that it is the way we need to go for our rich client.

[afida]

Andy you design sound very attractive, do ypu think you can describe it little more. Mainly I am intereseted in your Rich client messaging interface. Also if you can breifly explain the need for async method processing for your client requests. And how do you update the client upon method completion in this async mode?

Thanks

Amad