tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berneburg, Cris J. - US" <>
Subject RE: [OT] Want help understanding missing piece in architecture
Date Mon, 05 Mar 2018 19:53:19 GMT
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> 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

View raw message