Optionally authenticates the users •
SOCKS was originally intended as a network firewall. Because of its simplicity and flexibility, SOCKS has been used as a generic application proxy, in virtual private networks VPNs, and for
extranet applications. SOCKS offers unique features and benefits:
Application−independent protection — as soon as new applications appears, SOCKS can protect them without need for any additional development.
• Flexible protection through a variety of access control policies based on user, application,
and time criteria, in addition to source and destination addresses. •
Bidirectional proxy support — SOCKS identifies communication target through domain names, overriding the restriction of using the private IP addresses. SOCKS can use domain
names to establish bidirectional communication between separate LANS with overlapping IP addresses.
•
Other IP−layer based proxy mechanisms, like the network address translation NAT, support only unidirectional connections, from the private network the intranet toward the external network the
Internet. For some applications, like multimedia applications, it simply cannot work; these applications request the return data channel.
25.2.4 Web Services
We have discussed in this section primarily intranet−related services. Without these services, or at least some of them, intranet cannot function at all. The services themselves are functionally
unidirectional, and their main purpose is to protect an intranet and provide the selected transparency toward external Internet services. Just recall firewalls or proxy servers. But there is
another side of the intranet−Internet story: do we want also to present our intranet community to the external world? In most cases the answer is positive. Intranet owners, whoever they are —
companies, organizations, colleges — wish to publish certain information to the public. And they can find the audience on the Internet.
Web services make this wish become a reality. As an example let us look at a companys intranet. The companys Web page on the Internet is its public face and presents the image the company
wants the world to see. It may be built glamorously, with many graphics and special features to attract Web visitors — potential patrons and customers — and catch their attention. While the
intranet is the companys private face, hidden from external viewers, that makes a working environment for its employees, the purpose of Web services is the opposite — advertise the
company to as many people as possible. And both use almost the same hardware and software for the two very different purposes. A Web service can exist without an intranet there are many Web
sites without intranet backings, while the opposite is extremely rare. Everybody tends to want to be recognizable worldwide.
There are many variations on the name Web services: World Wide Web WWW, Web Hosting, Information Superhighway, and sometimes even simply intranet. Without elaborating the
correctness of certain names, we will primarily use the name Web service services.
Web services are self−contained, modular applications that could be described, published, located, and invoked over a network:
A Web service needs to be created, and its interfaces and invocation methods must be defined.
•
639
A Web service needs to be located for being invoked by potential users. •
A Web service needs to be invoked to be of any benefit. •
A Web service may need to be unpublished when it is no longer available or needed. •
These academic definitions of Web services could be expressed in other, more comprehensive ways:
Web services are HTMLXML−based information exchange systems that use a network for direct application−to−application interaction. These systems can include programs, objects,
messages, andor documents. •
Web services provide data−independent mechanisms to programmatically expose business services on the network using HTMLXML protocols and formats.
• Web services could be accessed by using browsers Web clients, but do not requires the
use of either browsers or HTMLXML. •
The foundation of the Web services is the hyper−text transfer protocol HTTP a simple TCPIP−based application protocol default port number is 80. The HTTP protocol is used to
format, transmit, and link documents of different type text, graphics, sounds, animation, and video. Web−based information comes in a standardized format known as hypertext markup language
HTML. Hyper−text in the name means that the text contains hot links which, when activated, refer directly to another body of information. Markup language means documents are prepared in a
generic way that will allow them to be displayed on any clients video display. HTML documents are generally referred to as web pages. An improved version of HTML is known as extensible markup
language XML. XML is already in wide use today, and it will probably completely replace HTML in the future.
The JavaTM 2 Platform, Enterprise Edition J2EE technology provides a component−based approach to the design, development, assembly, and deployment of Web services. The J2EE
platform provides a multitiered distributed application model, the ability to reuse components, a unified security model, and flexible transaction control. By intent, Web services are not implemented
in a monolithic way, but rather represent a collection of several related technologies. At a bare minimum, any Web service entails a connection between two applications — in programmers
parlance, a remote procedure call RPC — in which queries and responses are exchanged in XML over HTTP. The more generally accepted definition, however, implies implementation of a stack of
specific, complementary standards, as presented in the Figure 25.9.
640
Figure 25.9: The Web services technology stack. Today, the core layers that define basic Web services communication have been widely accepted
and likely will be implemented quite uniformly. Higher−level layers that define strategic aspects of business processes remain an open question, however, and it is possible that divergent approaches
will emerge. The development of generally open and accepted standards is a key strength of the coalitions that have been building Web services infrastructure. At the same time, these efforts have
resulted in a dizzying array of jargon and acronyms. We will focus on the core layers; higher layers are business−related, and they are beyond the scope of this text.
Core layers of the Web services stack are: Common Internet Protocols. Although not specifically tied to any transport protocol, Web
services build on ubiquitous Internet connectivity and infrastructure to ensure nearly universal reach and support. In particular, Web services will take advantage of HTTP, the
same connection protocol used by Web servers and browsers. •
Extensible Markup Language XML. XML is a widely accepted format for exchanging data and its corresponding semantics. It is a fundamental building block for nearly every other
layer in the Web services stack. •
Simple Object Access Protocol SOAP. SOAP is a protocol for messaging and RPC−style communication between applications. It is based on XML and uses common Internet
transport protocols like HTTP to carry its data. SOAP has been submitted to the World Wide Web Consortium W3C standards body and will emerge soon as XML Protocol XP.
•
Web services, as they are described here, make a framework for further development and implementations in the area of e−businesses. In that light they are more appropriate for future
events than the current state of the art. However, the origins of Web services are in the todays WWW, and WWW is currently the main player on the Internet.
WWW is built as a serverclient application. At the server side is the Web server, which hosts Web sites, provides support for HTTP and other implemented protocols, and executes server−side
programs that perform certain functions. Such programs are CGI scripts or servlets CGI stands for common gateway interface that provide dynamic creation of Web pages. Web server provides
services to one or more Web containers. A Web container presents a ubiquitous, accessible, and consistent platform that provides a first−class environment for deploying and running of the Web
641
Web browsers are at the client side. The browser is a program that reads Web−based information in the standardized HTMLXML format. It contacts a remote Web server and places requests on behalf
of users. The requested documents are then transferred and displayed on the users video display. Currently, the two most popular browsers are Netscape Navigator and Microsoft Internet Explorer.
The browser follows the specified pointer to look for certain objects or service. This pointer is known as the uniform resource locator URL and contains five basic components:
Protocol or application identified by: http:
♦ HTTP protocol to access Web pages
https: ♦
secure HTTP protocol based on HTTPSSL ftp:
♦ FTP protocol to transfer files
mailto: ♦
Send e−mail to the designated address news:
♦ Access Usenet newsgroups
telnet: ♦
TELNET protocol for remote login ldap:
♦ Access LDAP directory services
file: ♦
Access a local file on the browsers machine 1.
Hostname 2.
Domain host name of the Web server.
TCP port
3. Optional; otherwise the default port is assumed 80 for HTTP.
Directory 4.
Optional; otherwise the document directory configured at Web server is assumed.
Filename 5.
Optional; otherwise the default filename index.html is assumed. The filename is case sensitive.
As an example, the following URL: http:www.scps.nyu.edudemoexample.html
• specifies Web page example.html on the Web server www.scps.nyu.edu in the subdirectory demo
the subdirectory is referred to the configured document home directory for the server. The WWW includes more than just Web page browsing. This is a suite of many well−known network
services. The implemented URL identifies the requested network service the first URL component.
A Web server is a daemon, usually named httpd, which is listening for incoming HTTP requests at the configured port default port number is 80. The Web server configuration is an OS−independent
procedure characterized by a separate set of configuration rules. Generally Web server configuration files are well−commented, with logical and comprehensive syntax and an intuitive
content. They are definitely very different from old−fashioned condensed and unfriendly UNIX configuration files, which were designed a long time ago to be primarily machine oriented.
Unfortunately, it does not mean that the configuration of a Web server is an easy task. There are many configuration details, enough for quite a tick book.
642
cat usrlocalapacheconfhttpd.conf presented only partially .....
..... Section 3: Virtual Hosts
VirtualHost: If you want to maintain multiple domainshostnames on your machine you can setup VirtualHost containers for them.
Please see the documentation at URL:http: www.apache.orgdocsvhosts for further details before you try to setup virtual hosts.
You may use the command line option −S to verify your virtual host configuration.
If you want to use name−based virtual hosts you need to define at least one IP address and port number for them.
VirtualHost 146.25.91.112 DocumentRoot usrlocalmyserverwww
ServerName myserver.scps.nyu.edu Directory usrlocalmyserverwww
AllowOverride AuthConfig
Options FollowSymLinks Order allow,deny
Allow from all SetHandler server−parsed
Directory ScriptAlias cgi−bin usrlocalmyservercgi−bin
ScriptAlias admin usrlocalmyserveradmin ScriptAlias gifs usrlocalmyserverwwwgi fs
Directory usrlocalmyservercgi−bin
AllowOverride None Options FollowSymLinks
Order allow,deny Allow from all
Directory VirtualHost
..... .....
To respond to incoming requests for Web pages, multiple Web server daemons are running simultaneously, and new daemons could be spawned on an as needed basis. The number of
daemons, both initial and maximum, is configurable. These configuration parameters should reflect real needs and processing power of the implemented Web servers hardware. Here is an example:
ps –ef | grep http | grep –v grep
root 470 1 0 12:43 ? 00:00:03 usrlocalapachebinhttpd nobody 473 470 0 12:43 ? 00:00:01 usrlocalapachebinhttpd
nobody 474 470 0 12:43 ? 00:00:00 usrlocalapachebinhttpd nobody 475 470 0 12:43 ? 00:00:00 usrlocalapachebinhttpd
nobody 476 470 0 12:43 ? 00:00:00 usrlocalapachebinhttpd nobody 477 470 0 12:43 ? 00:00:01 usrlocalapachebinhttpd
nobody 478 470 0 12:43 ? 00:00:00 usrlocalapachebinhttpd nobody 479 470 0 12:43 ? 00:00:01 usrlocalapachebinhttpd
nobody 480 470 0 12:43 ? 00:00:01 usrlocalapachebinhttpd nobody 481 470 0 12:43 ? 00:00:00 usrlocalapachebinhttpd
nobody 482 470 0 12:43 ? 00:00:00 usrlocalapachebinhttpd
643
Web pages require permanent maintenance and update. Otherwise they soon become obsolete and nonattractive. A good Web page has to be well organized, clear, simple, and intuitive to follow,
readable and comprehensive. An overcrowded page could be counter−productive because users are eager to browse quickly through presented material. It is better to put the existing material in
several linked pages instead of a single page. Finally, an appropriate balance between textual and graphic presentation is a key for a successful Web page.
It is very difficult to predict an exact number of hits to a newly designed Web server. But an increase in the load over the time is expected. The scalability and the availability of the Web services are
very important. A possible solution can include multiple Web servers behind a special front−end device known as the load director. All servers provide the same service, and the load director
controls a load balance among all available servers. If an individual server fails, the load is distributed between other active servers.
A need for Web services is primarily business driven. But it would be naïve to expect that all business problems will be solved if you provide a technically good WWW site. Following are some
tips on what not to expect from a Web presence:
Do not expect a WWW site to produce miracles. Placing a Web page up on the Internet is no longer enough. If you want people to visit, you must drive them there. The Internet must be a
part of a total marketing mix in order to be effective. It must be a reason for customers to place an order, or anything else for that matter. The reason could be anything from greater
and easier access to information, up to saving money by placing an order over the Internet. •
Do not think of the Web as a place for outsiders only. The Web can also be inside the companys intranet for information like employee manuals, questionnaires, employees 401
K plans, as well as core business functions like placing orders, workflow applications, etc. •
Do not expect to have to throw away the existing hardware and software. The company has made substantial investments in the core business systems over time. As a general
principal, needed information should be accessible on the Internet intranet site. •
Do not expect to be dependent on one hardwaresoftware company ever again. A properly done Internetintranet site including any custom programming that has to be done should
be able to run on any platform. If IT personnel have chosen a Solaris operating system, a properly done site should be able to run on a Hewlett−Packard, IBM, or DEC box, too.
•
Do not ignore this technology. The only thing that is certain is that competitors are not ignoring the Web. This technology if properly implemented will allow closer
communications with customers, with suppliers and even between employees in the company. In this millennium, information will be the most valuable commodity of most
companies, and the Web allows for information to move quickly in a format that is accessible to vast numbers of people. In turn, this information will allow businesses to move more
quickly and to save money. •
25.2.5 Other External Services
