Will the real client/server please stand up? This is a question often posed due to changes in architecture and technologies over the last twenty-five years. According to Orfali (1999), several client server types exist such as:
1. File servers
2. Database servers (SQL calls)
3. Transaction servers (1-3 seconds)
4. Groupware servers (Microsoft Exchange and Sharepoint, MOO, CSU Interact, MOODLE)
5. Object servers (ORB-communicating objects)
6. Web application servers (HTML, Java, CGI, ASP).
The Orfali text also gave an excellent overview of client/server computing for over ten years and is a still good reference text. Orfali stated that 'the road to bandwidth heaven' will govern future development and migration towards wireless and mobile device networks requiring further protocol and network design. As bandwidth availability will grow with 'fibre to the premises' many changes beyond those endured by Web 2.0 will proliferate.
Various client/server systems just shuffle the location of the application logic around – from the client end to the server end of the networked relationship. See the 'see-saw' diagram below in Figure 2.1.
E-business applications development: Architectures, models, methods, and methodologies
Many of the new client server development projects are related to E-Commerce and M‑Commerce systems - or E-Systems; so the term 'client/server', with its roots in the paradigms of distributed computer applications over a network, takes on a new image.
Burying your treasure
Several common layers, or tiers, exist in the way that a client/server application is developed. The historical development from 1, 2, 3 to 'n' tiers is shown below:
1-tier client-server architecture - all the application logic is at the server end.
2-tier client-server architecture - either client or server has application logic buried inside.
3-tier client-server architecture - the application logic is in the middle tier.
'n'-tier client-server architecture - many component services exist in the middle tier.
Communications and networking
Data communications and the underlying network architecture and operating systems largely determine and enable the type of e-commerce that can be carried out by an organisation:
· The Internet and mobile e-commerce
· Architecture of web systems
· Data interchange (mobile devices, SMS, GPS)
· Bandwidth and Bluetooth devices(access)
· Cryptographic security
· Electronic payments
· Databases
· Multimedia (videoconferencing).
As bandwidth, viewing devices and mobile connection prices improve remote devices such as mobile phones and PDAs will play an increasingly important role in the expansion of e-systems and services. Corporate solutions such as database, e-mail servers, enterprise-wide intranet and extranets are changing due to new technologies such as the availability of broadband services, and the use of new protocols and language definitions such as SOAP, XML, RSS and new API's.
Client/server architecture: Some background information
E-commerce models and e-business applications are really just current themes in the longer history of client/server applications and the architecture that supports that interaction - so some basic definitions may be handy. Distributing parts of an information system across many computer systems and locations has been called distributed computing. Client-server architecture is the dominant architectural model for distributing information system resources across a network.
Client-server architecture divides software into two parts - client and server. A server manages one or more system resources and provides access to those resources through a well-defined communication interface. A client uses the communication interface to request resources and the server responds to those requests. Modern variants of client-server architecture divide application software into the following set of client and server processes - called layers of tiers: data layer, business logic layer and presentation layer. The term middleware describes software that 'glues' together multiple components in a client-server or multi-tier application.
Connections to remote resources can be either static or dynamic. A static connection is initialised by the user or system administrator prior to accessing a remote resource. Static connections are inherently difficult to initialise and maintain. The resource locator maintains a resource registry containing the names and locations of known resources and services. The interaction between a
resource locator and a primary resource registration repository is inherently dynamic. Connections established through those interactions are dynamic connections.
A server can be stateful or stateless. When the state is maintained by a 'statefull'
server, it tracks states such as location, selections made, and user information. For a 'stateless' server like a Web server - no information is maintained on the server (e.g. HTML page in a browser - but you can use cookies to get around this if needed).
Interprocess communication
When an application is split into multiple processes, those processes must communicate with one another to share data and coordinate their activities. A variety of protocols and standards have been developed to address the problem of process coordination across networks. Peer-to-peer communication protocols and the use of sockets, named pipes and remote procedure calls assist with such coordination.
Sockets, ports, pipes and your operating system
A socket is a unique combination of an IP number and a port number. Some port numbers are permanently assigned for standard Internet or vendor-specific services, but many port numbers are available for other uses including client-server or peer-to-peer communication among application programs. A named pipe is a pipe that has a name that is permanently placed within a file system directory and has the ability to communicate among processes on different computers. The operating system at both ends of the pipe manages communications to and from the pipe. With a remote procedure call (RPC), a process on one machine can call a process on another machine.
Common port numbers
See the list of TCP and UDP port numbers at http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
From Client/Server to Web frameworks
The section on Web Application Architecture Patterns require you to determine what are the significant components of your system. The basic idea is: where do you put the business logic? On the server, in an ASP page, or in a distributed object? Conallen (2003) describes the three most common patterns as:
1. Thin client with business logic on the server.
2. Thick client with business logic executed on the client machine (Java applets, ActiveX controls etc.).
3. Web delivery with distributed objects - RMI, CORBA using IIOP, Java Beans and DCOM to support delivery by using the browser client as a delivery and container device.
Thin client means the normal desktop that sits on clients' desktop, and does not have much in the way of processing power, disk space or memory. All of the processing is performed on a central server, rather than on the clients' PCs. On the desktop appears a desktop window, though the difference between this and a normal PC is that the processing and saving of files is not happening locally. Clients use the web browser to interact with the server.
The 3-tier client/server architecture can be mapped to the newer Web application frameworks like Ruby on Rails or Django with the Model-View-Controller design approach, as shown below:
data layer (guarded by the server) … the MODEL
business logic layer (middleware) … the CONTROLLER
presentation layer (text or GUI client) … the VIEW
Posts
0 comments:
Post a Comment