Showing posts with label Server Architectures. Show all posts
Showing posts with label Server Architectures. Show all posts
  • Intranet, Extranet, Internet The rise of the Internet occasioned a major upheaval in the way systems are used. Prior to the Internet, each system had its own ergonomics and manmachine interface; a user who wanted to use an application or to access data on a particular server had to adopt that system’s approach; using services on several different systems was therefore a burden to the user, since each could be different. With the Internet’s communications and presentation standards (HTTP and HTML), a much greater degree of transparency was achieved between servers and their users; the industry-wide convergence on TCP/IP as the communications protocol of choice was the first step in this simplification.

    To be able to accommodate the new uses and users enabled by the Internet, servers had to support these protocols. In other words, with the rise of the Internet, servers adapted to clients, whereas, in the past, the clients had to adapt to the server.

    One can characterize the various Internet variants in the following way:

    » Internet. Indicates the network upon which applications and information are put available for any public use and with limited security

    » Intranet. Indicates a network where private applications and information are limited to a “community” (generally a company) and present a high degree of security. Access by people outside the community is not allowed

    » Extranet. Indicates a network of the type Intranet extended to partners in whom a high degree of confidence is placed Access by people outside the partnership is not allowed. A high degree of security is associated such networks

    By May 2004, there were about 786 million Internet users world wide (source: InternetWorldStats.com).

    We will not differentiate between Internet, Intranet and Extranet in our description of the technologies used, since the differences are differences between users—employee for an Intranet, employee and partners for an extranet, and everyone in the case of the Internet—not technologies. The user differences give rise to differences in administration and security management, but not at the level of server programming.

    The first things that the Internet asks of a server are the properties of scalability and high availability. Scalability, because predicting the number of users in advance is difficult; high availability because in the absence of availability, a customer attempting e-commerce with a site and finding it unavailable will simply go and buy elsewhere—the distance between two electronic shops is just a mouse click.

    Source of Information : Elsevier Server Architectures 2005

    more

  • Database Access Techniques The client/server model implies access by applications to remote databases— that is, databases located on another system. Further, there are diverse types of databases to be accessed, the diversity arising from any number of factors, including different decisions being made by different portions of the company, or as a side effect of company mergers; this all implies that it is desirable that access methods for databases are independent of the DBMS’s themselves. This is a real problem; although all databases provide SQL as an access method, various vendors have independently extended SQL in different manners compromising portability of applications between DBMS’s.

    Various approaches have been proposed to meet the need for DBMSindependent access techniques. In this area, as in others, there are examples of scarcely-used or implemented standards, along with proprietary solutions which have the advantage of existing and working but the obvious drawback of instigating captive applications.

    The access to a remote database includes the following dimensions: the interface, on the one hand, and FAP (formats and protocols), on the other hand.

    As to the interface between applications and a DBMS, two approaches are distinguished:

    » Embedded SQL (ESQL), which uses a precompiler to translate SQL commands embedded in the application program; with this approach, calls are fixed at application creation time

    » Direct SQL calls (CLI—Call Level Interface), which do not require the application to know at creation time just which DBMS will be used

    The work done within the SAG (SQL Access Group) consortium, comprising
    several DBMS vendors, has resulted in a number of solutions. The first type of solution uses a CLI interface to provide access to a wide variety of DBMS; it is the ODBC (Open DataBase Connectivity) standard proposed by Microsoft.

    ODBC is implemented at the workstation level. For each DBMS to be supported, it is necessary to develop a specific ODBC driver.

    The principal difficulty with ODBC is that its specification is controlled by Microsoft and that it keeps changing. There is a similar technique for use in a Java environment, called JDBC, for Java DataBase Connectivity.

    A second type of solution implements an open link approach, which converts application SQL commands (whether embedded or CLI) into SQL commands understood by each DBMS. In practice, this requires that the DBMS vendors support a common FAP. There are several competing solutions available of this type, including SAG’s RDA (Remote Data Access), and IBM’s DRDA (Distributed Relational Data Access) the latter provides several models for the interaction of the application with database, and also supports two-phase commit.

    Source of Information : Elsevier Server Architectures 2005

    more

Subscribe to: Posts (Atom)