ARQUITECTURAS CLIENTE/SERVIDOR SERVIDORES ORIENTADOS/ NO ORIENTADOS A CONEXIÓN SERVIDORES ORIENTADOS A CONEXIÓN Telnet HTTP FTP SMTP LDAP Kerberos CORBA RMI RPC NFS SERVIDORES NO ORIENTADOS A CONEXIÓN SNMP P2P RPC NFS DNS TELNET Servidores Orientados a Conexión TELNET (TELECOMMUNICATION NETWORK) TELNET es un protocolo estándar siendo su número STD de 8. Su status es recomendado. Se describe en el RFC 854 - Especificaciones del protocolo TELNET y RFC 855 - "TELNET Option Specifications". El protocolo TELNET proporciona una interfaz estandarizada, a través de la cual un programa de un host(el cliente de TELNET) puede acceder a los recursos de otro host (el servidor de TELNET) como si el cliente fuera una terminal local conectada al servidor. TELNET ES UN PROTOCOLO BASADO EN TRES IDEAS: El concepto de NVT(Network Virtual Terminal) (NVT). Una NVT es un dispositivo imaginario que posee una estructura básica común a una amplia gama de terminales reales. Cada host mapea las características de su propia terminal sobre las de su correspondiente NVT, y asume todos los demás hosts harán lo mismo. Una perspectiva simétrica de las terminales y los procesos. Negociación de las opciones de la terminal. El protocolo TELNET usa el principio de opciones negociadas, ya que muchos host pueden desear suministrar servicios adicionales, más allá de los disponibles en la NVT. Se pueden negociar diversas opciones FUNCIONAMIENTO TELNET NVT(NETWORK VIRTUAL TERMINAL) Cuenta con un monitor o "display" y un teclado. El teclado produce datos de salida, que se envían por la conexión TELNET. El monitor recibe los datos de entrada que llegan. Las características básicas de una NVT, a menos que sean modificadas por opciones establecidas de común acuerdo, son: Los datos se representan en código ASCII de 7 bits, transmitido en bytes de 8 bits. Es un dispositivo semi-duplex que opera en modo de buffer en línea. Proporciona una función de eco local. Todas estas opciones pueden ser negociadas por los dos hosts. Por ejemplo, se prefiere el eco local porque la carga de la red es inferior y el rendimiento superior pero existe la opción de usar el eco remoto, aunque no se le requiera a ningún host. NVT El servidor TELNET ―escucha‖ en el puerto 23 close: cerrar la conexión actual. display: mostrar los parámetros operativos. mode: trata de introducir los comandos línea a línea. open: conexión con un host especificado. quit: salir de telnet. send: transmisión de caracteres especiales. set: establecimiento de parámetros operativos. status: muestra la información de estado. ?: muestra información de ayuda. FTP Servidores Orientados a Conexión FTP FTP es un protocolo estándar con el STD 9. Su status es recomendado. Se describe en el RFC 959 - FTP("File Transfer Protocol"). La copia de archivos de una máquina a otra es una de las operaciones más frecuentes. La transferencia de datos entre cliente y servidor puede producirse en cualquier dirección. Para acceder a archivos remotos, el usuario debe identificarse al servidor. En este punto el servidor es responsable de autentificar al cliente antes de permitir la transferencia de archivos. DESCRIPCIÓN DE FTP FTP usa TCP como protocolo de transporte para proporcionar conexiones fiables entre los extremos. Se emplean dos conexiones: la primera es para el login y sigue el protocolo TELNET y la segunda es para gestionar la transferencia de datos. En ambos extremos del enlace, la aplicación FTP se construye con intérprete de protocolo(PI), un proceso de transferencia de datos, y una interfaz de usuario. La interfaz de usuario se comunica con el PI, que está a cargo del control de la conexión. Este intérprete de protocolo comunica la información necesaria a su propio sistema de archivos. En el otro extremo de la conexión, el PI, además de su función de responder al protocolo TELNET, inicia la conexión de datos. Durante la transferencia de archivos, los DTPs se ocupan de gestionar la transferencia de datos. Una vez que la operación del usuario se ha completado, el PI cierra la conexión de control. DIAGRAMA DE FUNCIONAMIENTO OPERACIONES DE FTP Al usar FTP, el usuario realizará alguna de las siguientes operaciones: Conexión a un host remoto Selección de un directorio Listado de archivos disponibles para una transferencia Especificación del modo de transferencia Copiar archivos de o a el host remoto Desconectar del host remoto CONEXIÓN A UN HOST REMOTO comandos: Open User Identifica al ID del usuario remoto Pass Selecciona el host remoto de inicia la sesión con el login Autentifica al usuario Site Envía información al host remoto utilizado para proporcionar servicios específicos para ese host ESPECIFICACIÓN DEL MODO DE TRANSFERENCIA La transferencia de datos entre sistemas diferentes suele requerir transformaciones de los datos como parte del proceso de transferencia. El usuario ha de decidir dos aspectos de la manipulación de los datos: La forma en qué se transferirán los bits. Las distintas representaciones de los datos en la arquitectura del sistema. Esto se controla por medio de dos subcomandos: Mode :Especifica si el archivo se ha de tratar como si tuviera estructura de registros o como un flujo de bytes. Block :Se respetan las separaciones lógicas entre registros. Stream: El archivo se trata como un flujo de bytes. Esta es la opción por defecto, y proporciona una transferencia más eficiente, pero puede que no produzca los resultados deseados cuando se trabaja con un archivos estructurados por registros. Type: Especifica el conjunto de caracteres usado para los datos. ASCII Indica que ambos host están basados en ASCII, o que si uno está basado en ASCII y el otro en EBCDIC, se debería realizar una traducción ASCIIEBCDIC. EBCDIC Indica que ambos host se basan en EBCDIC. Image Indica que los datos deben tratarse como bits contiguos empaquetados en bytes de 8 bits. Debido a que estos subcomandos no cubren todas las posibles diferencias entre sistemas, el subcomando SITE está disponible para lanzar comandos dependientes del sistema. COPIA DE ARCHIVOS Get (mget) Put (mput) Copia un archivo del host local al host remoto. Finalización de la sesión de transferencia Quit Copia un archivo del host remoto al host local. Desconecta del host remoto y cierra el FTP. Algunas implementaciones usan el subcomando BYE. Close Desconecta del host remoto pero deja al cliente FTP ejecutándose. Se puede lanzar un comando open para trabajar con otro host remoto FTP ANONYMOUS El FTP anonymous es un SERVICIO ESPECIAL que te permite, SIN TENER UN 'USERID' o CUENTA en un servidor, para poder acceder a su sistema de archivos. Esta es, de hecho, la manera mas cómoda (después de las páginas WEB) de permitir que todo el mundo tenga acceso a cierta información, sin que para ello el administrador de un sistema tenga que crear una cuenta para cada persona interesada en disponer de ella. Si una máquina posee servicio 'FTP anonymous' solamente con teclear la palabra "anonymous" anónimo en inglés - cuando dicha maquina pregunte por tu usuario, tendras acceso a ese sistema CÓDIGOS DE RESPUESTA Con el fin de gestionar estas operaciones, el cliente y el servidor mantienen un diálogo por medio de TELNET. El cliente lanza comandos, y el servidor contesta con códigos de respuesta. Las respuestas incluyen también comentarios para el usuario, pero el cliente usa sólo los códigos. Los códigos de respuesta tienen tres dígitos, siendo el primero el más significante. DETALLE PRIMER DÍGITO 1** Respuesta preliminar positiva. Se ha iniciado la acción requerida; se espera otra respuesta del server antes de seguir con una nueva orden. 2** Respuesta de finalización positiva. La acción requerida se ha completado satisfactoriamente. Se puede iniciar una nueva orden. 3** Respuesta intermedia positiva. La orden se ha aceptado, pero se está pendiente de recibir más información para completarla. El usuario debería enviar otra orden indicando esta información. Esta respuesta se utiliza en órdenes que deben ir en secuencia. 4** Respuesta de finalización negativa transitoria. La orden no se ha aceptado y la acción requerida no se ha llevado a cabo, pero la condición de error es temporal y se puede solicitar la acción de nuevo. 5** Respuesta de finalización negativa permanente. La orden no se ha aceptado y la acción requerida no ha tenido lugar. SEGUNDO DÍGITO, 6 OPCIONES *0* Sintáxis. Estas respuestas se refieren a errores de sintaxis, órdenes correctas sintácticamente pero que no encajan en ninguna otra categoría, órdenes no implementadas o superfluas. *1* Información. Estas son respuestas a solicitudes de información como STATUS o HELP. *2* Conexiones. Respuestas referidas a las conexiones de control y de datos. *3* Autenticación y cuenta. Respuestas para el proceso de entrada al sistema y procedimientos de cuenta. *4* Sin especificar aún. *5* Sistema de archivos. Estas respuestas indican el estado del sistema de archivos en el servidor según se realizan transferencias u otras acciones sobre el sistema de archivos. EJEMPLOS PWD TYPE A PASV LIST OPTS utf8 ON HTTP Servidores Orientados a Conexión INTRODUCCIÓN El protocolo estándar de comunicaciones entre servidores y clientes Web es el HTTP("Hypertext Transfer Protocol"), que es un borrador de estándar de Internet. RFC 2616 HTTP es un protocolo orientado a objetos genérico y sin estado. El IETF ha establecido un grupo de trabajo para mejorar su eficacia. Es un protocolo orientado a transacciones y sigue el esquema petición-respuesta entre un cliente y un servidor. Al cliente que efectúa la petición (generalemente un navegador o una araña web) se lo conoce como "user agent" (agente del usuario). UNA TRANSACCIÓN HTTP CONSISTE BÁSICAMENTE EN: Conexión Solicitud El envío por parte del cliente de un mensaje de solicitud al servidor. Respuesta El establecimiento de una conexión del cliente con el servidor. El puerto TCP/IP 80 es el puerto bien conocido, pero el URL puede especificar otros puertos no reservados. El envío por parte del servidor de una respuesta al cliente. Cierre El cierre de la conexión por parte del cliente y el servidor. HTML El lenguaje estándar de marcas para documentos Web es HTML ("Hypertext Markup Language"), que es un borrador de estándar de Internet y actualmente varios grupos de trabajo del IETF están trabajando en él. HTMP es una aplicación de SGML("Standard Generalized Markup Language"). Para crear un documento Web hay que usar las marcas HTML que constituyen la estructura lógica del documento, por ejemplo, cabeceras, listas y párrafos. ESTRUCTURA BÁSICA DE UN DOCUMENTO HMTL <HTML> <!– Inicio de document o--> <HEAD> <!-- Encabezado documento--> <TITLE>This is a Sample</TITLE> </HEAD> <!–Fin de la sección de encabezado--> <BODY> <!– Inicio del cuerpo de texto--> <!—Contenido --> </BODY> <!– Fin del cuerpo --> </HTML> <!– Fin del documento --> <html> <head> <title>Welcome to eMotherEarth.com</title> </head> <body> <h1>Welcome to eMotherEarth.com</h1> <p> <h3>Your 1-Stop Shop for Earth Products</h3> <p> Please enter your login info: <p> <form action="catalog" method="post"> <p>Name: <input type="text" name="username"> <p><input type="submit" name="Submit" value="Login"> </form> </body> </html> URL URL es un protocolo estándar de Internet y se puede encontrar en el RFC 1738. El contexto global para construir nuevos esquemas para codificar nombres y direcciones de objetos en Internet se describe en el RFC informacional 1630. Este RFC describe el término URI(Universal Resource Identifiers) como un modelo más teórico para diseñar estos esquemas. URI Los URIs que se refieren a una dirección objeto(dirección IP e información de la ruta de acceso)mapeados a un método de acceso conocido usando un protocolo de red existente como HTTP o FTP se conocen como URLs. Por lo tanto, un URL es una forma específica de un URI. En general, los URLs se escriben del modo siguiente: <scheme>:<scheme-specificpart> URL, ESQUEMAS DEFINIDOS Los siguientes esquemas estan incluidos en el RFC, y les pueden seguir otros en el futuro: ftp - "File Transfer protocol" http - "HyperText Transfer Protocol" gopher - El protocolo Gopher mailto - Dirección de Correo Electrónico news - "USENET news" nntp - "USENET news" usando acceso NNTP telnet - Sesiones interactivas wais - "Wide Area Information Servers" file - Nombres de archivos específicos de un host prospero - "Prospero Directory Service" • DESCRITOS EN EL RFC 1738 URL CON IP Mientras que la sintaxis para el resto del URL puede variar dependiendo del esquema seleccionado, los esquemas que implican el uso directo de un protocolo basado en IP usan una sintaxis común para la parte <scheme-specific data>, que comienza por "//" para indicar que sigue la sintaxis estándar de Internet: //<user>:<password>@<host>:<port>/<url-path> Las siguientes partes pueden ser excluidas "<user>:<password>@", ":<password>", ":<port>", y "/<url-path>" se pueden excluir. URL DE HTTP Según la definición anterior, el URL de HTTP tiene este aspecto: http://<host>:<port>/<path>?<searchpart> Donde: host port El número de puerto al que conectar. Si este parámetro se omite en un URL de HTTP, es 80 por defecto. path El nombre de dominio completo de un host o una dirección IP en formato decimal. Especifica un selector HTTP, una ruta a un documento HTML, por ejemplo. ? searchpart Registra de consulta("query string") indicada con "?". COMANDOS GET HEAD Envía datos al programa ubicado en la URL especificada PUT Solicita el encabezado del recurso ubicado en la URL especificada POST Solicita el recurso ubicado en la URL especificada Envía datos a la URL especificada DELETE Borra el recurso ubicado en la URL especificada FORMATO DE PETICIÓN Y RESPUESTA En el caso de que la petición se haga con el protocolo HTTP/1.0 o con el protocolo HTTP/1.1 la petición sigue el formato: Línea de petición *(Cabeceras) CRLF [Contenido] GET / HTTP/1.1 Host: www.wrox.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; enUS; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Connection: Keep-Alive POST POST / HTTP/1.1 Host: www.wrox.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Content-Type: application/x-www-form-urlencoded Content-Length: 40 Connection: Keep-Alive name=Professional%20Ajax&publisher=Wiley RESPUESTAS HTTP/1.1 200 OK Date: Sat, 31 Dec 2005 23:59:59 GMT Content-Type: text/html;charset=ISO-8859-1 Content-Length: 122 <html> <head> <title>Wrox Homepage</title> </head> <body> <!-- body goes here --> </body> </html> CABECERAS GENERALES Los campos de este tipo de cabeceras se aplican tanto a las peticiones como a las respuestas, pero no al contenido de los mensajes. Estas cabeceras son: Cache-Control, son directivas que se han de tener en cuenta a la hora de mantener el contenido en una caché. Connection, permite especificar opciones requeridas para una conexión. Date, representa la fecha y la hora a la que se creó el mensaje. Pragma, usado para incluir directivas de implementación. Transfer-Encoding, indica la codificación aplicada al contenido. Upgrade, permite al cliente especificar protocolos que soporta. Via, usado por pasarelas y proxies para indicar los pasos seguidos CABECERAS DE PETICIÓN Accept, indican el tipo de respuesta que acepta. Accept-Charset, indica los conjuntos de caracteres que acepta. Accept-Encoding, que tipo de codificación acepta. Accept-Language, tipo de lenguaje de la respuesta que se prefiere. Authorization, el agente de usuario quiere autentificarse con el servidor. From, contiene la dirección de correo que controla en agente de usuario. Host, especifica la máquina y el puerto del recurso pedido. If-Modified-Since, para el GET condicional. If-Match, para el GET condicional. If-None-Match, para el GET condicional. If-Range, para el GET condicional. If-Unmodified-Since, para el GET condicional. Max-Forwards, indica el máximo número de elementos por los que pasa. Proxy-Authorization, permite que el cliente se identifique a un proxy. Range, establece un rango de bytes del contenido. Referer, indica la dirección donde obtuvo la URI de la petición. User-Agent, información sobre el agente que genera la petición. CABECERAS DE RESPUESTA Age, estimación del tiempo transcurrido desde que se creó la respuesta. Location, se usa par a redirigir la petición a otra URI. Proxy-Authenticate, ante una respuesta con el código 407 (autentificación proxy requerida), indica el esquema de autentificación. Public, da la lista de métodos soportados por el servidor. Retry-After, ante un servicio no disponible da una fecha para volver a intentarlo. Server, información sobre el servidor que maneja las peticiones. Vary, indica que hay varias respuestas y el servidor ha escogido una. Warning, usada para aportar información adicional sobre el estado de la respuesta. WWW-Authenticate, indica el esquema de autentificación y los parámetros aplicables a la URI. CABECERAS DE ENTIDAD Allow, da los métodos soportados por el recurso designado por la URI. Content-Base, indica la URI base para resolver las URI relativas. Content-Encoding, indica una codificación adicional aplicada al contenido (a parte de la aplicada por el tipo). Content-Language, describe el idioma del contenido. Content-Length, indica el tamaño del contenido del mensaje. Content-Location, da información sobre la localización del recurso que da el contenido del mensaje. Content-MD5, es un resumen en formato MD5 (RFC 1864) para chequear la integridad del contenido. Content-Range, en un GET parcial, indica la posición del contenido. Content-Type, indica el tipo de contenido que es. Etag, define una marca para el contenido asociado. Expires, indica la fecha a partir de la cual la respuesta deja de ser válida. Last-Modified, indica la fecha de la última modificación. CÓDIGOS DE ESTADO El código de estado es un número de 3 dígitos que indica si la petición ha sido atendida satisfactoriamente o no, y en caso de no haber sido atendida, indica la causa. Los códigos se dividen en cinco clases definidas por el primer dígito del código de estado. Así tenemos: 1xx: Informativo. La petición se recibe y sigue el proceso. Esta familia de respuestas indican una respuesta provisional. Este tipo de respuesta está formada por la línea de estado y las cabeceras. Un servidor envía este tipo de respuesta en casos experimentales. 2xx: Éxito. La acción requerida por la petición ha sido recibida, entendida y aceptada. 3xx: Redirección. Para completar la petición se han de tomar más acciones. 4xx: Error del cliente. La petición no es sintácticamente correcta y no se puede llevar a cabo. 5xx: Error del servidor. El servidor falla al atender la petición que aparentemente es correcta. EJEMPLOS DE CÓDIGOS DE ESTADO 100, continuar. 101, cambio de protocolo. 200, éxito. 201, creado. 202, aceptado. 203, información no autoritativa. 204, sin contenido. 205, contenido reestablecido. 206, contenido parcial. 300, múltiples elecciones. 301, movido permanentemente. 302, movido temporalmente. 303, ver otros. 304, no modificado. 305, usar proxy. 400, petición errónea. 401, no autorizado. 402, pago requerido. 403, prohibido. 404, no encontrado. 405, método no permitido. 406, no se puede aceptar. 407, se requiere autentificación proxy. 408, límite de tiempo de la petición. 409, conflicto. 410, gone. 411, tamaño requerido. 412, falla una precondición. 413, contenido de la petición muy largo. 414, URI de la petición muy largo. 415, campo media type requerido. 500, error interno del servidor. 501, no implementado. 502, puerta de enlace errónea. 503, servicio no disponible. 504, tiempo límite de la puerta de enlace. 505, versión de protocolo HTTP no soportada. SERVIDORES HTTP Apache (Jakarta Project) IIS (Internet Information Server) GWS (Google Web Server) Cherokee EVOLUCIÓN EN HTTP Los primeros sitios web no eran sino colecciones de páginas web enlazadas entre ellas por el Lenguaje HTML. Hoy en día, los sitios web incluyen multimedia, aplicaciones de comercio electrónico, y otro tipo de sofisticadas aplicaciones basadas en Web como voz IP y banca online. Además de los avances en contenido, se han producido avances en las tecnologías de servidores web, como el desarrollo de servidores de aplicaciones, y tecnologías de creación dinámica de contenido, como las páginas JSP y las páginas ASP. ARQUITECTURA 2-CAPAS (CLIENTE/SERVIDOR) ARQUITECTURA DE N-CAPAS (2-CAPAS) Ideal para generación de contenido dinámico Servidores de aplicaciones (Java) utilizan servlets en Java REQUERIMIENTOS DE EJECUCIÓN DE LOS SERVLETS JAVA . Los Servlets de Java requieren algún conocimiento previo de Java y HTML Las aplicaciones web y las páginas web que requieran iniciación de servlets deben ejecutarse en servidores web con contenedores web integrados, como el servidor web WebSphere o un contenedor solitario de servlets como el Tomcat . Los Servlets también pueden ejecutarse en servidores de aplicación con contenedores web integrados como el Servidor BEA WebLogic . El API Servlet suele estar mayoritariamente integrado en el servidor/contenedor web. El contenedor/servidor logra esto último implementando la especificación Java Servlet 2.1 o 2.2 .Por ejemplo, Tomcat con la especificaciones de Servlet API 2.5 y JSP API 2.1 Una vez que el contenedor/servidor básico se ha bajado y configurado, el siguiente paso es entender la programación de servlets. El API Servlet tiene dos paquetes, el javax.servlet , que tiene clases y paquetes independientes de protocolos, y el javax.servlet.http , que es más específico para el protocolo HTTP. ESTRUCTURA DE SERVLET Y CICLO DE VIDA Todo servlet debe directa o indirectamente implementar la interfaz Servlet. Los siguientes métodos están declarados en el interfaz Servlet. public abstract void init (ServletConfig config) throws ServletException. El método init se usa para inicializar los parámetros proporcionados por el objeto ServletConfig. Se invoca sólo una vez, a menos que el servlet sea reiniciado si se destruye y se vuelve a cargar. El método init es el lugar en el que inicializar los parámetros de configuración como la conexión con una base de datos, la inicialización de archivos y otros valores de entorno. Ningún método del servlet puede ser invocado a no ser que el servlet esté inicializado mediante el uso del método init(). public abstract ServletConfig getServletConfig () Este método proporciona el objeto ServletConfig para la inicialización de los parámetros del servlet. Se pueden crear parámetros adicionales especificándolos en el archivo servlet.properties. Una vez que hayan sido especificados en este archivo, se puede acceder a ellos usando el objeto ServletConfig. public abstract void service (ServletRequest req, ServletResponse res) throws ServletException, IOException. El método service es el punto esencial del modelo petición respuesta del protocolo HTTP. Recibe una petición del cliente en forma de objeto ServletRequest. Los parámetros del cliente son pasados junto al objeto de petición (aunque existen otras formas de enviar parámetros desde el cliente al servlet, por ejemplo, usando cookies o por medio de una reescritura del URL). La respuesta resultante se envia al cliente usando el objeto ServletResponse. public abstract String getServletInfo() Este método se usa para la extracción de metadatos del servlet, como por ejemplo el autor, la versión del servlet, y otra información concerniente al copyright. El método tendrá que ser redefinido dentro del servlet para que devuelva esta información. public abstract void destroy () El método destroy se invoca para liberar todos los recursos solicitados como la base de datos, y otros recursos del servidor. También se encarga de la sincronización de cualquier hilo pendiente. Este método se llama una sola vez, automáticamente, como el método init. CLASES RELEVANTES EN SERVLETS La clase GenericServlet proporciona una implementación básica del interfaz Servlet. Para escribir un servlet especificamente para el protocolo HTTP, se usa la clase HTTPServlet, que extiende a Generic Servlet El ciclo de vida de los eventos para un servlet se especifica en el interfaz javax.servlet.Servlet. Todos los servlets siguen el modelo del ciclo de vida. El contenedor web tiene la responsabilidad de crear una instancia del servlet y de invocar al método init (1). Si un cliente ha enviado una petición al contenedor web, entonces, esa petición se pasa al método servicio del servlet (2), y se envia una respuesta de vuelta al contendor web (3). Finalmente, cuando el servlet haya finalizado su propósito, el contenedor web invoca al método destroy Además de los métodos que heredan de la clase GenericServlet, la clase HTTPServlet tiene métodos adicionales para cada uno de los métodos de respuesta HTTP tratados antes. doDelete (HttpServletRequest, HttpServletResponse) doGet (HttpServletRequest, HttpServletResponse) doOptions (HttpServletRequest, HttpServletResponse) doPost (HttpServletRequest, HttpServletResponse) doPut (HttpServletRequest, HttpServletResponse doTrace (HttpServletRequest, HttpServletResponse) Por ejemplo, la clase Servlet tiene que redefinir doGet o doPost (o ambos métodos, dependiendo de si los datos serán enviados por un GET o por métodos de petición POST HTTP). Estos métodos toman dos parámetros: un objeto HttpServletRequest y un objeto HttpServletResponse. Estos dos objetos dan acceso total a toda la información sobre la petición del cliente, y ayudan a controlar la salida enviada al cliente como respuesta a dicha petición. Los métodos doGet y doPost son invocados por el método service. El método service puede usarse directamente al redefinirlo. UN SERVLET SENCILLO Importar el paquete básico para crear un servlet, javax.servlet. Implementar el interfaz servlet. Definir el método init, que toma como parámetro un objeto ServletConfig para establecer las propiedades del servlet. Método principal service que toma como parámetros los objetos de petición y respuesta. Todo el procedimiento del servlet gira en torno a estos objetos. La petición del cliente va adjunta en el objeto de petición, y la respuesta del servlet se envía en el objeto de respuesta. Proporcionar una respuesta sencilla de escritura de una frase como salida html. Una vez que el servlet haya sido compilado, es necesario instalarlo en el contenedor web en su adecuada localización o en un directorio por defecto de servlets. ..\ACS_10-1\EjemploServlet.txt REFERENCIAS Allamaraju, S. et al. Professional Java Server Programming J2EE Edition. Wrox Press, Inc., 2000. BEA Systems. BEA WebLogic Server. http://www.oracle.com/bea/index.html The Jakarta Project. Jakarta Tomcat. http://jakarta.apache.org/tomcat Sun Microsystems. Interface javax.servlet.Servlet. http://java.sun.com/javaee/6/docs/api/ Sun Microsystems. Tutorial http://java.sun.com/javaee/5/docs/tutorial/doc/bnafd.html JSP http://www.programacion.com/java/tutorial/servlets_jsp/11/ JAVA WEB DEVELOPMENT