Information Sciences 150 (2003) 195–206 www.elsevier.com/locate/ins
A data-centric design for n-tier architecture Paul D. Manuel *, Jarallah AlGhamdi College of Computer Sciences and Engineering, King Fahd University of Petroleum and Minerals, Dhahran 31261, Saudi Arabia Received 30 December 2001; received in revised form 17 March 2002; accepted 4 July 2002
Abstract The increasing heterogeneity, complexity, and distributed nature of deployment architectures only serve to compound the problems faced by software solutions. With the advent of the Internet and web technologies, system designers have had to reevaluate the applicability of n-tier architectures, and assess which technologies are appropriate at each tier. In this paper we evaluate the design issues of n-tier architecture. We debate whether it is good to move code or data to communicate messages between applications. Based on the latest technology of J2EE and .NET framework, we recommend a data centric design of n-tier architecture. Based on our experience we also suggest a modified interactive software process model. Ó 2002 Elsevier Science Inc. All rights reserved. Keywords: eCommerce; n-tier architecture; J2EE; .NET framework; IDL; XML; IIOP; SOAP; Software design; Software process model
1. Introduction eCommerce is an application of business communication and transactions over networks and through computers [2,5]. As most restrictively defined, electronic commerce is the buying and selling of goods and services, and the transfer of funds, through digital communications. However it also includes all
*
Corresponding author. E-mail address:
[email protected] (P.D. Manuel).
0020-0255/02/$ - see front matter Ó 2002 Elsevier Science Inc. All rights reserved. PII: S 0 0 2 0 - 0 2 5 5 ( 0 2 ) 0 0 3 7 7 - 8
196
P.D. Manuel, J. AlGhamdi / Information Sciences 150 (2003) 195–206
inter- and intra-company functions (such as marketing, finance, manufacturing, selling, and negotiation) that enable commerce and use electronic mail, electronic data interchange (EDI), file transfer, fax, video conferencing, workflow, or interaction with a remote computer. Electronic commerce also includes buying and selling over the World-Wide Web and the Internet, electronic funds transfer, smart cards, digital cash and all other ways of doing business over digital networks. The technology behind eCommerce is called ntier technology since the application, has many levels of communication. An example is a system, which has a presentation tier, a process tier, a persistence tier as well as communication with outside third party vendors. A typical n-tier architecture model is shown in Fig. 1. In this model, sometimes also known as the three-tier model, clients remain focused on presenting information and receiving input from users. This is known as the presentation tier. Data, meanwhile, is hosted on one or more data servers in the data tier. Only that processing required to access data and maintain its integrity gets implemented on this tier. This includes SQL query engines and transaction managers for commercial software, as well as triggers and stored procedures written by database administrators. Unlike the client– server model, however, these triggers and procedures are limited in scope to managing the integrity of the data residing on this tier. Business rules are moved to the application logic tier sometimes referred to as the business services or middle tier. The components of business rules are usually in the middle tier. Recently there have been a number of important advances in computerbased technologies that have made the software industry rethink how software
Fig. 1. n-Tier architecture.
P.D. Manuel, J. AlGhamdi / Information Sciences 150 (2003) 195–206
197
is developed, and offer new opportunities with respect to computer-based support for reuse of software artifacts. This has led to many new tools, processes, techniques, and technologies to support this new way of thinking and working. In this paper we analyze the design issues and software process model of ntier architecture based on J2EE and .NET frameworks.
2. Features of n-tier architecture An integrated information system using a distributed environment needs the following features (www.n-tier.com): Autonomous: A server is expected to be autonomous enough to protect its own critical resources and to take its own decision at critical moments. Usability: The architecture should assist users in performing their jobs efficiently and effectively. Adaptability: The architecture should have the ability to easily and cheaply redesign existing functions for new technology, should provide access to existing legacy information, and provide a variable transition period from the old technology to the new. Distributability: The clients and components of the architecture should be able to efficiently execute across multiple hardware platforms of a network. Inter-operability: The applications within the architecture should be able to work together in a consistent manner to perform tasks for the users of an information system. Standardization: Components of the architecture should be based on software standards that are widely available or defined by an international standards organization. Extensibility: The architecture should be easy to adapt to meet new and ever-changing requirements. Internationalizability: The architecture should be able to display information in the languages and formats appropriate for all the countries and cultures in which the applications are used. Manageability: The system managers should be able to economically configure, monitor, diagnose, maintain, and control the resources of the computing environment. Portability: The software should be relatively easy to be moved from one platform to another. Scalability: The architecture should be able to efficiently handle any size applications and grow with the business needs. Security: The architecture should protect information and computer resources from unauthorized use. The security component should have the ability
198
P.D. Manuel, J. AlGhamdi / Information Sciences 150 (2003) 195–206
to provide network-wide authentication. Addition, this component should provide centralized authorization capabilities. Reusability: The reuse of existing software components is key to effective use of valuable software engineering talent and the aggressive schedules imposed by audience expectations. Reliability: The components of the architecture should be able to be depended on for mission-critical business operations. Quality design of object classes and frameworks with an eye to maximizing reuse can also increase the reliability of the resulting software system. Much [2–4,14,15] have been studied and discussed about the above-mentioned features of n-tier applications. Now we discuss a few current issues of ntier industries that are still to be addressed.
3. The design issues of n-tier technology: moving code or data? The idea behind any n-tier architecture [1,4,14] is that a program can call another program, or an application can call another application. In short, there are various pieces that work together, but they are built by different groups. Client-server is a two-tier architecture. Even though the client is built by somebody and the database is built by somebody else, that works well because the database has a contract for saying how the client talks to the database––it is schema, ODBC and SQL. Here the client and the database server are tightly coupled. For example, let us consider an Application X (a hospital) that wants to go and order some medicine. Some other one has written an Application Y (a pharmacy) that actually takes an order for medicine and processes it. Both in turn talk to an Application Z (an insurance) that does bill paying and settlement (Fig. 2). In this network, there are a couple of processes going on that are not synchronous in real time. When a patient (X) orders a prescription, he does
Fig. 2. Three different environments.
P.D. Manuel, J. AlGhamdi / Information Sciences 150 (2003) 195–206
199
not want to actually have its bill debited until the prescription has been mailed out, and his insurance (Z) takes a day or two to settle the payment to Y. If it is a brokerage house, it can take even five days. To make them work, these applications are to be wired together in the form of n-tier way. Now how do they communicate each other? In the n-tier world, the original thinking was that we would have a world of distributed objects. The client would be interface definition language (IDLs) for describing the objects, and that would be the contract. The service contract may be an enquiry, quotation, purchase order, invoice between X and Y. In the same way, it may be credit, debit, and transfer of fund etc. between Y and Z. All the objects would talk to all the other objects by looking them up in an object request broker (ORB) or some sort of repository and then using the IDLs to figure out how to talk to them. It means that we are moving the code rather than the data. Let us now discuss the issues in moving the code instead of the data through various tiers. In the world of distributed objects, objects are supposed to have encapsulation and communicating with an object is nothing but invoking a method of the object. Suppose Y is looking up a hospital record of a patient and Y wants to get his first name, last name, social security number, date of birth, and so on. Suppose Y invokes a get method to get the first name, invokes a get method to get the last name, invokes a get method to get the social security number and so on. Then what will happen? Y will have three or four hundred method calls that will make against that object remotely from one application to the other. This turns out to be highly expensive, and it has been a real problem even within the organization. Running different applications built by different people that coordinate this way does not scale very well. In fact, the performance may not be impressive even when there are a very limited number of users in very high-speed networks under a known environment. But as soon as it is extended across big corporate networks, or across the Internet, that model completely breaks down. To be precise, what that means is that we have to move data––not code. A lot of people had the idea that it would be enough to move code around to cause these things to happen––like objects––we move instructions around the Web. Here is one more problem. What will happen when Application X is trying to move the object of purchase-order to Application Y and then execute it? Well, it may not be possible. Application X does not know Application Y, it does not know how to run the code of Application Y, it does not know what platform Y is, and the code of X is not running in the same context and the same framework. But at same time it is possible to move the purchase order as data, not as the object. It is a fundamental characteristic of a successful Web service that data is basically moved around, not code. The new thinking is to move around data instead of code through the n-tier networks. Regarding this, various experiments [1–4,6,8,14,15] have been
200
P.D. Manuel, J. AlGhamdi / Information Sciences 150 (2003) 195–206
carried out to study the recent design issues of n-tier technology. The recent technologies J2EE (www.sun.com) and .NET framework (www.microsoft.com) address these issues of n-tier architecture. The critical characteristics during the development of any n-tier architecture application are loosely coupled, coarse-grain communication, asynchronous and temporal.
3.1. Loosely coupled Let us discuss the first characteristic that is loosely coupled. The client– server world is tightly coupled. If the database is changed, the client code is typically broken. On the contrary in the n-tier world, what is expected is this. When the implementation of application X is being changed, the other applications Y and Z that are talking to it should not even notice and they should not break. This is what we call loosely coupled and this is just opposite to the client–server world. This loosely coupled model is an agreement on the wire format and the protocol, and not on the implementation. The implementation could be changed and the application knows exactly what wire format and protocol it needs to talk so it does not break all of its clients. To maintain the system loosely coupled, designers should not focus on where application components will execute (i.e., where they will be deployed) or what platforms they will execute on. More specifically, designers must avoid platform-specific or hard-coded interfaces to communicate to other applications. How do you do it? What is the answer? One answer to this may be Simple Object Access Protocol (SOAP) [10] and eXtensible Markup Language (XML) [6,8]. SOAP is a model for describing a standard for the protocol associated with all this. It is the wire format of the protocol, but it is also a description of the protocol. Moreover, it is an XML-based protocol that passes messages from one software component to another across the Internet, using HTTP, SMTP and other standard protocols [8]. XML forms a building block for having this loosely coupled communication where the XML schema and the XML document describes what the exchange of information is between the applications: here is the XML document to ask for a prescription, here is the XML document to ask for settlement, here is the XML document confirming shipment of the prescription, here is the XML document confirming settlement payment, and so on. This is one way to implement the concept of ‘‘loosely coupled’’ at the design level of n-tier architecture model. The main idea behind this is that we basically agree upon data format and protocol for how application X talks to application Y, without the knowledge of the implementation of application X or Y. This is what we mean by moving data not code.
P.D. Manuel, J. AlGhamdi / Information Sciences 150 (2003) 195–206
201
3.2. Coarse-grain communication The second issue is coarse-grain communication. Imagine if everyone goes into a supermarket, buys a stick of butter, goes home; comes back, buys a quart of milk, goes home; comes back, buys a loaf of bread, goes home; and so on. If everybody does that, it will be a disaster. The supermarket will have queues that go out the door because the cost of handling each individual transaction will be very high. That model completely breaks down. That is why we buy things in paper bagfuls. We make one visit to the supermarket and buy all we want in one shot. Naturally that makes the system more efficient. This is what we call coarse-grain communication. Let us say, application Y is looking up a hospital record of X and it wants to get first name, last name, social security number and date of birth of a patient. In stead of commuting between X and Y four times, what we need is a coarse-grain communication model where Y talks to X only once to get a single agreed-upon data message with the information it needs. One possible good design is sending this information as XML messages [5,7]. They are not huge but they are not teeny and actually have a reasonable amount of information, which is enough to get the job done. We call that coarse-grain communication. It is equally fundamental to any kind of Web services architecture or really any services architecture, because the amount of communication that has to go on between these things is not as great. Also the communications can be less reliable because we are not depending on many, many round trips. A single successful round trip will give us what we need to have. Here again we move data, not code.
3.3. Asynchronous The third key criterion to successful Web services is asynchronous. Let us say, X requests Y to ship a prescription. The shipment of medicine is not going to happen right away. But Y will send a mail saying that the request is being processed. We are human beings and we can read that mail and, so, everything is fine. But what will happen X, which is a program, and it is waiting to know if this happens, and it cannot read text. We have to have an agreed-upon way to get a message back to a known place saying, ‘‘yes, the medicine is shipped’’. This is what we call asynchronous. But as soon as you try and invoke a business process, that model of synchronous invocation is not sufficient. There are inherent delays and unpredictability. When X is communicating to Y, X is talking to a program that is developed and maintained by someone else, and X just does not know the availability of Y. X does not know how long it will take him to get the job done.
202
P.D. Manuel, J. AlGhamdi / Information Sciences 150 (2003) 195–206
Here is a problem: if Y does not respond to X within two minutes or two hours or two days, it is probably an error. To write error code, the developer X should know the latency period, that is, ‘‘What is the acceptable round-trip time before X gets the reply from Y?’’ and ‘‘What is the time gap between two steps?’’ Application X and Y need to have a contract or service condition to write error code. That is asynchronous. One of the design issues is here to find a way to have the contract or service condition between X and Y that does not tightly couple X and Y. 3.4. Temporal communication In the real world of Web services, the conversations between applications are very fluid. Let us say, X requests information on 10 different prescriptions by sending 10 messages to Y. Usually the order in which the reply from Y comes back is not really predictable. It is too complex. Y has to field them all and keep track of them all in a particular order X sends the request. There are a bunch of cases where the conversation involves an obvious sequence. It is not just a set of messages. The incoming responses may have to keep track of the sequence of the outgoing requests. This is what we call temporal communication. During the design phase, the designer cannot assume anything about the runtime environment of other applications. Otherwise it may lead to tightly coupledness. A successful Web services architecture is a conversational and asynchronous model. Normally in the n-tier world, the client code often will make different assumptions than the server has, and there is no way for the client code to know that it is breaking the rules. As it is, there is no automatic way to figure out the order in which one application exchanges messages with other application. This is also considered as an important design issue of n-tier. During the design, it should be written down clearly what the contract is with the service. It may be noted down that the contract is not just ‘‘here is the message Y can send X, here are the messages X can send Y back, and here is the amount of time that Y should respond to X within, and so on’’. It should also include the sequence of things that has to occur. If it is not spelled out in the design, it can be done in any order. The communications may be based on service contracts between the applications. The design should be in such a way that any new service contract may be incorporated during the maintenance phase by a very little customization.
4. A data-centric design Recently there have been a number of important advances in computer technologies to incorporate the design issues of n-tier application, which we
P.D. Manuel, J. AlGhamdi / Information Sciences 150 (2003) 195–206
203
have discussed above. Those advanced techniques are J2EE framework based on Internet Inter-ORB Protocol (IIOP) [9] and .NET framework based on SOAP [6,8].
When we develop an application on these frameworks and we move data between applications in the form of XML, we prefer the architectural design in the form concentric circles instead of vertical partitioning. This design sometimes is called data centric. After designing those building blocks we can wire everything up together in the following way. The application forms four concentric circles. In the innermost circle is data. The second layer is business logic with the off-the-shelf components in compliance with the business rules. The third layer is application logic cementing the components in compliance with service contracts and wiring protocols. The fourth is user interface. This concentric circular formation helps to move the data more efficiently and conveniently.
5. Software process For corporate projects, there are two kinds of options. The first is to purchase, install, and deploy packaged applications. Many organizations have recently spent a great deal of time and effort over the past few years to purchase, install, and deploy packaged applications. The most obvious examples of this are the range of enterprise resource planning (ERP) packages from SAP, Baan, Maximo, i2, PeopleSoft etc and the range of customer relationship maintenance (CRM) packages from Siebel, Clarify Vantive etc. The other option is the conventional process of developing the software using the off-theshelf components available in the developerÕs own library or from the third party vendors. For any B2B projects, BITECH software has ready-made modules such as sales, eProcurement, finance, CRM, management information
204
P.D. Manuel, J. AlGhamdi / Information Sciences 150 (2003) 195–206
system (MIS) etc; whereas sales has sub-modules such as transaction process, sales analysis, new enrolment etc; in turn transaction process has components such as quotation, purchase order, invoice, payment, acknowledgement etc. In fact, software engineers [13] still argue over the advantages and disadvantages of the two options. With advent of tools to generate presentation layers (interactive web pages etc.) and off-the-shelf components to implement business logic and application logic, we experience the following software process model a bit more advantageous for an n-tier project. The process is similar to Component-based development process mentioned in Pressman [12] with little changes. It is evolutionary in nature [11], demanding an iterative approach to the creation of software. Here the spiral model is divided into two regions, one for the client and the other for the developer. During our experience, we feel the customer region covers two-fifth of the spiral. The customer evaluation is on testing the features such as loosely coupled, asynchronous, coarse-grain communication, and
Fig. 3. The spiral model.
P.D. Manuel, J. AlGhamdi / Information Sciences 150 (2003) 195–206
205
temporal communication. The customer may not spend too much time on testing the functionalities of the business components at this stage. As the project begins, the development team moves around the spiral in a clockwise direction, beginning at the center. The first circuit around the spiral might be the feasibility study whether to go for customization of packaged solution or to go for in-house software development in a conventional way with the building blocks of in-house library/third party components. The second circuit is to identify business components, various service contracts, wiring protocols; the third circuit may be to develop a prototype to demonstrate the functionalities of business components and the communication with other applications. Then it progresses to more sophisticated versions of the software. The success of this model depends upon the involvement of the client in the project hand-in-hand with the developers. It is something like assembling a Harley Davidson bike or Rolls Royce car where you assemble the parts with the satisfaction of the client by keeping the user side by side. The advantage is that this model can be adapted to apply throughout the life of the application software. More over, the acceptance-testing phase starts right from the beginning (Fig. 3).
6. Conclusion When n-tier architecture is built based on J2EE or .NET framework, we recommend a data centric design to communicate messages by moving around data (not code) between applications. We encourage a software process of incremental spiral model that reduces the development time considerably. In addition we could realize the customer satisfaction in terms of quality.
References [1] A. Bosworth, Crossgain: bringing it all together, XML Magazine (February/March) (2001). Available from . [2] A. Brown, eCommerce components for the internet, The Business Forum Journal, 9297 Burton Way, Suite 1, Beverly Hills, California 90210, USA. Available from . [3] T. Chester, High-performance Web sites: ADO versus MSXML, Dr. DobbÕs Journal; San Mateo 26 (10) (2001) 81–87. [4] D. Cohen, Construct your e-commerce business tier the easy way with XML, ASP, and scripting, Microsoft Journal (February) (2000). Available from . [5] J. Fontana, Where Middleware and XML converge Web services, Network World, Framingham 18 (39) (2001) 54–57. [6] N. Gunton, SOAP: Simplifying distributed development, Dr. DobbÕs Journal, San Mateo 26 (9) (2001) 89–93.
206
P.D. Manuel, J. AlGhamdi / Information Sciences 150 (2003) 195–206
[7] J. Herman, XML Internet takes off––part 2, Business Communications Review, Hinsdale 31 (6) (2001) 22–26. [8] S. Lais, SOAP, other protocols specify security for XML, Computer world, Framingham 35 (28) (2001) 37–40. [9] R. Mateosian, J2EE technology in practice, IEEE Micro, Los Alamitos 21 (4) (2001) 71–89. [10] T. Modi, Clean up your wire protocol with SOAP, Part 2 Use Apache SOAP to create SOAPbased applications, JavaWorld (April) (2001). Available from . [11] O. Nierstrasz, S. Gibbs, D. Tsichritzis, Component-oriented software development, CACM 35 (9) (1992) 160–165. [12] R.S. Pressman, Software engineering: a practitionerÕs approach, fifth ed., McGraw Hill, 2001. [13] J. Romeo, ERP: on the rise again, Network Computing, Manhasset 12 (19) (2001) 42–52. [14] S.H. Simon, eCommerce Solution for Business and IT Managers, ISBN 0-07-137188-5, McGraw-Hill Publishing, 2001. [15] M. Vizard, IT infrastructures are woefully unprepared for the demands and stresses of ebusiness, InfoWorld, Framingham 22 (2) (2000) 22–27.
