[OT] Want help understanding missing piece in architecture

["Berneburg, Cris J. - US" <cb...@caci.com>]

Hi Folks

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?

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.

Thanks for your time and patience.  :-)

--
Cris Berneburg
CACI Lead Software Engineer

RE: [OT] Want help understanding missing piece in architecture

["Berneburg, Cris J. - US" <cb...@caci.com>]

Thanks Chris for taking the time to provide such a detailed and educational answer.

cjb> Now let's say that we want the Tomcat application to only do 
cjb> rendering.  It connects to a different server, X, and no longer to the 
cjb> DB.  The X server connects to the DB.  Requests and data flow between 
cjb> the Tomcat app and the X server.
cjb> 
cjb> What is X?  Is it a web service?  Application behind a web socket? 
cjb> What platforms support those?  Is that what the whole SOAP, xml, and 
cjb> JSON stuff is for?

cs> client -> presentation -> business -> db

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

Good to know.  Thanks for the primer.  :-)
- REST is a standard.
- JSON and XML are formats.
- SOAP implements an XML protocol.
- You can implement a monolithic URL or multiple URLs that represent different verbs.

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

That makes sense.  Websocket for push/pull and persistent connections.  Depends on the need.

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

cs> There are LOTS of reasons you might want to do this kind of thing.
cs> Scaling is usually *not* one of them, because in a typical
cs> web/app/db server setup, you can horizontally scale-out the web
cs> servers or the app servers pretty much indefinitely [...]

OK, scaling is accomplished by other means.

cs> IMO the real benefit of that kind of architecture is *flexibility*.

Ah, that's my "HTML vs Something Else" scenario, but it could also be different client types, too, not just the language.

It also sounds like moving in that direction would require a compelling need, and not simply for the fun of it, or because the peas will no longer touch the mashed potatoes on my plate.

I recently encountered a project that uses the "Jersey RESTful Web Services framework", but I don't yet understand how the framework actually works or how to use it.

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

To sum up loading the DB with more roles:
1. Vendor lock-in.
2. SQL sucks as a programming language.
3. Messy: tightly coupled business and DB logics.
4. Doesn't scale well.

Yeah, my technical term for that is "icky".  :-)  I think we still have stored procedures that generate HTML.  *shiver*

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

Yup, thanks Chris!

--
Cris Berneburg
CACI Lead Software Engineer

Re: [OT] Want help understanding missing piece in architecture

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Cris,

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
flexible.

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

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqZhvsACgkQHPApP6U8
pFg+Kw//Wv402FMenTlne+SYvnudQmQ0nBKgc4cWMJzn3KSSzxoX3D4chZAwqc4r
zedG/j9NWsFgaCOntJ4nMN+qdRoh9WZsuaUQOFOh/02qhc0Bl0bQsVhUQZn4xqX4
g4kd1xoUYRb2/xru4niQ2rJCVGuxLAxeLkJDZdRwoDBuU09+nVOjKvCeT2x1oko4
cQzuJppV5cC6bu834jxgpEL8iymAGt3OtEehGf416l7O1TKlC81YCjfG13DPoC3s
qj2Ku9+odE3Pl4qmI1bssmWQvjqIu0FWHeCc+Xtxi36IjaiAazmcDVdJfhMTIxjZ
5FTAY0Vsh353mX1/L0HhTJE3z590/rlJmv6jfWn3ZpQ2/J8oPQ3zE8FEXiipyLwr
3SS99PTTVIAmh/8VZtWC1IwHjnVU7nz4OnmY9dWSPRXgD0OtPx1wCE2Vwp9G0JT1
m2dF82ZFcL2q+IF1a6U6wulQKlUouh1wIelyKSpAX9QM1DHy/j4Ve4D9wrlUwAYW
sljXAD2Z+XD2EwGpaMB+8gwtGhAdCjQKyQzUzKjkNAXiWEEs/Yhj1voEfUK0Ne9A
zqIeRUO46BGrf3iRT5MdGcAUKBys6CjbmE9dOtTsk0gVI/R7U6gN1SsHGsEOz2Lr
s4EPKgLUswjubX95HypR7mJm1fynzOFhJaDEGd78jeZvyof/7QQ=
=WzvU
-----END PGP SIGNATURE-----

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