Hash: SHA256


On 3/2/18 11:46 AM, Berneburg, Cris J. - US wrote:
> There's a concept I'm trying to wrap my brain around.  It's
> similar to MVC, separating responsibilities between the display
> and model/controller layers.  In terms of coding, I know how to
> make that happen.  However, in terms of server architecture, I do
> not.
> For the purposes of semantics, please assume "server" refers to 
> either a physical box and/or software service, application, 
> container, etc.
> Let's say we have a database server and Tomcat application server. 
> The web application uses JSP.  The app is configured to connect to 
> the DB.  With this configuration, all the communication with the
> DB and page rendering occurs within the Tomcat application.
> Now let's say that we want the Tomcat application to only do 
> rendering.  It connects to a different server, X, and no longer to 
> the DB.  The X server connects to the DB.  Requests and data flow 
> between the Tomcat app and the X server.
> What is X?  Is it a web service?  Application behind a web socket? 
> What platforms support those?  Is that what the whole SOAP, xml,
> and JSON stuff is for?

Obviously, this gets into what the "appropriate" architecture is for
an application, etc. so the best anyone can do is give you *examples*
of what might be reasonable.

If you want something like this:

client -> presentation -> business -> db

Where "presentation" is "only" your JSPs and the "business" is the "X"
component you have described above, then there are many ways to
accomplish your objective.

The communication protocol is up to you, and will be affected by how
to decide to design X. If you use HTTP - a reasonable choice - then
you also need to decide what bits you'll send across that protocol.
Obvious choices are JSON or XML. SOAP is just a particular
implementation of XML-based RPC. Rest is a loose standard for using
HTTP verbs that make sense instead of having one big "do-everything"
URL where you feed-in requests via e.g. XML or JSON documents in a POST.

You could also use Websocket, but that would depend upon what the
relationship between your client (presentation) and server
(X/business) has to be. If it's request/response-oriented, then
Websocket is probably more trouble than it is worth. If maintaining a
connection over a long period of time, and either the client or server
should be able to "speak" at any time, then Websocket is probably the
right solution in that case.

Regardless of the exact implementation, I think it would reasonably be
called a "web service". Some people think that "web service means
SOAP" or "web service means ___" but I would say it's a fairly loose
term. I'd call anything that provides an HTTP/Websocket interface but
is intended to be used by *software* and not humans/web browsers
directly should be called a web service. If humans are using it, it's
called a "web site" or a "web application" IMHO.

> And why do it?  Are there any benefits to such an architecture? 
> Scaling maybe?  Support for rendering different output types (HTML
> vs Something Else)?  Theoretically I'm thinking that maybe the
> different servers could live inside different security zones, but I
> don't know if that's a valid requirement.

There are LOTS of reasons you might want to do this kind of thing.
Scaling is usually *not* one of them, because in a typical web/app/db
server setup, you can horizontally scale-out the web servers or the
app servers pretty much indefinitely, as long as the downstream
service(s) can handle the load. If you have your database running on
Chuck's iPhone, having 500 application servers isn't going to improve
the speed of your web application if it's db-heavy.

IMO the real benefit of that kind of architecture is *flexibility*.
Let's say that you have a series of low-level services all wrapped-up
inside of X. Then you have a web-layer (presentation) that talks to X
which does all the "real work". If you were just building the web
application and nothing else, it might be a waste of time to split
presentation/business into separate services/projects/whatever.

But let's say that you want to build a mobile application that isn't
just an app-wrapper around your web site? Your mobile app can then
call X directly and ignore the web/presentation parts of your "web
application". Then you can create another mobile application on
another platform, too, and re-use the same service.

You now want a desktop application to go along with those mobile apps?
No problem, call X directly. And the web version continues to provide
your web-based clients the same service they have always enjoyed.

I have seen LOTS of deployments like this, and many of them end up
using the database itself as the "X" in your setup: they write most of
their application using stored-procedures in the database, then
everyone uses JDBC (or whatever) to call the database to ask for
things to be done.

You want a new user? Great: call the createNewUser(args) stored
procedure, and it will validate everything for you, return any errors,
or create that user for you. Call it directly from the web framework.
Call it from a command-line client. Proxy it through a paper-thin
web-service for your mobile clients.

The advantage of putting everything in the database is that "everyone
can access it" and it's a pre-existing, centralized place where
arbitrary code can be dumped. It's also quite flexible, because it has
immediate access to 100% (well, often, at least) of the
relational-stored data for the application, plus it's got whatever
goodies you have installed on that server (or servers) at its
disposal. I've even seen stored procedures call-out to ImageMagic to
re-size images for clients. Just call "resizeMyImageForMe(inout
bytes)" and the "database" will resize images for you.

I have an architectural objection to putting that kind of stuff in the
database, specifically. First, it ties you (even further) to your own
RDBMS vendor. Second, SQL (whatever flavor your vendor provides) isn't
exactly a great programming language. It's not very expressive, it's
hard to debug, and it doesn't lent itself to many programming
paradigms such as OO, etc. Third, it binds your business logic to the
database itself and is therefore very difficult to de-couple for e.g.
scalability. If you decided that you wanted to separate your "business
logic" from the "database logic", then what do you do? Set up a
proxy-database-server where the "outer" database server does all the
business logic and then makes remote-ODBC calls to the "inner"
database server where the data is actually warehoused? Yeah, that
makes no sense.

For my money, I'd always build a separate, self-contained service for
my business layer. That's your X above. It can exist in many different
forms, but they all work roughly the same way, and they are all quite

Just one perspective (from a developer). I hope that helps a little.

- -chris
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to