-----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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org