Enterprise Application Model

Application architecture is the high-level plan for building an application to solve a specific business problem. The Enterprise Application Model is an orderly summation of all the requirements for the implementation of any enterprise application, divided into six specific submodels. Table 2.3 lists the requirements as items to define or deliver within each submodel.

Figure 2.3 shows not only the categories of requirements that an enterprise application must meet, but also the relationships between the various requirements. The arrows show that successful application development begins with determining the business requirements and results in the physical architecture of the completed system. Between these two stages, the user, logical, and technology requirements are fulfilled, with each category depending on inputs from both the business requirements and its neighboring submodels, and with each model's outputs directly contributing to the physical architecture that is finally implemented. The Development Model (the teams and processes applied to developing the application) permeates and coordinates all of the other requirements.

click to view at full size

Figure 2.3 Enterprise Application Model

Table 2.3 Submodel requirements of the Enterprise Application Model

Business Business goals
Development cost
Return on investment
Resources needed
Time constraints
Security and maintenance
Existing infrastructure investment
Business rules and policies
User User interface
Ease-of-use requirements
Training and documentation
Application support
User's desktop configuration and network connection
Logical Logical application structure
Object and data modeling
Business objects and services
Interface definitions
Technology Component development or reuse
Development tools
Deployment platforms
System and database technologies
Clustering, pooling, and messaging technologies
Development Development team
Development process
Project management
Source code control
Testing Application milestones and deliverables
Physical Physical application architecture
Distribution and interconnection of components
End product of the iterative inputs of each of the other submodels

The view of the Enterprise Application Model shown in Figure 2.3 immediately provides important insights into the requirements for successful enterprise application development, some of which are listed here:

  • Importance of relationships Understanding the relationships between the different requirements provides a way to move through the process of designing and building the application without neglecting the many dependencies that each design task has on other parts of the overall design. We'll explore this iterative development style at length in the section titled "Enterprise Development Teams and Processes."
  • Importance of requirements All of the requirements embodied in each of the submodels are a part of the overall Enterprise Application Model and contribute to the success or failure of an application, whether or not they are consciously addressed in the development process.
  • Importance of submodels Each submodel can be treated in a relatively stand-alone manner, much like software components. Each submodel has its own set of concepts, requirements, techniques, processes, tools, state storage, and input/output (deliverables). In most cases, the output of each submodel becomes a critical part of the overall functional specification for the project, and this specification is in turn used to define the project's physical architecture and to produce the project test plan.

These insights suggest a development process that is iterative and incremental rather than linear. Such a process involves working on each set of requirements a little bit at a time, pausing at frequent intervals to assess the impact of each model on its neighbors. It helps to identify conflicting requirements early so that necessary design tradeoffs and adjustments can be made before they require re-implemention of major portions of the application.

Designing with the Enterprise Application Model

First and foremost, the Enterprise Application Model is a design tool. It guides application architects through the process of designing and building a large-scale application, by organizing its design requirements into submodels and showing how the submodels fit together. It shows how to balance the competing requirements of every design decision. As a result, the application can be built in small incremental steps, working in any order that seems appropriate, with the confidence that every design choice integrates smoothly with the overall application architecture.

Designing with Submodels

A big advantage of using the Enterprise Application Model as a design guide is that the process can start anywhere. The context and priorities of the project, rather than an arbitrary linear order, determine the correct sequence for traversing from one submodel to another, ultimately fulfilling the requirements of all the submodels. For new projects, the preferred direction is top to bottom, with the needs of the business driving the middle submodels and the needs of the middle submodels driving the physical architecture that is finally implemented. However, good reasons may dictate starting elsewhere—for example, an existing application context that needs re-deployment, or a usability problem that must be fixed.

As the arrows in Figure 2.3 show, the requirements and output from neighboring submodels directly affect each other. These arrows are used to balance and resolve the competing requirements between the submodels while creating the application's Functional Specification.

Regardless of which submodel is worked on first, the general pattern for traversing the model during application design is:

  • Make some design choices in any submodel.
  • See what effect those design choices have on the neighboring submodels, and make any necessary design adjustments in those models.
  • Repeat step 2 until the change has been fully accounted for through the entire Enterprise Application Model.

To give a high-level view of how submodels work, the following example uses some concepts of distributed component-based architecture, such as pooling and scalability, that are not covered until later chapters. If necessary, check the definitions of these concepts in the Glossary.

Suppose that the User Model for an online sales system requires the system to accommodate a twenty-fold increase in the number of users during the holiday season compared with the rest of the year. How does this requirement affect the other models? With each arrow in Figure 2.3, the effects of this requirement ripple through the model as follows:

  • The Business Model This model must provide the justification and resources for changes to be implemented. The impact of technology on support, operations, and other groups within the organization must be assessed. The implementation or acquisition of technology should be considered for all systems. If a project doesn't integrate with the organization's Business Model, it should not be undertaken.
  • The User Model This model provides the user perspective of each project. Each new application released to the user community should provide a common and consistent method of use. When application interfaces are consistent, user productivity can increase.
  • The Logical Model This model must respond by encapsulating the services that interact directly with the user and defining interfaces for them so that they can be implemented as components that can be easily pooled.
  • The Technology Model As a result of changes in the Physical, Logical, and Business Models, this model has to build the pooled components and choose an appropriate scaling technology, such as Microsoft Transaction Server, to coordinate them.
  • The Development Model This model needs to organize the teams that will build and test the pooled components, to allocate resources, and to schedule the development milestones. In the Enterprise Application Model, the Development Model is the glue that ties together the submodels, specifying the overall project resources and defining how the work and deliverables flow from one submodel to another.
  • The Physical Model This model needs to accommodate scaling quickly to a great number of users without degrading performance. Meeting this requirement usually means that a clustering or pooling strategy must be employed so that more instances of the critical components can be made available to the system simply by adding additional servers.

All important submodel output—business requirements, user requirements, business rule logic and algorithms, database schema, performance, and so on—is described in the project's Functional Specification. This is a living document that is continuously changed and updated throughout the development cycle. At each design stage, it's important that any significant change percolate through the other submodels, following the arrows between neighboring submodels until the impact of the change has been fully accounted for throughout the entire Enterprise Application Model. Many iterations of feedback between neighboring submodels might be needed before a change has been completely assimilated.

Balancing Interactions Between Submodels

The Physical Model for an enterprise application is the final outcome of the design process and can be directly derived from the requirements of its neighboring submodels. Because of this, the design process is, to a great extent, a process of balancing the natural contentions between the various submodels.

For example, the Business Model's interest in reducing administration costs might push the Technology Model toward remote processing on central servers. At the same time, the most efficient User Model might suggest local processing on the user's desktop. The process of defining the Physical Model necessarily involves finding an acceptable compromise between these two competing goals.

Understanding these interactions helps determine the order in which design decisions should be made, and can help prevent ill-considered changes to one aspect of the overall design that may unacceptably impact the requirements described in other submodels.

Because the Development Model permeates the entire Enterprise Application Model, this submodel has no "typical" interactions with the other submodels. Every design and implementation decision must be accounted for in the Development Model.

Examples of the common submodel interactions that can occur within the Enterprise Application Model are presented in the following sections. For each submodel, we briefly cover:

  • The major application design questions the submodel answers.
  • The major relationships between it and other submodels.
  • Examples of how it is affected by the Internet.
  • References to more complete information given later in the book.

The Internet is a major new technology and deployment platform for enterprise applications. For this reason, it is less familiar to many developers than other technologies for component-based design and delivery. Its impact is discussed in these brief summaries. Singling it out in this manner is not meant to imply that the Internet is always, or even usually, the best platform for enterprise applications. It is simply an attractive new option that may be the right choice in some situations.

Business Model

The Business Model defines the organization's goals and its reasons for funding the application. Questions about the application that this model answers include:

  • What are the business requirements for this project?
  • What business objectives and features must it provide?
  • What level of investment will provide the best financial return?
  • How fast must the project be delivered?
  • How expensive will it be to deploy?
  • What platforms must it support?
  • How many users must have access to it concurrently?
  • How important is security?
  • How reliable must it be?
  • When will this release be replaced or updated?
  • How quickly must new business policies or user needs be incorporated into new updates?

In an ideal scenario, implementing an enterprise application architecture begins by defining the business requirements embodied in the Business Model. If other models are implemented outside the Business Model context, the business goals supported by the project may not be appropriate for the organization.

How the Business Model Interacts with Other Submodels

Figure 2.3 illustrated that the Business Model directly interacts with the User Model, the Logical Model, and the Technology Model. Table 2.4 characterizes these interactions and gives brief examples of each.

Table 2.4 Interactions of the Business Model

SubmodelHow the Business Model relates to itExample
User Determines who will use the application, their skill levels, and their desktop configuration. An application that will be used by inexperienced personnel must be highly intuitive and well-documented.
Logical Sets policies about how business assets must be managed. These policies are reflected in logical business rules. Business policies determine how shipping, inventory, and sales must respond to new orders.
Technology Determines or constrains the technology needed to satisfy business requirements. A business requirement to directly market the organization's products through electronic commerce mandates Internet technology.

Each of these interactions works both ways. For example, the cost and capacity of new modems may limit the number of customers an organization will be able to serve with its new Internet-based direct marketing application. In this case, the Technology Model might force a reassessment of the goals and requirements of the Business Model.

How the Internet Has Impacted the Business Model

Examples of the way the Internet has impacted the Business Model include:

  • The opportunity to write software that can run without changes on multiple platforms (although with varying degrees of compatibility and reliability).
  • The cost of testing an application on many platforms, virtual machines, and Internet browsers.
  • The opportunity to publish vast amounts of information very inexpensively, increasing product visibility and sales while providing a powerful mechanism to decrease product support costs.
  • The ability to deploy some kinds of "lightly interactive" applications by using the capabilities of Internet servers, thereby reducing deployment costs.
  • The need to protect the organization from malicious attacks on Web servers and the risk of Internet-delivered viruses or non-sanctioned components.

User Model

The User Model defines the target user of the application. Questions about the application that this model answers include:

  • Who are the users and what are their skills, experiences, and use cases or scenarios?
  • What are the user requirements for task sequencing, usability, training, responsiveness, performance, and interoperability with external applications and data?
  • Are users dedicated employees who can tolerate usability quirks or inconveniences, or are they consumers who may not buy the product if its user interface is not easy, reliable, and efficient?
  • How much feature documentation and help will users need? Will they have the patience to read documentation?
  • Will users require product support? Will they pay for it?
  • How many users will be accessing the application at any one time?
  • How powerful are the users' computers, and how fast are their network connections?
  • What is required to ensure proper security?

In larger or more formal environments, the User Model itself can be separated into four relatively independent submodels: the Usability Model, the Documentation Model, the Support Model, and the User Security Model.

How the User Model Interacts with Other Submodels

Figure 2.3 illustrated that the User Model directly interacts with the Business Model, the Logical Model, the Technology Model, and the Physical Model. Table 2.5 characterizes these interactions and gives brief examples of each.

Table 2.5 Interactions of the User Model

SubmodelHow the User Model relates to itExample
Business The number of users, their skill levels, and desktop configurations determine the cost of training and supporting them. A retail order-entry application must be fast to accommodate busy clerks. This may require additional hardware or infrastructure investments.
Logical How the user thinks about the tasks and works at them determines how the functionality must be logically encapsulated. If a customer's credit can be checked while the order is being taken, the credit-checking functionality must be in a separate, asynchronously processed component.
Technology User requirements determine the technology needed to meet them. An application deployed on the Internet must use platform-independent technology for the user-interface elements.
Physical The number of users and their locations affect the component architecture needed to reach them effectively. An application that will be used by a rapidly changing number of users must deploy its user-intensive services in an easily scalable configuration, such a component pool or queue.

How the Internet Has Impacted the User Model

Examples of the way the Internet has impacted the User Model include:

  • Access to an enormous wealth of professionally published HTML-based information.
  • A huge growth in the opportunity to reach untrained consumers directly from enterprise applications.
  • A significant fear of "Big Brother-like" Web applications gaining access to personal desktop resources.
  • A loss of some user interface form-rendering techniques.
  • Slower user-interface responsiveness in applications, based on slow network links.
  • Unreliable information and application access over relatively fragile Internet links.

Logical Model

The Logical Model defines the business entities that will be rendered by the application, and what policies and rules will be used to operate on those entities. The questions this model answers are very specific to the business for which the application is being developed. Questions about the application that this model answers include:

  • When should a customer be given a purchase discount?
  • When should inventory be restocked?
  • How much sales tax should be charged on an out-of-state order?

The Logical Model itself is made up of two relatively independent submodels:

  • The Logical Data Model This submodel is responsible for documenting the business entities that the system manages (for example, products, customers, and orders) and the rules for maintaining them (for example, "All new orders must be represented in the Orders Table as well as the Shipping Table").
  • The Logical Object Model This submodel is responsible for documenting the rules and algorithms that operate on the data entities, determining how these rules are grouped into interfaces and classes, and assessing how the various objects interact among themselves to solve macro-level requirements. The Logical Object Model is also used to specify how each object fits into an N-tier application design.

How the Logical Model Interacts with Other Submodels

Figure 2.3 illustrated that the Logical Model directly interacts with the Business Model, the User Model, the Technology Model, and the Physical Model. Table 2.6 characterizes these interactions and gives brief examples of each of the interactions.

Table 2.6 Interactions of the Logical Model

SubmodelHow the Logical Model relates to itExample
Business Determines how business policies can be encapsulated. An application that must accommodate rapidly changing tax rates and rules must isolate these rules in separate, easily maintainable components.
User Defines the logical entities users act on to perform various business tasks. Logical customer and order objects and credit-checking services are needed to enable users to carry out typical sales tasks in the application.
Technology Specifies the features and services that must be packaged into the chosen technology's components. A credit-checking component must use technology capable of interfacing with credit reporting agencies.
Physical Determines the features and services that must be deployable using the chosen physical architecture. A funds transfer component must be deployed upon an infrastructure that supports reliable security protocols.

How the Internet Has Impacted the Logical Model

Examples of the way the Internet has impacted the Logical Model include:

  • Increased use of N-tier application designs that separate business logic from user-interface behavior, as organizations strive to encode business functionality on powerful Internet application servers.
  • An aggressive push by corporations and third-party software vendors to implement their new functionality with objects that can be more easily maintained and reused, improving responsiveness.

For the most part, the Internet is a physical phenomenon. It will not have a significant impact on the Logical Model of those organizations that have already moved to object-oriented, LAN-based development.

Technology Model

The Technology Model defines the technology services that are available to solve the application's requirements. The Technology Model is used to identify, acquire, or create the necessary technical resources that support the requirements. Questions about the application that this model answers include:

  • What operating system features can be assumed to be on the desktop, on the server, and on the database?
  • What network protocols will be supported?
  • What security technology will be used?
  • How will technology be used to assist with high-end scalability?
  • How will database integrity be maintained across multi-component and multi-database transactions?
  • How will large, asynchronous requests be handled?
  • What technology will be used to access legacy systems?
  • How will UI forms be rendered?
  • What technology will be used to access data on a remote database?
  • What technology will be used to replicate data across database servers, or on the desktop?
  • Considering the needs of the business (such as schedules, resources, skills, and costs) and the capabilities of the available technology (such as objects and components, data access, graphical user interface forms, distributed transactions, security, design tools, programming tools, and bug tracking), how should the product be built?
  • What tools should be used to help build, debug, integrate, or deploy the application?

Code written and compiled for the project becomes part of the Technology Model, just like controls or operating system services picked up from external sources. Similarly, the source code for the project is part of the Technology Model, in the same way that usability test reports are part of the User Model.

How the Technology Model Interacts with Other Submodels

Figure 2.3 illustrated that the Technology Model directly interacts with the Business Model, the Logical Model, the User Model, and the Physical Model. Table 2.7 characterizes these interactions and gives brief examples of each.

Table 2.7 Interactions of the Technology Model

SubmodelHow the Technology Model relates to itExample
Business Implements the application's business objectives into the physical system. New Internet technologies create business opportunities that were previously unavailable.
Logical Implements the logical structure of the application as physical components. Business rules are encapsulated in components that run on the application's infrastructure.
User Delivers application functionality with technology appropriate to the user's skills, desktop configuration, and connectivity. If an Internet application gives users remote database and business-processing services, the development team must acquire the tools to program, debug, and test multi-user, asynchronous, distributed applications.
Physical Provides the technology to deliver the application functionality on the chosen physical architecture(s). If an Internet application must run on servers that use different operating systems, the development team may have to use multiple programming languages and tools.

How the Internet Has Impacted the Technology Model

Examples of the way the Internet has impacted the Technology Model include:

  • The availability of Hypertext Markup Language (HTML), Java, Hypertext Transfer Protocol (HTTP), Internet servers, LAN firewalls, component signing, and desktop-based Web browsers.
  • The need for fast application servers to remotely process business rules.
  • The possibility of adding additional new end-user platforms to the test and development support list.

Development Model

The Development Model defines the process and resources used to develop an application, and is the "glue" that allows all the submodels to work together. Questions about the application that this model answers include:

  • Who should work on what part of the overall development problem?
  • In what order should submodel tasks (such as logical object design, usability testing, database design, programming, and testing) be performed, and how should progress be measured?
  • How many developers are assigned to the project and what are their skills?
  • What specialized activities should be employed to optimize development efficiency and final quality of the deliverables?
  • How should the project be managed and coordinated with other projects?
  • How important is software reuse and componentization? (The answer to this question influences coordination, the importance of standards, the time spent on design, and the value of a general-purpose architecture.)
  • How should work in progress be shared and promoted for other developers and testers to use?
  • How should the application be deployed into the final production environment?
  • How will administration be managed?
  • How will updates be deployed?

The Enterprise Architecture Development Model can effectively use two additional MSF models. However, these models can also stand alone and should be considered peers.

  • MSF Team Model for Application Development This model, which is concerned with the organization, coordination, and management of development teams, is discussed in Chapter 3.
  • MSF Process Model for Application Development This model, which addresses issues of planning, scheduling, and milestones, is discussed in Chapter 4.

How the Development Model Interacts with Other Submodels

Figure 2.3 illustrated that the Development Model permeates all the other submodels, guiding the process of development through them and coordinating their requirements and deliverables. In this respect, there are no "typical" interactions, because every design and implementation decision must be taken into account in the Development Model.

How the Internet Has Impacted the Development Model

Examples of the way the Internet has impacted the Development Model include:

  • An enormous increase in the importance of server-based (UI-less) logic.
  • An increase in the complexity and resource requirements for testing and debugging complex, multi-user, distributed, continuously running applications.
  • An emphasis on the value of location-independent components, and all the processes involved in their development, coordination, and sharing.
  • An extension of the developer or programmer roles to include the roles of author and publisher.
  • The creation of a strong commercial demand for a universal, scalable, and component-oriented enterprise application architecture.

Physical Model

The Physical Model defines where the physical resources to support the requirements of the other submodels of the application are deployed. It also specifies the process through which competing interests of the submodels are resolved. The completed Physical Model of an enterprise application is the application's architecture. Questions about the application that this model answers include:

  • How will the physical resources of computers, network bandwidth and protocols, databases, components, operating system and back-office services, and third-party features be used to meet the overall needs of the business (such as scalability and robustness)?
  • How will existing deployments migrate to desired deployments?
  • How can resources be accessed most efficiently (for example, local machine versus the Internet)?
  • How can usability and throughput performance requirements be met in execution environments that include slow LAN or WAN access times, intermittently disconnected network servers, and unreliable Internet connections?

Application Architectures

An application architecture is a conceptual view of the structure of an application. As shown in Figure 2.4, each application has three distinct layers: the user layer, the business layer, and the data layer. Each application also contains presentation code, business-rule processing code, data processing code, and data storage code. Application architectures differ in how this code is packaged to form a particular application product.

click to view at full size

Figure 2.4 Physical Model and its application layers

Many current applications have a two-tier architecture, also known as client/server architecture. In a two-tier architecture, a client process handles the data processing and presentation parts of the application. Data is stored on centrally administered server machines. Clients connect directly to the servers they need, often for the lifetime of the application's use.

Client/server applications work well in controlled environments in which the number of users can be estimated and managed, and resources can be allocated accordingly. However, when the number of users is unknown or very large, the client/server architecture breaks down. Because each client connects to data servers directly, the number of available data connections limits scalability. Opportunities for reuse are limited because the clients are bound to the database formats. Each client application contains data processing logic, making the applications relatively large. (This type of client is sometimes called a fat client.) If the data processing logic ever needs to change, new applications must be distributed to every client computer.

A slight improvement comes from moving parts of the data processing, or business logic, to the data servers—for example, by using Microsoft SQL Server stored procedures. This architecture is sometimes called "two-and-a-half tier." Applications built on this model are somewhat more scalable, but not scalable enough to meet the needs of highly distributed applications. In addition, opportunities for reuse are limited.

Scalability and reuse can be improved significantly by introducing a third tier to the application architecture. With multi-layer architecture, also known as N-tier architecture, the user, business, and data tiers are logically separated, as illustrated in Figure 2.5.

Figure 2.5 Multi-layer application architecture

The three tiers perform the following functions:

  • User tier The presentation tier presents data to the user and, optionally, lets the user edit data. The two main types of user interfaces for PC-based applications are native and Web-based. Native user interfaces use the service of the underlying operating system. On the Microsoft Windows platform, for example, native user interfaces use the Microsoft Win32 API and Windows controls. Web-based user interfaces are based on HTML and Extensible Markup Language (XML), which can be rendered by a Web browser on any platform. We look at the user tier more extensively in Chapter 7.
  • Business tier The business tier is used to enforce business and data rules. The presentation tier uses the services of the business tier. However, the business tier is not tied to any specific client; its services are available to all applications. Business rules can be business algorithms, business policies, legal policies, and so on—for example, "Users get a 10 percent discount for ads placed before Tuesday night" or "Six percent sales tax must be collected for all orders delivered to the Commonwealth of Kentucky." Data rules help to ensure the validity and occasionally the integrity of the stored data—for example, "An order header must have at least one detail record" or "Money must not be lost or generated during transfers between bank accounts." Business rules are typically implemented in isolated code modules, which are usually stored in a centralized location so that multiple applications can use them. (This code isolation embodies the software management principle of component-based development, discussed earlier in this chapter.) The business tier is discussed further in Chapter 8.
  • Data tier The business tier has no knowledge of how or where the data it works on is stored. Instead, it relies on the data access services, which perform the actual work of getting and putting the data. The data access services are also implemented in isolated code modules, encapsulating knowledge of the underlying data store. If the data store moves or changes format, only the data access services need to be updated. Each data access module typically is responsible for the integrity of a set of data—for example, data placed in relational tables or Microsoft's Active Data Object (ADO) and OLE DB technology. We discuss data access technologies more extensively in Chapter 9. For the purpose of N-tier design, the data store is simply the database management system (DBMS)—the systems required to serve data from tables, as well as optimize information retrieval, such as database indexes. Examples of data stores will be provided in Chapter 9, but include SQL Server, Exchange Server, In Memory Database (IMDB), and Microsoft Access.

It may be slightly confusing to talk about logical architecture as part of the Physical Model. It is important to understand that logical architecture encompasses a wide range of physical architectures and implementations that specify where services are deployed. In other words, applications are constructed as logical networks of consumers and suppliers of services. Services are merely units of application logic that provide well-defined functionality.

The terms multi-layer and N-tier don't imply separate computers. The N-tier application architecture promotes scalable applications. To create highly scalable applications, resources such as database connections must be shared. Instead of each client application consuming resources to access data servers directly, client applications communicate with business services. One instance of a business service can support many clients, reducing resource consumption and improving scalability, as shown in Figure 2.6 and Figure 2.7. Because business services do not manage data directly, it's easy to replicate these services to support even more clients. Services can often be designed and implemented independently of any particular client applications, providing flexibility and the potential for reuse in many applications. By encapsulating application logic behind well-defined public interfaces, developers create a body of reusable services that can easily be combined in new ways to create new applications. In addition, common functionality can easily be updated in response to changing business requirements, without impacting the client applications that rely on the functionality. This reduces the management and deployment costs of changing requirements.

Figure 2.6 Client/server systems

click to view at full size

Figure 2.7 N-tier systems

The multi-layer application architecture can also help developers deal with existing, or legacy systems. Developers can "wrap" access to existing systems within business logic, data access, or data store services. Client applications need to worry only about how to access the business logic, not about how to access all the different legacy systems they might rely on. And if the legacy system is modified or replaced, only the wrapper needs to be updated.

How the Physical Model Interacts with Other Submodels

Figure 2.3 illustrated that the Physical Model directly interacts with the User Model, the Logical Model, and the Technology Model. Table 2.8 characterizes these interactions and gives brief examples of each.

Table 2.8 Interactions of the Physical Model

SubmodelHow the Physical Model relates to itExample
User Provides the means by which the application is made available to users. The physical architecture must be able to support users' desktop configurations and scale efficiently to the number of users and their processing requirements.
Logical Determines the extent to which logical constructs can be mapped to the physical infrastructure. An application that provides online transaction processing must define components that can interface with a transaction management infrastructure.
Technology Limits the technology that can be supported on the physical infrastructure. An application deployed to the public on the Internet must use "least common denominator" technology for user-interface elements that must run on a variety of platforms and browsers.

How the Internet Has Impacted the Physical Model

Examples of the way the Internet has impacted the Physical Model include:

  • An enormous increase in the importance of using highly scalable architectures to support unknown or unlimited numbers of Internet users.
  • A requirement to access application functionality (business logic) from many different client platforms.
  • An enormous increase in the use of distributed, asynchronous resources.
  • The enabling of new application types, including simple informational applications (simple HTML) and active informational applications (interactive HTML, ActiveX, and Java).
  • The introduction of traditional desktop-oriented applications embedded in Web pages.
  • The availability of installation-free user interfaces (browser-based HTML).
  • The need for corporate firewalls between internal LANs and the public Internet.
  • The need for on-demand, server-based application installation (ActiveX components and Java applets).
  • The introduction of the packaging (.cab and .zip files) and digital signing of components.

Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Microsoft Corporation - Analyzing Requirements and Defining Solutions Architecture. MCSD Training Kit
Year: 1999
Pages: 182

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net