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
