A 3-Tier Architecture (3TA) is traditionally used when building web applications. It makes a logical separation between the presentation layer, the business logic layer, and the database layer. For instance, on the Java platform, the presentation layer could be implemented with JSP and JSF, the business layer with session EJB, and the data layer with entity EJB or Hibernate. It is important here to note that the 3TA introduces only a logical separation between layers. The 3 layers together make a given application, which gets deployed on a given server or cluster, and built by a given team. The 3TA can be seen as an implementation of the divide and conquer strategy for the use of the application architect, as it lets him think of his application in term of layers.
Most companies have been implementing applications following the 3TA for years and have now a collection of applications that all behave and look differently, and are hard to integrate. The 3TA introduces a welcome division between the presentation, business logic, and data layer, but is damageable in the sense that it leads architects to think in term of application silos.
The Service Oriented Architecture (SOA) builds on top of the 3TA and addresses its shortcomings. Instead of looking at the IT infrastructure as set of application silos, SOA looks at a set of services and applications. Services implement some kind of functionality and are used by applications and other services. Services communicate between each other and with applications by exchanging XML documents. Comparing SOA to 3TA, SOA applications correspond to the 3TA presentation layer, while SOA services correspond to the 3TA business logic and data layers.
Service Oriented Architecture
With SOA, all the complexity of the system is encapsulated in coarse grained services and applications are kept extremely simple. In fact, the only concern of applications is to display XML data they get from services and to send XML data to services based on user input.
SOA does not compete with 3TA, but introduces three additional requirements:
- Completely separating the presentation layer from the other layers.
- Breaking down the other layers by coarse grained functionality to make services.
- Having the services communicate with each other and with applications by exchanging XML documents (typically using web services).
What are the advantages of having services "communicate with each other and with applications by exchanging XML documents" rather than, say, by exchanging data structures? XML needs to be parsed; this makes it inefficient?ReplyDelete
We could argue about the technical benefits of using XML versus other formats for exchanging data between different systems. There certainly are other formats that are more compact than XML (the "more efficient" argument), or that existed before (the "why reinvent the wheel?" argument).ReplyDelete
Those are all valid arguments. IMHO, the main benefit of using XML to exchange data between systems is that XML is a widely adopted standard. Both the Java and Microsoft camps have adopted XML and are pushing XML and web services. This means that already today, a lot of data in the enterprise is available as XML, and services can be accessed by exchanging XML documents (sometimes through web services).
Compare XML for data exchange to the English language for writing scientific papers. Is English the best language out there to write scientific papers? Maybe a linguist would argue that Esperanto is better. But the main benefit of English as a language to write papers is the same as XML as a data exchange format: everyone is using it.
I never liked JSP, or any of the plethora of mark-up language add-ons because the break the whole concept of the three tier model. (At the same time, I hope to write a proposal about using xslt within xhtml to do the same thing -- have one file specify the presentation and the services it connects to.) It is not just a matter of everyone "speaking XML" but the reason they are is that XML is good at describing real world data. XML is the Espreranto of data, I think and it has the adoption rate of English.ReplyDelete
Hank, you make a good point: using XML to describe data definitely has a number of advantages, and drilling down on the down on those benefits would be a good subject for a future entry on this web log. It looks to me like the two main advantages of using XML at the presentation layer is that:ReplyDelete
1) Backend systems with which the presentation layer interacts are increasingly using XML as a way to exchange data. So it makes sense to use XML technologies to deal with this data, for instance XSLT to present XML data that comes from backend systems and XForms to capture data from the user through forms and produce an XML document to send to backend systems.
2) XML is well suited as a description language (as opposed to a programming language), and the things that need to be done a the presentation layer are inherently descriptive, for instance: navigation between pages (PCF), page template (XSLT), data validation (W3C Schema, Relax NG), form definition (XForms).
A quick comment regarding the first poster who is opposing "XML documents and "data structures". Well, an XML document is a data structure if there ever was any! Do you mean, rather than "data structure", something like Java objects?ReplyDelete
In any case, the "performance" argument can always be put forth. When people started using Java, they said it did not perform. Nowadays, such an argument has become mostly irrelevant, because of the benefits the Java environment has brought. The same can be said of XML: it provides benefits for a certain category of applications, and it is your call to decide whether those benefits outweigh a potential performance impact.
To clarify: yes I meant something like Java objects. Mostly I am playing devil's advocate here. I prefer the simplicity and clarity of a REST approach that returns XML documents. However, I find myself having to defend this style against the use of SOAP and especially XML-RPC. The latter returns a "native" data structure (Java, Perl, etc.) to the calling program, which, I am frequently told, is a more "efficient" approach, as there is no need for the program to parse XML. I am just trying to better understand the advantages (and disadvantages) of an XML-centric service oriented architecture.ReplyDelete
I am doing some research on xml and need to know the following.
how to identify a company is using three tier architecture.
how to identify a company is using three tier architecture with or without xml?
benefits of using the XML platform to implement Three-Tier Architecture?
Any suggestions please?.
I am not sure if this is really what you are asking, but just looking at their web site you can't. You would need to get some internal knowledge about how their system works. I hope this helps,
ok so assume (what internal knowledge will i need? and how can i decide on the basis of that internal knowledge?
if they were not using three tier architecture how could three tier architecture be implemented? (This has to be with reference to an online shopping company.) i hope you can help with some more information.
Well, the best is to ask them. You can't know much about one's architecture "from the outside".
and what are the steps to implement a three tier architecture?