Talk:Three-tier (computing)
Discussion of Web development versus traditional meanings
[edit]I'm pretty sure the traditional and web development meanings of 3-tier are closely related - did they diverge at any certain point? From memory, most introductory web development books (eg. Beginning PHP4, The Cold Fusion 4 Web Application Construction Kit, etc.) around 2000 went over the 3-tier architecture in the introduction or first chapter.
Does the Theory Work?
[edit]In a three-tier model, how easily can a web application can be converted to different types of applications?
For example:
Using Jakarta Tomcat <-> Jave 2 Enterprise Edition <-> Mysql
then change it to Apache 2 Web Server <-> PHP <-> Postgre
What type of web application would it be? Well, let's say it is a movie rental web application.
~AT3
- Changing the business logic is a pain in the .... Changing PHP for Java Servlets & JSP is very difficult, as the programming is quite diferent. Also, as far as I understand PHP combines both presentation and logic on the same page, whereas a Level 2 JSP implementation implements business logic on servlets and presentation on JSP.
- Now regarding the first architecture, it is actually Apache Web Server -> Jakarta Tomcat (Java 2 Enterprise Edition) -> MySQL. The second one is ok. For either of the two, changing for example Apache Web server with MS IIS 4.0 is doable. I have installed IIS with Jakarta. It is also fairly straightfoward to change the database AS LONG AS you use standard ANSI SQL queries.
- So basically the theory holds... as long as you don't change the most important part, the business logic. --Threner 03:29, 29 October 2005 (UTC)
- If you don't the hardest layer to change is generally the business logic, since it can be anything from PHP, ASP, ASP.NET, a Server, JSP, Beans, Cold Fusion, or any number of other custom pieces and will require extensive re-write. If you do the presentation layer correctly that should be easy, and database migraions are not too much of a problem.
- Also be warned that my 3-tier system put much of the business logic in the data tier as stored procs. Fun fun fun. Rhooker1236 11:55, 1 September 2006 (UTC)
Cleanup and merging
[edit]For more information on this (and my crazy plans/screw ups) see Talk:Multitier architecture#Cleanup and merging. -- Foofy 07:13, 19 October 2005 (UTC)
3-Tier is important enough that it deserves its own Wikipedia entry.
Re-merged
[edit]I just redid the merge going back the other way, to Three-tier (computing) as the parent, per the apparent consensus in discussion but contrary to the tag direction which I don't think anyone noticed... Georgewilliamherbert 04:39, 26 May 2006 (UTC)
Comment
[edit]I think the merge was needed and was very nice.
Comment
[edit]I think Multi-tier should not be merged with 3-tier because multitier can be 3 or four or more tier based upon the user or client requirements.
Comment
[edit]I have a number of observations about the content. I think the MVC comparison material may not be correct. It is architecturally permissible for a front-tier entity (view) to directly use a service of a back-tier entity (model), esp for read-only browsing of data and administrative repair of damaged data. I think the 3-tier architecture originates from PARC in 1979 with the MVC design pattern. Although this was initially only a Smalltalk programming pattern, it established a universal concept that all computing functionality breaks down into three fundamental sets of concerns, which should be separated. Everyone at the time was looking at Smalltalk for new concepts, and I think people working in distribution of computing eventually made the obvious application of MVC to their work, although they may not have given credit. The earliest extensive documentation of a fully developed 3-tier distributed software architecture is the OSCA(TM) and INA literature from Bellcore in the early 1990's. The primary thinker behind these projects was John Mills. OSCA described 3-tier distribution of computing. INA added the concept of building blocks (software modules) with contracts (well-formed interfaces) that expose either a service (service contract) or the ability to configure and monitor a service (management contract), and it borrowed the ANSA concept of a middleware "trading service," an automated advertisement and discovery service for contracts that enabled dynamic formation and reformation of distributed systems. The INA concepts are now known generally as Service-Oriented Architecture, which is a natural enabler of 3-tier distributed software. Whereas the Bellcore projects produced around 2,500 pages of somewhat unaccessable distributed computing literature, the content was distilled into a 180 page requirements document by the TeleManagement Forum in 2001. [I have lots of references and other items, but have never really participated in a wikipedia page before. Someone pls tell me what to do! kirk@shrewsbury.com] Does anyone know what became of Microsoft DNA? —The preceding unsigned comment was added by Jkshrews (talk • contribs) 15:35, 13 December 2006 (UTC). Kirk Shrewsbury 12:50, 24 December 2006 (UTC)
Comment
[edit]Multi-tier and three-tier should be combinded. As a student, I have had study questions that make reference to two-tier, three-tier, and n-tier at the same time. Putting it all in one spot makes sense. It is all in one spot in most textbooks, also. Add ing a redirect reference to Multi-tier using the keyword n-tier is helpful, but it needs to be a little clearer that they are the same for CS newbies. Thanks.—The preceding unsigned comment was added by 68.62.46.47 (talk) 19:07, 30 January 2007 (UTC).
Comment
[edit]I glanced at the old discussion on n-tier/3-tier merge. (I saw the nice reference to a page about MS DNA. Thanks for that, whoever listed it.) Below are my comments on some of the discussion items I noticed.
Terminology: "Layer" vs. "Tier": At the TeleManagement Forum (TMF) Application Component Team (ACT) activity, we decided to make an arbitrary distinction between these two terms. We decided to reserve the term "layer" to describe the elements of an architecture in which the nature of the separation of concerns required the various elements to interact with one another only in a deterministically sequential manner.
An example is the 7-Layer OSI Reference Model. The Physical Layer always communicates with the Data Link Layer which always communcates with the Network Layer which always communicates with the Transport Layer, etc. There is no path by which information skips around any layer. The various concerns are stacked like pancakes, each pancake touching only the one beneath it and the one above it.
We decided to reserve the term "tier" to describe the elements of an architecture in which the nature of the separation of concerns allows some of the elements to interact with any of the other elements as required. This makes a mesh or a graph of interactions as opposed to a sequence. This interaction pattern is more like spaghetti, meatballs, and sauce, where the pasta, the meat, and the gravy all touch one another. MVC falls into this category, as any of the three elements is permitted to interact with either of the other two.
I am normally opposed to arbitrary terminological distinctions and definitions that result in bizarre local dialects of IT lingo in different organizations. But this was a case where a major, overarching architecture issue was at play, and I believe it was beneficial and very helpful to create some arbitrary terminology. Therefore, I use the term "tier" when discussing MVC, and I use the term "layer" only about matters where strictly sequential interaction takes place.
SubTiers: n-tier vs. 3-tier: In my experience, I have seen various architectures defined with more than three tiers. It was always easy to perceive that one of the three MVC tiers had been subdivided, and the multiple subdivisions had then been promoted to the top level (or first order) of importance.
MVC View: Herzum & Sims, The Businsess Component Factory, divides the MVC View Tier into a User Tier and a Workspace Tier to produce a 4-tier architecture. Also, it is easy to see the currently accepted web interface technology as having two MVC View sub-tiers, resulting in a supposedly 4-tier arrangement. One sub-tier is that in which the information is formatted abstractly (mark-up language) and transmitted and the second sub-tier is that in which the information is rendered into a viewable image (the browser). This could be conceived as a 4-tier architecture, but in fact it is the normal 3-tier architecture with sub-tiers in the View.
MVC Model: (1) I have seen a company proprietary 4-tier architecture resulting from dividing the MVC Model Tier into two sub-tiers, one a tier of legacy systems and the second a Mediation Tier responsible for normalizing their various data schemas. Although they labeled this a 4-tier architecture, I regarded it as a subdivided 3-tier architecture. (2) In the implementation of a real computer system, the MVC Model tier is typically implemented with several sub-tiers based on a speed/cost trade-off. Cache memory (internal semiconductor), primary memory (RAM--external semiconductor), secondary memory (disk), and offline storage (tape), form architectural sub-tiers of the MVC Model Tier. This could be regarded as n-tier architecture, but it is really practical subdivisions of the MVC Model Tier.
MVC Controller: Traditional n-tier theory is concerned with the fact that services inside the MVC Controller Tier may operate in concert, with secondary and tertiary service invocations needed to fulfill an original request. This creates the appearance of sub-tiers.
Nested MVC: It is also clear that MVCs may be nested. Each of the tiers will be implemented with computers, each of which will contain an I/O channel (MVC View), a processing unit (MVC Control), and storage control (MVC Model--note: this is sometimes mixed in with the I/O channel). The processing unit, in turn, will most often be implemented with an internal microcontroller, executing microinstructions fetched from an internal read-only microinstruction store, creating yet one more level of nested MVC.
The Answer: I believe the answer to n-tier theory is merely to state that any of the three MVC tiers may be subdivided into sub-tiers in order to further understand and implement its functionality. And what is more, each MVC tier may contain nested MVC patterns to any degree that is useful.
I believe there is probably something natural about the MVC pattern and its applicabilty to separating the concerns of all real problems. That is why we can't get away from it. It appears on the grandest scale of enterprise client-server computing as 3-tier distributed software architecture, and it appears on the smallest scale of micro-engines deep within computing engines. I am expecting that when the wiring of human and animal brains is finally unstrung and put onto schematic diagrams, the MVC pattern will be seen to occur over and over again, the processes of organic evolution having converged quite naturally on the most efficient solution of a computing problem.