Embed Size (px)
DESCRIPTION
El Comienzo de la Creación en la Web
Citation preview
Introducción. 2
1.1 JAVA (EL GRAN PROTAGONISTA)2
2 Servidores de aplicaciones. 3
2.1 STANDARDS DE LOS SERVIDORES DE APLICACIONES.4
2.2 J2EE EL NUEVO STANDARD JAVA.5
2.2.1 ENTERPRISE JAVA BEANS (EJB).7
2.2.2 JAVA SERVER PAGES (JSP)10
2.2.3 JAVA NAMING AND DIRECTORY INTERFACE (JNDI)12
2.2.4 JAVA TRANSACTION API (JTA)15
2.2.5 JAVAIDL17
3 XML 25
3.1 JAVA API FOR XML PARSING (JAXP)26
4 Wireless Aplication Protocol (WAP) 27
4.1 WIRELESS MARKUP LANGUAGE (WML)27
4.2 WMLSCRIPT28
4.3 EL FUTURO DE WAP.30
5 General Packet Radio Service (GPRS) 31
6 Universal Mobile Telecommunication System (UMTS) 32
7 E-BUSSINESS 34
7.1 BUSINESS TO BUSINESS (B2B)34
7.2 BUSINESS TO CLIENT (B2C)35
7.3 BUSINESS TO EMPLOYEE (B2E)36
8 METODOLOGÍAS DESARROLLO. 37
8.1 OBJECT ORIENTED ANALISIS AND DESIGN (OOAD)37
8.2 UML37
8.2.1 DIAGRAMAS.38
8.2.2 DIAGRAMA DE CASOS DE USO.39
8.2.3 DIAGRAMA DE CLASES.41
8.2.4 DIAGRAMA DE SECUENCIA.45
NUEVAS TECNOLOGÍAS INTERNET.
1 Introducción.En este documento se pretende dar una visión de las tecnologías que dominan el mundo de Internet.
No se pretende dar una descripción detallada de todas las tecnologías existentes, pero se intenta ir mas allá de la mera enumeración de unas siglas y la explicación de sus significados.
También se dará una impresión de hacia donde se dirige internet y que evolución seguirá en los próximos meses.
El presente de Internet es la era PC. La mayoria de usuarios que acceden a Internet lo hacen desde un PC, portátil o no, y los contenidos, la filosofia y la estructura de Internet esta orientada hacia estos usuarios. La evolución tecnológica sufrida ha sido provocada por la necesidad de dar servicio a mas usuario, y de dotar a internet de contenidos Multimedia. Hace dos años nadie pensaba que un servidor debería ser capaz de servir 201 millones de paginas diariamente. Estas cifras son ahora comunes en los servidores mas conocidos, y los mas grandes las multiplican por 5. Esto quiere decir que existe la tecnología capaz de crear servidores de Internet de alto rendimiento.
En este apartado explicamos las tecnologias que se utilizan en los servidores de Internet. Podemos encontrar servidores WEB con paginas HTML, CGI, Servles, Paginas ASP, JSP, Servidores de aplicaciones con EJBs, etc...
1.1 JAVA (El gran protagonista)
Las tecnologías de desarrollo de Internet están dominadas casi totalmente por el lenguaje JAVA. Por lo que nos encontramos con muchos tipos de JAVA diferentes. En poco tiempo JAVA ha sufrido una diversificación mucho mas grande que la que ha sufrido el C++ en varios años. Es por esto que no se puede tomar a JAVA como un mero lenguaje generalista de desarrollo orientado a Internet. Sus diferentes utilidades han hecho evolucionar el lenguaje de tal manera que los programadores que estén acostumbrados a trabajar con JAVA en la parte cliente no sean capaces de realizar trabajos específicos para la parte servidor y viceversa.
2 Servidores de aplicaciones.Son los recién llegados, aunque ya hace unos años que existen no es hasta hace poco mas de un año que la estabilidad de sus versiones ha llegado a niveles aceptables. Son servidores de alto rendimiento que estan pensados para dar servicio a WEBS con grandes necesidades. Entre ellos nos encontramos a WEBS que tengan una gran necesidad transaccional, pocas visitas pero muchas operaciones, y WEBS con necesidad de servir un gran número de paginas.
Existen una gran variedad de servidores de aplicaciones, aquí se enumeran algunos:
Manufacturer Product(s)
Product Description,Special features (See Legend Key) EJB
Servlet API JSP
Allaire
JRun Server J2EE Server, JMS, Servlet-JSP Web Server
1.1 2.2 1.1
ATG Dynamo Application Server
J2EE Server, Servlet-JSP Web Server
1.0 2.2 1.1
BEA Systems
Weblogic Application ServerWeblogic Enterprise Server
J2EE Server, JMS, WAP/WML
2.0 2.2 1.1
Bluestone Total E-Server J2EE Server 1.0 2.2 1.1
IBM
WebSphere Application Server
J2EE Server, WAP/WML, JMS
1.0 2.1 1.0
Inprise Inprise Application Server
J2EE Server 1.1 2.1 1.0
Oracle
Oracle 8i iASOracle 8i
J2EE Server ORDBMS
1.0 2.2 1.1
Sun
iPlanet Application Server
J2EE Server, WAP/WML
1.12.2 1.1
Pero cuales son los servicios que nos ofrecen los servidores de aplicaciones. Entre los mas importantes se encuentran:
Servicios de seguridad. Los clientes se deben autentificar al servidor, y este es el responsable de darles acceso a sus diferentes componentes, como puede ser una base de datos. La mayoría de servidores (todos los de la lista anterior) disponen de un mecanismo para incorporar nuevos usuarios y grupos. El control de a que partes del servidor puede acceder un usuario se realiza mediante LDAP.
Mantenimiento de sesiones. En servidor provee de persistencia a los datos del usuario mediante objetos session que se almacenan en el server pero son propiedad exclusiva de un usuario. Elimina la necesida de que en nuestro código debamos diferenciar las peticiones de los diferentes usuarios, ya que es el server el responsable de devolverle los datos correctos a cada uno de ellos.
Balance de cargas. Permite a un grupo de servidores de aplicaciones trabajar como un cluster. Las cargas se balancean entre todos los servidores para no
cargar en exceso a ninguno de ellos y permitir escalar aplicaciones fácilmente. Si una de las maquinas falla las peticiones son redirigidas a las otras maquinas en funcionamiento. Algunos de los servidores también replican la información de usuario entre los diferentes servers disponibles para asegurar siempre la persistencia de la sesión.
Lógica de negocio. La lógica de negoció propia de cada aplicación esta realizada en componentes, que se deben realizar, pero que se les puede asignar mecanismos de seguridad, persistencia, transacción, y comportamientos multithread. Los componentes desarrollados se benefician del mantenimiento de sesiones y de los balanceos de carga de los servidores.
Generación de HTML. El server puede decodificar una dirección URL que le llegue, y mediante componentes de negocio y consultas a la base de datos generar el HTML o XML a enviar al browser cliente.
Acceso a datos. Los servidores proveen de objetos de acceso a las bases de datos que se encargan de realizar las conexiones, mantenerlas vivas, gestionar un pool, reconectarlas en caso de error, ahorrando mucho trabajo especifico de base de datos.
Manejo de transacciones. Se pueden crear transacciones que engloben a varios componentes o a uno de ellos, y es el server el responsable de realizar los rollback o commit necesarios.
Pool de threads. El server es el responsable de tener un número de thread y de instancias de objetos creadas previamente.
2.1 Standards de los servidores de aplicaciones.
Los servidores de aplicaciones se basan en dar soporte a unos standards de la industria que marcan como deben ser sus componentes, y que facilitan un desarrollo parecido en diferentes servidores de aplicaciones. Aunque no todos ellos soportan los mismos standards y alguno de ellos crean especificaciones propias, si que existe una base comun. Esta es:
JSP JTA JavaIDL JavaMail JNDI EJB JMS Servlets JDBC SSL HTTP
Muchos de estos standars se engloban dentro del J2EE, que esta basado en el Java 2 Standard Edition.
2.2 J2EE El nuevo standard JAVA.
J2EE es una especificación de un standard para servidores de aplicaciones. Comprende diferentes tecnologías y especifica como deben trabajar juntas. Todos los servidores de aplicaciones que quieran ser compatibles J2EE deben pasar un test de compatibilidad, que garantiza la correcta implementación de las tecnologías en el servidor.
Las partes principales de entorno de explotación de un servidor de aplicaciones compatible J2EE son:
Componentes. Existen cuatro clases de componentes que un servidor compatible J2EE debe soportar.
o Aplicaciones clientes. Aplicaciones corrientes, escritas en JAVA que acceden a los servicios del servidor vía RMI.
o Applets.o Servlets y JSP.o Enterprise Jaba Beans (EJB). Estos componentes se ejecutan en el
servidor, dentro de un container. Containers. Son los encargados de dar servicios a los componentes que corren en
el servidor de aplicaciones. Existen diferentes containers que agrupan a los componentes pos funcionalidades. Los mas importantes son: el web container que contiene servlets y Java Server Pages y el EJB container.
Resource Manager Driver. Se encarga de proveer a los componentes de conectivad con recursos externos al servidor de aplicaciones. Estas conexiones externas pueden realizarse por JavaMail, Java Dabatase Connectivity (JDBC) y JavaMail.
Base de datos. El acceso a las bases de datos se debe realizar con JDBC, aunque la mayoria de servidores de aplicaciones dan accesos alternativos a sus bases de datos, y debes ser accesibles a todos los componentes, excepto los applets.
La especificación J2EE incluye unos servicios que deben ser implemetados obligatoriamente por los servidores de aplicaciones J2EE compatibles. Estos son:
HTTP. Los componentes, como servlets y Java Server Pages, del servidor deben ser accesibles vía http.
HTTPS. También debe soportar acceso mediante Secure Socket Layer.
Java Transaction Api (JTA). Da soporte a transacciones.
JavaIDL. Para la conexión con objetos CORBA mediante JavaIDL ORB.
JDBC
Java Naming Directory Interface (JNDI).
Java Mail. Provee de un API independiente para realizar aplicaciones con acceso a mail.
Estos son los servicios obligatorios, pero hay otros que son recomendables, y que no todos los servidores de aplicaciones compatibles con J2EE los cumplen.
Remote Method Invocation over Internet Inter-Orb Protocol (RMI-IIOP). Permite el paso de objetos, tanto de referencia como de valor, remotamente.
Java Message Services (JMS). Provee de un API standard para el manejo de colas y de comunicación publish and suscribe.
2.2.1 Enterprise Java Beans (EJB).
Los EJB son como un middelware entre la parte cliente y la parte servidor de Internet. En la parte cliente tenemos multitud de clientes diferentes, PDAs, PCs, Moviles, NCs, y en la parte servidora existe aun una mayor oferta. Multitud de constructores de software nos ofrecen sus productos para que utilicemos, existen servidores en diferentes sistemas operativos, y las bases de datos pueden estar en equipos tan diferentes como un PC o un HOST 3270 de IBM. Los EJB nos dan la posibilidad de crear la lógica de negocio como componentes reusables, y poderlos usar en cualquier tipo de servidor que soporte la especificación EJB.
El programar EJBs en lugar de aplicaciones enteras en JAVA permite ahorrarse las preocupaciones de seguridad, pool de conexiones, gestión transaccional, control de estado, persistencia o multithreading. Al desarrollar EJB el esfuerzo, y una vez superada la curva de aprendizaje inicial, el esfuerzo se centra en programar la lógica de negocio.
Teóricamente, en la practica existen unas pequeñas diferencias, escoger un servidor u otro no es una decisión critica, ya que nuestros EJBs deben funcionar en todos. No hace mucho para trabajar con los servidores WEB se debía programar en APIs propietarios como NSAPI o ISAPI.
Como veremos mas adelante el comportamiento de un EJB no se define tan solo en la parte de desarrollo. Cualquier EJB puede variar el comportamiento transaccional, su persistencia, seguridad. Es mas un mismo EJB puede comportarse de maneras diferentes en el mismo servidor dependiendo de la aplicación a la que este dando servicio.
2.2.1.1 Ciclo de desarrollo
El ciclo de desarrollo de un EJB es un poco mas largo que el de una aplicación normal, y deben seguirse todos los pasos. Vamos a ver un ejemplo altamente sencillo de un EJB, llamado ObtenPepe que devolvera el string “pepe”.
Desarrollo.
Debemos desarrollar tres partes, la clase en cuestión, su interfaz HOME y la interfaz remota.
La Clase, contiene la lógica de negocio.
import javax.ejb.*;
import java.rmi.*;
public class ObtenPepeBeane implements SessionBean {
SessionContext sessionContext;
public void ejbCreate() throws CreateException, RemoteException {}
public void setSessionContext(SessionContext sc)
throws RemoteException {
sessionContext = sc;
}
public String obtenerPepe() {
String Nombre = “Pepe”;
return Nombre;
}
}
Su interfaz HOME.
import javax.ejb.*;
import java.rmi.*;
public interface ObtenPepeHome extends EJBHome {
public BuscaPersonas create()
throws CreateException, RemoteException;
}
Su interfaz remota.
import javax.ejb.*;
import java.rmi.*;
public interface ObtenPepe extends EJBObject {
public String obtenerPepe(int DNI) throws RemoteException;
}
Despliegue o deployment
Se usa formato XML, y ya existen unos .dtd standard a seguir. Se definen la propiedades del EJB, tales como nombre, tipo(Session o Entity), clases, campos. Se configura su comportamiento transaccional, y sus parámetros de seguridad. Los
servidores de aplicaciones disponen de herramientas que nos crean los ficheros de deployment de nuestros EJB.
2.2.1.2 Arquitectura de EJB
Un EJB corre dentro de un container o contenedor en un servidor de aplicaciones. El contenedor lo facilita el fabricante del servidor de aplicaciones y es el interface entre el EJB desarrollado y el servidor escogido. Los contenedores proporcionan independencia al EJB del servidor en el que corre.
2.2.1.3 Tipos de EJB.
Tenemos dos tipos diferentes de EJBs que se diferencian principalmente por su persistencia.
Entity beans. Se pueden definir como representaciones de datos del servidor. No estan ligados a ningún cliente, la instancia pertenece al servidor, y se normalmente se utilizan para englobar el acceso a la base de datos del servidor. Son responsables de mantener su persistencia y de estar sincronizados con los datos a los que representan, aunque sufran modificaciones desde fuera del servidor. La sincronización de las diferentes llamadas la realiza el servidor, que puede crear diferentes instancias si lo cree necesario para la carga de peticiones del bean.
Session Beans. Es una representación del cliente en el servidor. Una instancia de session bean siempre pertenece a un solo cliente. Un buen ejemplo de session bean sería uno que representase la cuenta de un cliente. Solo se le permite el acceso al cliente que lo ha creado, y el servidor es el responsable de mantener los datos entre las diferentes llamadas del cliente. Disponemos de dos tipos diferentes de session bean.
o Stateless. Este tipo no guarda su estado entre las diferentes peticiones del cliente. Se reutilizan las instancias para dar servicio a diferentes clientes, al no guardar información de cliente.
o StateFul. Guardan información de estado del cliente, sus instancias no son reutilizadas entre llamadas de diferentes clientes. Aunque se guarden los datos entre llamadas del mismo cliente, el bean no guarda los datos ante una posible caída del servidor.
2.2.1.4 Para que usar EJB.
Los EJB se usaran en todos los desarrollos de un proyecto internet medio grande, es decir todos aquellos que deban corren en un servidor de aplicaciones. Cualquier proyecto Internet que tenga una parte importante de desarrollo servidor es un candidato a ser desarrollado con J2EE en un servidor de aplicaciones. La otras alternativas como los Servlets o CGIs se estan quedando desfasadas, y llevan un tiempo mayor de desarrollo si se quiere dar soporte a las características ofrecidas por los servidores de aplicaciones. Los desarrollos de EJBs se benefician de crear porciones de código reutilizables en diversos proyectos.
2.2.2 Java server Pages (JSP)
JSP es una especificación que esta soportada por muchos servidores WEB y que debe estar soportada por todos los servidores de aplicaciones al formar parte de J2EE.
Es la combinación de un lenguaje de marcas, como puede ser HTML, DHTML o XML con trozos de código en JAVA que producen hojas dinámicas, es decir, las hojas acaban de construirse con la ayuda del código java que contienen.
Cuando un cliente pide una pagina al servidor web este la envía al servlet responsable de su traducción y envía el resultado al cliente.
La hojas JSP se ejecutan en el servidor, no en el cliente, por lo que no es posible realizar validaciones de cliente con código JSP.
Para los que conozcan la tecnología ASP de Microsoft las JSP son muy parecidas, pero dan acceso a toda la potencia de J2EE, además de ser mas abiertas, se pueden ejecutar en entornos no Microsoft.
2.2.2.1 Arquitectura de una pagina JSP.
Una pagina JSP esta formada de varios elementos.
Directivas. Proveen de la información global que afecta a toda la pagina. Su sintaxis es <%@ directiva { atributo = “valor” } %>. Existen diferentes directivas, cada una con sus diferentes atributos. Con esto indicamos el lenguaje de script de la pagina, clases a importar, indicar si puede acceder a los datos de la sesión, su tratamiento de errores, etc...
Declaraciones. Se declaran las variables y métodos que se van a utilizar en toda la pagina. Su sintaxis es <%! Declaración >.
Scriplets. Es cualquier bloque de código java que este comprendido entre <% y %>. El código java de los scriplets puede acceder a cualquier variable o bean declarada. Así como a los objetos del HOST, como los EJBs.
Expresiones. Es cualquier bloque de código java comprendido entre <%= y %>. El código es ejecutado, y su resultado se muestra en la hoja resultante.
Ejemplo de página JSP.
<HTML>
<HEAD>
<TITLE>
Pagina ASP
</TITLE>
</HEAD>
</BODY>
<!--Comentario: información global de la pagina -->
<%@page languaje = “java” %>
<--!Comentario: declaración de la variable-->
<%! Int max = 2; %>
<!— Comentario: Scriplet -->
<%
for (int I=0; I < max; I++)
{ %>
<BR>
Contador I = <%=I %>
<% } %>
</BODY>
</HTML>
2.2.2.2 Para que usar JSP.
Cualquier aplicación Internet que presente hojas dinámicas, en respuesta de las entradas del usuario o de los datos almacenados en el servidor es susceptible de realizarse con JSP. Aunque JSP nos permita poner código de acceso a la base de datos, y lógica de negocio en la página es importante no cargar las hojas de demasiada inteligencia y de utilizar objetos del servidor para realizar estas tareas. Una proyecto que almacene toda su lógica en las páginas JSP será un proyecto difícil de mantener. Asi que las JSP debe usarse con cuidado, y para lo que estan pensadas. Permitir el acceso a los objetos del servidor y modificar los datos y la estructura visual de la pagina.
2.2.3 Java Naming And Directory Interface (JNDI)
Es una extensión de Java que provee de un interface standard y unificado a los diferentes APIS de gestión de directorios.
Un directorio es una especio de base de datos que provee de un acceso rapido y ordenado a los datos que almacena. Cada sistema operativo dispone de su propio API de acceso JNDI engloba LDAP y NIS, los dos mas usados, y da las herramientas necesarias para crear las interfaces con otros no soportados.
2.2.3.1 Estructura
El cliente, una aplicación, realiza la petición a JNDI, este la traslada al servicio de directorios de cada sistema, que realiza las peticiones de bajo nivel y accede a los datos almacenados.
JNDI se conecta a un servicio LDAP, por lo que se debe tener un servidor LDAP instalado y corriendo.
Los pasos a seguir para empezar a usar el servicio LDAP a través de JNDI son:
Conectarse al servicio LDAP
Identificarse
Realizar las operaciones pertinentes.
Desconectarse.
Ejemplo de conexión JNDI con LDAP.
1. La conexión:
Debemos obtener una referencia a un objelto que implemente el interface DirContext. Normalmente se usa una instancia de la clase InitialDirContext, que en su constructor acepta como parámetro una hastable que contenga los datos necesarios para realizar la conexión.
//Creamos la hastable en la que almacenaremos la información necesaria para la //conexión
HashTable EntornoLDAP = new HashTable();
//Indica la clase a utilizar.
EntornoLDAP.put(Context. INITIAL_CONTEXT_FACTORY, “com.sun.jndi.LdapCtxFactory”);
//Indica donde puede encontrar el servidor de LDAP.
EntornoLDAP.put(Context.PROVIDER_URL, “ldap://localhost:389”);
//Pasamos la hash y obtenemos la referencia del objeto que implementa DirContext
DirContext contextoLDAP = net InitialDirContext(EntornoLDAP);
2.Autentificación.
Con la conexión realizada anteriormente nos conectaríamos al servicio como el usuario anonymus. Para pasar el usuario debemos llenar las claves Context.SECURITY_AUTHENTICATION, Context.SECURITY_PRINCIPAL y Context.SECURITY_CREDENTIALS.
//Creamos la hastable en la que almacenaremos la información necesaria para la //conexión
HashTable EntornoLDAP = new HashTable();
//Indica la clase a utilizar.
EntornoLDAP.put(Context. INITIAL_CONTEXT_FACTORY, “com.sun.jndi.LdapCtxFactory”);
//Indica donde puede encontrar el servidor de LDAP.
EntornoLDAP.put(Context.PROVIDER_URL, “ldap://localhost:389”);
//Indicamos la identificación.
EntornoLDAP.put(Context.SECURITY_AUTHENTICATION, “simple”);
EntornoLDAP.put(Context. SECURITY_PRINCIPAL, “cn=directory manager”);
EntornoLDAP.put(Context.SECURITY_CREDENTIALS, “pass”);
//Pasamos la hash y obtenemos la referencia del objeto que implementa DirContext
DirContext contextoLDAP = net InitialDirContext(EntornoLDAP);
2.2.3.2 Por que JNDI
En un entorno de sistemas distribuidos orientado a objetos, los clientes deben disponer de un mecanismo que les permita localizar e identificar objetos de modo que los clientes, los objetos y los recursos parezcan estar en la misma máquina. Un servicio de denominación proporciona este mecanismo. En el entorno de servidor EJB, se utiliza
JNDI para enmascarar el servicio de denominación real y proporcionar una interfaz común para el servicio de denominación.
JNDI ofrece las funciones de directorios y de denominación para las aplicaciones de Java, pero la API es independiente de cualquier implementación específica de un servicio de directorios y de denominación. Esta independencia de implementación garantiza que se puedan utilizar servicios de directorios y de denominación diferentes accediendo a ellos a través de la API JNDI. Por consiguiente, las aplicaciones de Java pueden utilizar numerosos servicios de directorios y de denominación existentes como, por ejemplo, LDAP (Lightweight Directory Access Protocol), DNS (Servicio de denominación de dominios) o CDS (Servicio de directorio de célula) de DCE.
JNDI se ha diseñado para aplicaciones de Java utilizando el modelo de objeto de Java. Usando JNDI, las aplicaciones de Java pueden almacenar y recuperar objetos denominados de cualquier tipo de objeto Java. JNDI también proporciona métodos para ejecutar operaciones estándar de directorios como, por ejemplo, asociar atributos con objetos y buscar objetos utilizando sus atributos.
En el entorno de servidor EJB, se utiliza el descriptor de despliegue para especificar el nombre JNDI para un enterprise bean. El servidor EJB registra los nombres con JNDI al arrancarlo.
2.2.4 Java Transaction API (JTA)
Es un API que nos permite realizar transacciones independientemente del sistema al que nos estemos referenciando. Esta altamente ligado a J2EE y en particular a EJB , de tal manera que pierde su sentido usarlo fuera de este entorno.
Por lo general, resulta práctico diseñar los enterprise beans de modo que toda la gestión de transacciones se maneje a nivel del Enterprise Bean aunque, en una aplicación distribuida estricta de tres capas, no siempre es posible o incluso aconsejable. Sin embargo, puesto que la capa central de una aplicación EJB puede incluir dos subcomponentes--beans de sesión y beans de entidad--resulta mucho más fácil diseñar la gestión transaccional completamente en la capa de servidor de la aplicación. Por supuesto, la capa del gestor de recursos también se debe haber diseñado para ofrecer soporte para las transacciones.
No obstante, se puede programar un cliente EJB (que no sea un enterprise bean) para participar en transacciones para estas situaciones particulares que lo requieren. Para participar en una transacción, el cliente EJB debe realizar lo siguiente:
Obtener una referencia para la interfaz javax.transaction.UserTransaction utilizando JNDI tal como se ha definido en la Interfaz de programación JTA (Java Transaction Application Programming Interface).
Utilizar la referencia de objeto para invocar cualquiera de los métodos siguientes:
begin--Inicia una transacción. Este método no toma ningún argumento y devuelve un valor de anulación.
commit--Intenta comprometer una transacción; dando por supuesto que no hay nada que retrotraiga la transacción, la conclusión satisfactoria de este método compromete de transacción. Este método no toma ningún argumento y devuelve un valor de anulación.
getStatus--Devuelve el estado de la transacción a la que se hace referencia. Este método no toma ningún argumento y devuelve int; si no hay ninguna transacción asociada a la referencia, se devuelve STATUS_NO_TRANSACTION. Los valores de retorno válidos para este método son los siguientes:
STATUS_ACTIVE--Indica que el proceso de transacción continúa.
STATUS_COMMITTED--Indica que se ha comprometido una transacción y que sus efectos se han convertido en permanentes.
STATUS_COMMITTING--Indica que una transacción está en proceso de compromiso (es decir, se ha iniciado el compromiso de la transacción, pero aún no ha finalizado el proceso).
STATUS_MARKED_ROLLBACK--Indica que se ha marcado una transacción para retrotracción.
STATUS_NO_TRANSACTION--Indica que en el contexto de transacción actual no existe ninguna transacción.
STATUS_PREPARED--Indica que se ha preparado una transacción, pero no ha finalizado.
STATUS_PREPARING--Indica que una transacción está en proceso de preparación (es decir, se ha iniciado la preparación de la transacción, pero aún no ha finalizado el proceso).
STATUS_ROLLEDBACK--Indica que se ha retrotraído una transacción.
STATUS_ROLLING_BACK--Indica que una transacción está en proceso de retrotracción (es decir, se ha iniciado la retrotracción de la transacción, pero aún no ha finalizado el proceso).
STATUS_UNKNOWN--Indica que el estado de una transacción es desconocido.
rollback--Retrotrae la transacción a la que se hace referencia. Este método no toma ningún argumento y devuelve un valor de anulación.
setRollbackOnly--Especifica que el único resultado posible de la transacción es la retrotracción. Este método no toma ningún argumento y devuelve un valor de anulación.
setTransactionTimeout--Establece el tiempo de espera (en segundos) asociado a la transacción. Si algún participante de la transacción no ha establecido específicamente este valor, se utiliza un valor de tiempo de espera por omisión. Este método toma un número de segundos (como el tipo int) y devuelve un valor de anulación.
2.2.5 JavaIDL
Es una tecnología para objetos distribuidos, objetos que interactúan entre ellos, que residen en diferentes plataformas a través de la red. Es una tecnología similar a RMI, pero JavaIDL permite la interacción con objeltos escritos en otros lenguajes como C o C++.
La interacción con objetos escritos en diferentes lenguajes es posible gracias a que JavaIDL se basa en la tecnología CORBA, lenguaje de definición de objetos que permite que se interroguen entre ellos gracias a IDL Interface Definition Language.
Para soportar la interacción entre objetos en diferentes programas Java IDL provee de un ORB (Object Request Broker). Un ORB es una librería que permite la comunicación a bajo nivel entre las aplicaciones que siguen Java IDL y la especificación CORBA. Nosotros no debemos preocuparnos ni de CORBA ni de ORB, JavaIDL nos aísla de los problemas de comunicación de bajo nivel.
Antes de empezar a trabajar con JavaIDL necesitamos el compilador idltojava, que nos permite pasar los interfaces que realicemos de IDL a JAVA.
Los pasos a seguir para crear una comunicación JavaIDL son los siguientes:
Definir el interface IDL. Definiremos el interface para el objeto usando IDL ya que el compilador idltojava genera el código java y todos los ficheros necesarios automáticamente.
Compilar el interface. Al ejecutar el idltojava se generan las clases java y las clases de stub necesarias para comunicarse con el ORB.
Implementar el servidor. Usaremos el esqueleto generado por idltojava para insertar el código necesario de nuestro servidor.
Implementar el cliente. Usaremos el stube generado por el idltojava como base de la aplicación cliente. El código contiene las llamadas a el ORB, y para buscar el servidor.
Ejecutar las aplicaciones. Ejecutar el servidor com un servicioy ya podemos lanzar el cliente.
Ejemplo HelloWorld.
1.Creación del interface.
Crearemos un fichero llamado Hello.idl con el siguiente contenido.
module HelloApp {
interface Hello
{
string sayHello();
};
};
este fichero lo debemos compilar con el idltojava y obtendremos cinco ficheros, entre ellos Hello.java con el siguiente contenido:
/* Hello.java as generated by idltojava */
package HelloApp;
public interface Hello
extends org.omg.CORBA.Object {
String sayHello();
}
Aqui podemos ver que la conversión de IDL a JAVA. El module HelloApp se ha convertido en el package HelloApp. El interface Hello en public interface Hello.
Los otros cuatro ficheros generados por idltojava son:
HelloImplBase.java: Clase abastracyta, es el esqueleto que provee de la funcionalidad básica de CORBA para el servidor.
HelloStub.java: Provee de la funcionalidad de CORBA para el cliente.
This class is the client stub, providing CORBA functionality for the client. It implements the Hello.java interface.
HelloHelper.java: Clase final que provee de funcionalidad auxiliar para realizar el paso de objetos CORBA a objetos propios.
HelloHolder.java: Clase final Provee de las operaciones para pasar parámetros con CORBA.
2.Creación del servidor.
Crearemos el fichero HelloServer.java con el siguiente contenido.
// Importamos el package creado por idltojava
import HelloApp.*;
//Importamos las clases necesarias de CORBA
import org.omg.CosNaming.*;
import org.omg.CosNaming.NamingContextPackage.*;
import org.omg.CORBA.*;
//Clase principal
public class HelloServer
{
public static void main(String args[])
{
try
{
//Iniciamos el ORB.
ORB orb = ORB.init(args, null);
//Creamos un servicio para la clase. Y lo registramos en ORB
HelloServant helloRef = new HelloServant();
orb.connect(helloRef);
// Recuperamos el contexto
omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");
NamingContext ncRef = NamingContextHelper.narrow(objRef);
// Enlazamos el objeto con el servicio
NameComponent nc = new NameComponent("Hello", "");
NameComponent path[] = {nc};
ncRef.rebind(path, helloRef);
// Esperamos las invocaciones de los clientes
java.lang.Object sync = new java.lang.Object();
synchronized(sync)
{
sync.wait();
}
}
catch(Exception e)
{
System.err.println("ERROR: " + e);
e.printStackTrace(System.out);
}
}
}
//Clase servant utilizada para orb.Connect()
class HelloServant extends _HelloImplBase
{
public String sayHello()
{
return "\nHello world!!\n";
}
}
3.Creación del cliente.
import HelloApp.*; // El package creado por idltojava
//Las clases necesarias de CORBA
import org.omg.CosNaming.*;
import org.omg.CORBA.*;
public class HelloClient
{
public static void main(String args[])
{
try{
// Inicializamos ORB
ORB orb = ORB.init(args, null);
// Cojemos el servicio.
org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService");
NamingContext ncRef = NamingContextHelper.narrow(objRef);
// Buscamos el objeto registrado por el servidor.
NameComponent nc = new NameComponent("Hello", "");
NameComponent path[] = {nc};
Hello helloRef = HelloHelper.narrow(ncRef.resolve(path));
// Llamamos al objeto y mostramos el resultado.
String hello = helloRef.sayHello();
System.out.println(hello);
} catch(Exception e) {
System.out.println("ERROR : " + e);
e.printStackTrace(System.out);
}
}
}
4.Realizar la prueba.
Lo primero es iniciar el servidor el servidor tnameserver, indicándole el puerto en el que queremos que corra.
tnameserv –ORBInitialPort 1024
Despues debemos iniciar el servicio creado, en este caso HelloServer, le debemos indicar en que servidor esta corriendo el sevidor de IDL a no ser que sea el mismo en el que arrancamos el nuestro.
java HelloServer -ORBInitialPort 1024
Solo queda ejecutar el cliente al que le debemos indicar el nombre del servidor en el que esta corriendo el servicio IDL, y el puerto donde debe buscar al servicio.
Java HelloClient -ORBInitialPort 1024
2.2.5.1.1 Para que usar JavaIDL.
JavaIDL esta basado en un standard que permite invocar a objetos escritos en lenguajes diferentes a JAVA. I esta es su principal funcionalidad, el llamar a objetos JAV puede realizarse con RMI, que ademas permite utilizarlos por referencia o por valor. JavaIDL siempre trabaja por referencia, lo que hace el trafico más ligero, pero también tiene limitaciones.
3 XMLXML es un lenguaje de marcas, similar a HTML. Para entender un poco el concepto de XML no debemos partir de la idea de que es una especie de HTML mejorado, si no de la idea contraria. HTML es un XML con un DTD definido.
Para entender esta segunda idea debemos saber que XML es un lenguaje de marcas, que permite definir estas marcas mediante ficheros DTD. Un fichero XML no puede entenderse sin su fichero DTD correspondiente, por eso podemos plantearnos que HTML es un XML con sus marcas ya definidas. El gran problema de HTM es que por muchas mejoras que han ido apareciendo siempre nos basamos en unas marcas ya existentes que no pueden variarse. Con XML no tenemos esta limitación.
El problema de definirse las marcas propias es producir ficheros ML que no puedan ser entendidos fuera de nuestro entorno, por esta razón existen una serie de ficheros DTD standards que responden a diferentes necesidades y a diferentes entornos sectoriales.
Vamos a ver un fichero de XML que contiene los datos de dos empleados de una organización, y su dtd correspondiente.
Fichero XML:
<?xml versión=”1.0”!>
<!DOCTYPE departamento SYSTEM “departamento.dtd”>
<departamento>
<empleado id=“020”>
<nombre>Juan Garcia</nombre>
<puesto>Director Contenidos</puesto>
</empleado>
<empleado id=”010”>
<nombre>Jordi Velasonat</nombre>
<puesto>Responsable compras</nombre>
</empleado>
</departamento>
El fichero DTD tendría el siguiente formato:
<!ELEMENT departamento (empleado)*>
<!ELEMENT empleado (nombre, puesto)>
<!ATTLIST empleado id CDATA #REQUIRED>
<!ELEMENT nombre (#PCDATA)>
<!ELEMENT puesto (#PCDATA)>
Como podemos ver los dos ficheros son de fácil interpretación. En el DTD definimos la estructura de los elementos. Un departamento puede tener empleados, un empleado puede tener un nombre y un puesto. También definimos como obligatorio de marca empleado el parámetro id.
La gran ventaja de XML es que consigue unos formatos de intercambio de documento fácilmente mantenibles, ampliables y de fácil compresión. Podemos intercambiar los datos con ficheros de texto planos pero se adaptan mucho peor a las modificaciones y son mucho menos flexibles, y mas crípticos.
3.1 Java API for XML Parsing (JAXP)
Es un API nuevo de J2EE, implementado en la versión 1.3 del SDK. Permite el acceso facil a ficheros XML, modificar su contenido, interpretarlos, crearlos. Accede al fichero dtd para entender el fichero xml, y poder interrogarlo para recuperar los valores almacenados en el. JAXP engloba el api SAX, creado para la interrogación de ficheros XML en diferentes lenguajes.
Cualquier clase que queramos crear debe importar los siguientes packages:
import javax.xml.parsers.*;
import org.xml.sax.*;
import org.xml.sax.helpers.*;
Y heredar de la clase HandlerBase. Este interface define los métodos a implementar necesarios. El mas importante de ellos es StartElement(String name, AttributeList amap). Este Metodo es llamado por cada elemento de la hoja XML y recibe en amap una lista de los atributos del elemento. Los métodos son llamados automáticamente al crear una instancia de nuestra clase.
4 Wireless Aplication Protocol (WAP)Como indica su nombre WAP es protocolo de comunicaciones entre aplicaciones, sin hilos. Aunque existe desde hace bastantes años, y se ha utilizado para multitud de fines, es ahora con su llegada al mundo de la telefonía móvil cuando ha conseguido una repercusión importante. Aunque es un protocolo generalista que facilita la conexión de todo tipo de dispositivos a redes sin cables. Engloba las capas OSI de transporte y sesión y también facilita de un interface para diferentes tipos de representación. Soporta tanto representaciones gráficas como de texto, para adaptarse a la mayoría de pantallas de dispositivos.
Como podemos ver en el grafico las peticiones realizadas por el terminal, que debe disponer de un navegador WAP, son enviadas a una pasarela que realiza la decodificación según sea el caso y los reenvía hacia el servidor. Este servidor es un servidor WEB normal, que en el caso de la figura contiene CGI, pero que puede estar formado por servlets o un servidor de aplicaciones. El servidor recoge la petición y devuelve los datos a la pasarela que los codifica y los envía al terminal. El proceso en detalle de una petición es el siguiente:
1. El usuario lanza una petición a una URL. 2. El terminal envia una petición para la URL especificada a la pasarela usando el
protocolo WAP. 3. La pasarela crea una petición HTTP convencional para la URL y la envia al
servidor.4. El servidor procesa la petición. Que puede referirse a una página un CGI o
cualquier componente del servidor. 5. El servidor devuelve el código WML. 6. La pasarela verifica que el código sea correcto, elimina las cabeceras http y
codifica el resultado. Crea la respuesta WAP y la envía al terminal cliente.7. El terminal recibe la respuesta WAP. Interpreta el código WML llegado.
Para realizar aplicaciones en WAP disponemos del lenguaje WML y de WMLScript.
4.1 Wireless Markup Language (Wml)
Es un lenguaje de descripción de páginas que indica como se debe presentar el contenido WAP al usuario. Con WML se puede mostrar información, recuperar entradas del usuario y especificar el comportamiento del navegador cliente ante las entradas del usuario.
WML es un lenguaje de marcas, como HTML, pero basado en XML, utiliza un DTD realizado por WAPFORUM. El HTML esta basado en una navegación entre paginas, y el WML en una navegación entre cartas, que como veremos es muy parecida.
La estructura mínima de un WML es la siguiente:
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<wml>
<card id=”Uno” title=”Primera”>
<p>
Hola mundo
</p>
</card>
</wml>
Como podemos ver la estructura es muy parecida a la de una hoja HTML. Primero indicamos el dtd a utilizar, y después empieza la estructura del lenguaje de marcas. El código wml se encierra entre las etiquetas <wml> y </wml>. Cada carta se encierra entre las etiquetas <card id=”xxx” title=”xxx”> y </title>. Cada pagína WML puede tener varias cartas. En el navegador WAP aparecerán las cartas como las opciones, identificadas por su título.
4.2 WMLScript
WMLScript es un lenguaje de script, que viene a ser lo mismo para WML que lo que son JavaScript o VBScript para HTML. Es un lenguaje mucho mas simple que estos dos, pero que también permite proveer de inteligencia a los clientes. Esta basado en EMAScript, pero modificado para soportar mejor velocidades lentas de transmisión. Algunas de las operaciones que se pueden realizar con WMLScript son:
1. Realizar validaciones de las entradas del usuario.2. Acceder a los servicios del cliente, como es realizar llamadas, enviar mensajes
insertar números de teléfono en la agenda, acceder a la información de la tarjeta SIM.
3. Generar mensajes, sin necesidad de acudir al servidor, para indicar situaciones de error, avisos.
4. Agregar extensiones al software del terminal.
Como se puede ver WMLScript es bastante potente, y nos permite acceder a todos los servicios standard de los teléfonos móviles compatibles WAP.
Vamos a crear un ejemplo muy sencillo, que contiene dos cartas y una función script que nos devuelve un número aleatorio.
Fichero WML:
<wml>
<card id=”card1” title=”Random Example”>
<p>
Select Random
</p>
<do type=”ACCEPT” label=”Random”>
<go href=”random.wmls#getRandom”/>
</do>
</card>
<card id=”card2” title=”Random results”>
<p>
Result: $(RESULT)
</p>
</card>
</wml>
Este fichero contiene dos cartas, en la primera se muestra una opción al usuario, que al escogerla efectua una llamada a la función realizada en WMLScript. La segunda carta es llamada por la función script y muestra el contenido de una variable que la función SCRIPT ya se ha encargado de rellenar.
La función script contenida en el fichero WMLS es:
extern function getRandom()
{
var r = Lang.random(100);
WMLBrowser.setVar(“RESULT”, r);
WMLBromser.go(“random.wml#card2”);
}
La función es extremadamante sencilla, genera un número aleatorio, lo copia en la variable RESULT y llama a la carta card2 de la pagina RANDOM.
4.3 El futuro de WAP.
En un principio WAP tiene un futuro limitado, ya que quedará desfasado como tecnología con la llegada de tecnologías nuevas que ya tienen fecha de llegada como el UMTS. Pero esta afirmación es solo una verdad a medias, aunque WAP tenga un futuro tecnológico limitado toda la experiencia adquirida en proyectos WAP tiene un futuro inmenso y prometedor. Si nos fijamos en la progresión de las aplicaciones WEB, basadas en la Internet estática estas han sufrido una evolución inmensa, atribuible a la adquisición de experiencia en este nuevo entorno. Cuanto mas tiempo se lleve en la programación de aplicaciones para terminales móviles antes se detectarán las necesidades de los clientes y se adquirirá una estructura de trabajo y una cultura de empresa adiente al desarrollo de proyectos para la nueva Internet.
Tambien es verdad que las aplicaciones aparecidas gasta ahora para WAP no explotan todas las posibilidades de este protocolo, sobretodo las que nos da la nueva especificación 1.2.
Pongamos el siguiente ejemplo:
Un broker de internet que da la posibilidad de comprar y vender acciones a través de Internet dispone de una enorme ventaja sobre un broker que solo permita operar desde terminales en su oficina. El siguiente paso es permitir a los usuarios configurar alertas que vigilen la cotización de sus valores. Estos usuario pueden recibir alarmas,, via e-mail que les indiquen cuando deben vender o comprar. Esto permite que el usuario no deba estar permanentemente conectado vigilando los valores, una gran ventaja. El siguiente paso es dar estas alarmas por GSM. El usuario recibirá las alarmas ahora donde este, tan solo necesitará acceder a un terminal Internet y realizar sus operaciones. El siguiente paso es permitirle el acceso vía WAP a los servicios del broker. En este punto el usuario recibe una alarma GSM en su móvil, activa la página WAP del broker y realiza la venta. Con la nueva especificación 1.2 de WAP podemos ir un paso mas adelante, enviarle un mensaje WAP interactivo que le indique la cotización y mediante la pulsación de una tecla le permita comprar o vender. En un mundo tan competitivo como es la bolsa, un usuario con este servicio puede actuar casi con la misma rapidez sobre su cartera de valores que cualquier usuario que este en el parquet de la bolsa.
Esto es solo un ejemplo de los que se puede realizar con WAP.
5 General Packet Radio Service (GPRS)Es un servicio que permite enviar y recibir información desde terminales móviles a una velocidad de 170 kbps, 10 veces superior a la velocidad normal del GSM. La conexión se realiza de forma instantánea, dando la sensación de que estamos conectados permanentemente.
GPRS funciona mediante intercambio de paquetes, la información se separa en diferentes paquetes antes de ser enviada y se vuelven a unir al ser recibidos. Al usar paquetes los recursos solo se utilizan cuando el usuario esta enviando o recibiendo información, en lugar de dedicar un canal para cada usuario durante un determinado un periodo de tiempo determinado. Esta forma permite que los usuario puedan compartir los canales existentes.
El servicio de GPRS nos permitirá entrar en el mundo de Internet móvil, ya que gracias a su velocidad se podra acceder a todos los servicios de Internet, como chats, ftp, correo electrónico, WEB.
6 Universal Mobile Telecommunication System (UMTS)Esta es la verdadera revolución de Internet. Si tenemos en cuenta que a finales de este año existirán el doble de terminales móviles que de PCs nos podemos hacer una idea de la importancia que significará para el negoció de Internet el acceso masivo desde terminales móviles. En unos años se accedera mucho mas a los contenidos de internet desde móviles que desde PCs. Con la llamada tecnología de tercera generación tendremos imágenes, gráficos de alta calidad, voz, y nos abre todo un nuevo mundo de posibilidades por explotar. Se podrá realizar cualquier cosa desde nuestro terminal móvil. Se rompen las barreras que existen con los PCs actuales, como poca movilidad, acceso a una parte limitada de la población dependencia de una conexión fija. en un principio se podrá acceder a todos los servicios de Internet, pero la verdader revolución llegará con los desarrollos específicos, que atacarán necesidades todavía no cubiertas, de los usuario de móviles. Por eso es tan importante empezar a crear una cultura de desarrollo de soluciones para acceso a la nueva Internet.
Las prestaciones que nos ofrece la tecnología UMTS son:
1. Transmisión simétrica/asimétrica de alta fiabilidad. 2. Hasta 384 kbit/s en espacios abiertos y 2Mbit/s con baja movilidad. 3. Uso de ancho de banda dinámico, en función de la aplicación. 4. Soporte tanto de conmutación de paquetes como de circuitos. 5. Acceso a Internet (navegación WWW), videojuegos, comercio electrónico, y
vídeo y audio en tiempo real. 6. Diferentes servicios simultáneos en una sola conexión. 7. Calidad de voz como en la red fija.
8. Mayor capacidad y uso eficiente del espectro. 9. Personalización de los servicios, según perfil de usuario. 10. Servicios dependientes de la posición. 11. Incorporación gradual en coexistencia con los sistemas actuales de 2G. 12. Itinerancia o roaming, incluido el internacional, entre diferentes operadores. 13. Economías de escala y un estándar global y abierto que cubra las necesidades de
un mercado de masas. 14. Cobertura mundial, con servicios terrestres y por satélite.
Con estas prestaciones es fácil imaginar que las aplicaciones existentes ahora en Internet se quedarán cortas para este nuevo número de usuarios. Para que sirve acceder a un YAHOO si debemos teclear incómodamente los que queremos buscar, si los datos devueltos están en formatos incómodos para nuestras pantallas.
Se creará todo un campo nuevo de desarrollo que fomentara la construcción de aplicaciones con una nueva interacción hacia el usuario. Se dependerá menos del teclado y se fomentará la construcción de drivers y aplicaciones de reconocimiento de voz, se aumentara la interactividad entre el usuario e Internet.
La tecnología que nos permitirá desarrollar aplicaciones UMTS ya existe en gran parte, aunque evolucionara e incluirá servicios nuevos. En el servidor tendremos los elementos ya vistos, como servidores de aplicaciones con JAVA como protagonista, y en la parte cliente unos navegadores específicos que permitirán ejecutar todos los objetos de cliente existentes ahora, con algunas limitaciones lógicas.
Por eso lo mas importante de UMTS no es como desarrollaremos aplicaciones para UMTS si no que desarrollaremos.
7 E-BUSSINESSE-business es llevar a Internet los procesos esenciales de un negocio para mejorar el servicio al cliente, reducir los ciclos de producción, obtener más resultados con recursos limitados, e incluso vender cosas. Ofrece nuevas formas de oportunidades, necesidades, reglas y retos.
La palabra e-bussines en resumen define cualquier negocio en internet, pero algo tan sencillo se transforma en algo muy complicado. Estamos hablando de abrir la imagen de la empresa a todo tipo de publico y de realizar una inversión que nos puede llevar a tener uno de los WEB mas rentables del sector o un WEB olvidado por todo el mundo. Las diferencias entre estos dos tipos de WEBs no son tantas, y gran parte de ellas dependen de las compañías de desarrollo que realicen la aplicación.
El desarrollo de una aplicación e-business es especial por varias razones:
1. Velocidad de desarrollo. Los proyectos deben acabarse antes de empezar. Esta frase conocida en todos los proyectos aquí toma mas sentido, existe mucha competencia, todos están tomando su lugar, y un proyecto que tarde mas de 6 meses en salir desde su concepción puede quedar anticuado en poco tiempo.
2. Fiabilidad. Cualquier error es conocido por personas ajenas a la empresa y daña seriamente su imagen.
3. Rapidez. Internet es un medio lento, o no, dependiendo en gran parte de la rapidez de nuestros desarrollos.
4. Disponibilidad. Las aplicaciones e-business no tienen horarios, deben funcionar 24 horas al día todos los días.
5. Escalabilidad. Deben estar preparadas para aumentar su capacidad a medida que aumentan sus clientes, o las peticiones de estos. Internet es un entorno abierto no podemos controlar el número de usuarios.
6. Mantenibles. Una aplicación e-business que no evoluciona es una aplicación muerta. Internet cambia y la aplicación debe adaptarse a los cambios.
7. Seguridad. Para facilitar las operaciones a través de la red estas deben ser seguras, y parecerlo. Para ello existe toda operación deberá realizarse a través de SSL.
7.1 Business to Business (B2B)
El B2B es una nueva forma de negoció, describe la posibilidad de negocio entre empresas a través de Internet. En un proyecto de este tipo una empresa pone a disposición de sus distribuidores sus productos y su soporte a través de Internet. Tiene todas las características de una aplicación e-bussines, pero con el número de clientes mas limitados y conocidos por el dueño del negocio. Tienen un alto requerimiento de seguridad ya que se suelen generar grandes volúmenes de negocio ya que la ventas realizadas son a mayoristas.
Los mercados B2B reúnen a múltiples compradores y vendedores en un centro de transacción, donde pueden colaborar y negociar a una fracción del costo y tiempo que antes se necesitaba para las transacciones complejas. Además de abaratar los costos y aumentar la eficiencia, estos mercados en línea facilitan el acceso a mercados internacionales y geográficos sin grandes inversiones en cuanto a infraestructura.
De todos los modelos de negocio e-business este es que tiene un mayor grado de aceptación y de éxito, ya que se dirige a un publico conocido y no hacen falta grandes inversiones en publicidad.
7.2 Business to Client (B2C)
Este modelo el que se dirige a los clientes finales. Se basa en el abaratamiento de costes y de infraestructura, así como en la posibilidad de llegar a una mayor masa de clientes potenciales. Ejemplos de B2C son amazon, submarino, etc.
Se debe realizar un mayor inversión en marketing, y disponer de una fuerte red de distribución, o optar los servicios de una empresa de distribución. El punto fuerte de este tipo de negoció es la reducción de costes, al no tener que mantener una red de puestos de venta, y la facilidad de entrar en mercados nuevos.
Como podemos ver una tienda virtual esta compuesta de varios componentes:
Productos: El catálogo de productos que recoge nuestra oferta de productos y servicios.
Merchat Server: Es el software especial que permite al cliente procesar las selecciones de productos que realiza a través de una sesión de compra. Este producto se conoce también con el nombre de "carrito de la compra". Aparte de las funciones que incluye para gestionar las selecciones del cliente, ha de calcular: totales, portes e impuestos. Este carro de la compra debe ser fácilmente accedido por el cliente para cambiar productos y cantidades y debe ser
independiente de las tecnologías utilizadas para desarrollar las páginas HTML (ej: Java, Javascript, ...) En lo posible, ha de estar siempre visible. Existen ya varios Merchant Server standard que se adaptan a los diferentes WEBs.
Medios de pago: Como tarjetas de credito, determinados datos de las tarjetas de crédito de los clientes son enviadas a través de Internet, junto con el importe de la transacción, a una entidad financiera con la que nos hemos dado de alta previamente para operar con ella como un comerciante. En vez de una Terminal Punto de Venta (TPV o "bacaladera") física, tendremos un módulo de software proporcionado por la Entidad financiera, que se integra con la plataforma de Comercio Electrónico para, de modo transparente, procesar y autorizar los pagos. Si se acepta la transacción, la entidad financiera envía un mensaje al TPV indicando que puede seguirse adelante. Las operaciones de este tipo plantean problemas específicos que se están intentando solucionar mediante iniciativas como SET ("Secure Electronic Transaction")
Logística de envío: Podemos disponer de logística propia o tener esta actividad externalizada a otra compañía.
7.3 BUSINESS TO EMPLOYEE (B2E)
Es similar el B2C, pero va dirigido a los empleados de la compañía. Los productos a vender no son los mismos que en un B2C, aunque su estructura si es parecida, aunque sin implementar los medios de pago. Un B2E es un punto medio entre un B2C y una Intranet. En las intranets las compañias publican información, en los B2E se publica pero también se intenta que el empleado pueda suscribirse cursos de formación o servicios prestados por la compañía.
8 METODOLOGÍAS DESARROLLO.Internet ha traído consigo necesidades nuevas, que ha hecho que las necesidades de desarrollo también deban cambiar. Si por ahora hemos asistido a un cambio en los lenguajes de desarrollo utilizados, debemos adaptar todavía los demás puntos que forman parte del desarrollo de un proyecto, como pueden ser gestión y análisis. Debemos adaptar nuestras metodologías a las necesidades de estos proyectos.
8.1 Object Oriented Analisis And Design (OOAD)
La tendencia es que se vayan fusionando. Debido a la gran presión de tiempo que se tiene en los proyectos de e-business. Se realiza tan solo la parte de diseño, que se evoluciona. No se toma como dos tareas totalmente diferenciadas, si no que entre tareas de análisis y tareas de diseño obtenemos la estructura de objetos y los diagramas utilizados en el desarrollo.
Se compenetra a la perfección con el modelo de componentes de JSEE, y nos permite desarrollar software mas facil de mantener y de recibir ampliaciones.
La anotación mas usada de diseño OO es UML Universal Modeling Language. El UML es seguido por las herramientas mas comunes de diseño, y por ahora es un estándar universal que han adoptado todos los fabricantes de software.
8.2 UML
UML es una especificación de notación orientada a objetos. Se basa en las anteriores especificaciones OMT, BOOCH, RUMBAUGH y COAD-YOURDON. Divide cada proyecto en un número de diagramas que representan las diferentes vistas del proyecto. Estos diagramas juntos son los que representa la arquitectura del proyecto.
Con UML nos debemos olvidar del protagonismo excesivo que se le da al diagrama de clases, este representa un aparte importante del sistema, pero solo representa una vista estática, es decir muestra al sistema parado. Sabemos su estructura pero no sabemos que le sucede a sus diferentes partes cuando el sistema empieza a funcionar. UML introduce nuevos diagramas que representa una visión dinámica del sistema. Es decir, gracias al diseño de la parte dinámica del sistema podemos darnos cuenta en la fase de diseño de problemas de la estructura al propagar errores o de las partes que necesitan ser sincronizadas, así como del estado de cada una de las instancias en cada momento. El diagrama de clases continua siendo muy importante, pero se debe tener en cuenta que su representación es limitada, y que ayuda a diseñar un sistema robusto con partes reutilizables, pero no a solucionar problemas de propagación de mensajes ni de sincronización o recuperación ante estados de error. En resumen, un sistema debe estar bien diseñado, pero también debe funcionar bien.
UML también intenta solucionar el problema de propiedad de código que se da con los desarrolladores, al implementar un lenguaje de modelado común para todos los desarrollos se crea una documentación también común, que cualquier desarrollador con
conocimientos de UML será capaz de entender, independientemente del lenguaje utilizado para el desarrollo.
UML es ahora un standard, no existe otra especificación de diseño orientado a objetos, ya que es el resultado de las tres opciones existentes en el mercado. Su utilización es independiente del lenguaje de programación y de las características de los proyectos, ya que UML ha sido diseñado para modelar cualquier tipo de proyectos, tanto informáticos como de arquitectura, o de cualquier otro ramo.
UML permite la modificación de todos sus miembros mediante estereotipos y restricciones. Un estereotipo nos permite indicar especificaciones del lenguaje al que se refiere el diagrama de UML. Una restricción identifica un comportamiento forzado de una clase o relación, es decir mediante la restricción estamos forzando el comportamiento que debe tener el objeto al que se le aplica.
8.2.1 Diagramas.
Son la esencia de UML. Cada diagrama usa la anotación pertinente y la suma de estos diagramas crean las diferentes vistas. Las vistas existentes en UML son:
Vista casos de uso: Se forma con los diagramas de casos de uso, colaboración, estados y actividades.
Vista de diseño: Se forma con los diagramas de clases, objetos, colaboración, estados y actividades.
Vista de procesos: Se forma con los diagramas de la vista de diseño. Recalcando las clases y objetos referentes a procesos.
Vista de implementación: Se forma con los diagramas de componentes, colaboración, estados y actividades.
Vista de despliegue: Se forma con los diagramas de despligue, interacción, estados y actividades.
Se Dispone de dos tipos diferentes de diagramas los que dan una visión estática del sistema y los que dan una visión dinámica. Los diagramas estaticos son:
Diagrama de clases: muestra las clases, interfaces, colaboraciones y sus relaciones. Son los mas comunes y dan una vista estática del proyecto.
Diagrama de objetos: Es un diagrama de instancias de las clases mostradas en el diagrama de clases. Muestra las instancias y como se relacionan entre ellas. Se da una visión de casos reales.
Diagrama de componentes: Muestran la organización de los componentes del sistema. Un componente se corresponde con una o varias clases, interfaces o colaboraciones.
Diagrama de despliegue.: Muestra los nodos y sus relaciones. Un nodo es un conjunto de componentes. Se utiliza para reducir la complejidad de los diagramas de clases y componentes de un gran sistema. Sirve como resumen e índice.
Lo diagramas dinámicos son:
Diagrama de casos de uso: Muestran los casos de uso, actores y sus relaciones. Muestra quien puede hacer que y relaciones existen entre acciones(casos de uso). Son muy importantes para modelar y organizar el comportamiento del sistema.
Diagrama de secuencia, Diagrama de colaboración (Diagrama de interacción). Muestran a los diferentes objetos y las relaciones que pueden tener entre ellos, los mensajes que se envían entre ellos. Son dos diagramas diferentes, que se puede pasar de uno a otro sin perdida de información, pero que nos dan puntos de vista diferentes del sistema. En resumen, cualquiera de los dos es un Diagrama de Interacción.
Diagrama de estados: muestra los estados, eventos, transiciones y actividades de los diferentes objetos. Son útiles en sistemas que reaccionen a eventos.
Diagrama de actividades: Es un caso especial del diagrama de estados. Muestra el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos.
Como podemos ver el número de diagramas es muy alto, en la mayoría de los casos excesivo, y UML permite definir solo los necesarios, ya que no todos son necesarios en todos los proyectos. En el documento se dará una breve explicación de todos, ampliándose para los mas necesarios.
8.2.2 Diagrama de casos de uso.
Se utiliza para el modelado del aspecto dinámico del sistema. Este diagrama puede utilizarse tanto en el nivel de análisis como en el de recogida de requerimientos. Se emplean para visualizar el comportamiento del sistema, una parte de el o de una sola clase. De forma que se pueda conocer como trabaja esa parte del sistema. El diagrama de uso es muy útil para definir como debería ser el comportamiento de una parte del sistema, ya que solo especifica como deben comportarse y no como están implementadas las partes que define. Por ello es un buen sistema de documentar partes del código que deban ser reutilizables por otros desarrolladores. El diagrama también puede ser utilizado para que los expertos de dominio se comuniquen con los informáticos sin llegar a niveles de complejidad. Un caso de uso especifica un requerimiento funcional, es decir indica esta parte debe hacer esto cuando pase esto.
Aquí tenemos una pantalla del together en la que se muestra un caso de uso para un sistema de ventas. Podemos ver la figura del cajero que puede realizar las siguientes tareas: Pasar un escaner por el producto, Total items, que incluye el buscar precio y impuestos, y cobrar. Como podemos ver de cobrar se generaliza los diferentes tipos de pago posibles.
Por otro lado tenemos al responsable del inventario que puede modificar el stock de los productos.
8.2.2.1 Figuras del diagrama.
En el diagrama nos encontramos con diferentes figuras que pueden mantener diversas relaciones entre ellas.
Casos de uso: representado por una elipse, cada caso de uso contiene un nombre, que indique su funcionalidad. Los casos de uso pueden tener relaciones con otros caso de uso. Sus relaciones son:
Include: Representado por una flecha, en el diagrama de ejemplo podemos ver como un caso de uso, el de totalizar el coste incluye a dos casos de uso.
Extends: Una relación de una caso de Uso A hacia un caso de uso B indica que el caso de uso B implementa la funcionalidad del caso de uso A.
Generalization: Es la típica relación de herencia.
Actores: se representan por un muñeco. Sus relaciones son:
Communicates: Comunica un actor con un caso de uso, o con otro actor.
Parte del sistema (System boundary): Representado pos un cuadro, identifica las diferentes partes del sistema y contiene los casos de uso que la forman.
8.2.3 Diagrama de clases.
Forma parte de la vista estática del sistema. En el diagrama de clases como ya hemos comentado será donde definiremos las características de cada una de las clases, interfaces, colaboraciones y relaciones de dependencia y generalización. Es decir, es donde daremos rienda suelta a nuestros conocimientos de diseño orientado a objetos, definiendo las clases e implementando las ya típicas relaciones de herencia y agregación.
En el diagrama de clases debemos definir a estas y a sus relaciones.
8.2.3.1 La Clase.
Una clase esta representada por un rectángulo que dispone de tres apartados, el primero para indicar el nombre, el segundo para los atributos y el tercero para los métodos.
Cada clase debe tener un nombre único, que las diferencie de las otras.
Un atributo representa alguna propiedad de la clase que se encuentra en todas las instancias de la clase. Los atributos pueden representarse solo mostrando su nombre, mostrando su nombre y su tipo, e incluso su valor por defecto.
Un método u operación es la implementación de un servicio de la clase, que muestra un comportamiento común a todos los objetos. En resumen es una función que le indica a las instancias de la clase que hagan algo.
Para separar las grandes listas de atributos y de métodos se pueden utilizar estereotipos.
Aquí vemos un ejemplo. La clase usuario contiene tres atributos. Nombre que es public, dirección que es protected y situación que es private. Situación empieza con el valor 3. También dispone de tres métodos Entrar, Salir y Trabajar.
8.2.3.2 Relaciones entre clases.
Existen tres relaciones diferentes entre clases, Dependencias, Generalización y Asociación. En las relaciones se habla de una clase destino y de una clase origen. La origen es desde la que se realiza la acción de relacionar. Es decir desde la que parte la flecha, la destino es la que recibe la flecha. Las relaciones se pueden modificar con estereotipos o con restricciones.
8.2.3.3 Dependencias.
Es una relación de uso, es decir una clase usa a otra, que la necesita para su cometido. Se representa con una flecha discontinua va desde la clase utilizadora a la clase utilizada. Con la dependencia mostramos que un cambio en la clase utilizada puede afectar al funcionamiento de la clase utilizadora, pero no al contrario. Aunque las dependencias se pueden crear tal cual, es decir sin ningún estereotipo UML permite dar mas significado a las dependencias, es decir concretar mas, mediante el uso de estereotipos.
Estereotipos de relación Clase-objeto.
Bind: La clase utilizada es una plantilla, y necesita de parámetros para ser utilizada, con Bind se indica que la clase se instancia con los parámetros pasándole datos reales para sus parámetros.
Derive: Se utiliza al indicar relaciones entre dos atributos, indica que el valor de un atributo depende directamente del valor de otro. Es decir el atributo edad depende directamente del atributo Fecha nacimiento.
Friend: Especifica una visibilidad especial sobre la clase relacionada. Es decir podrá ver las interioridades de la clase destino.
InstanceOF: Indica que el objeto origen es una instancia del destino.
Instantiate: indica que el origen crea instancias del destino.
Powertype: indica que el destino es un contenedor de objetos del origen, o de sus hijos.
Refine: se utiliza para indicar que una clase es la misma que otra, pero mas refinada, es decir dos vistas de la misma clase, la destino con mayor detalle.
8.2.3.4 Generalización.
Pues es la herencia, donde tenemos una o varias clases padre o superclase o madre, y una clase hija o subclase. UML soporta tanto herencia simple como herencia múltiple. Aunque la representación común es suficiente en el 90% de los casos UML nos permite modificar la relación de Generalización con un estereotipo y dos restricciones.
Estereotipo de generalización.
Implementation: El hijo hereda la implementación del padre, sin publicar ni soportar sus interfaces.
Restricciones de generalización.
Complete: La generalización ya no permite mas hijos.
Incomplete: Podemos incorporar mas hijos a la generalización.
Disjoint: solo puede tener un tipo en tiempo de ejecución, una instancia del padre solo podrá ser de un tipo de hijo.
Overlapping: puede cambiar de tipo durante su vida, una instancia del padre puede ir cambiando de tipo entre los de sus hijos.
8.2.3.5 Asociación.
Especifica que los objetos de una clase están relacionados con los elementos de otra clase. Se representa mediante una línea continua, que une las dos clases. Podemos indicar el nombre, multiplicidad en los extremos, su rol, y agregación.
Ejemplo.
En este diagrama se han creado cuatro clases. La clase principal es Usuario, que tiene dos clases hijas UsuarioADM y UsuarioINF. El usuario mantiene una relación de asociación con la clase Clave, se indica que es propietario de una clave, o de un número indeterminado de ellas. Se le crea también una relación de dependencia con la clase Perfil, es decir las instancias de usuario contendrán como miembro una instancia de Perfil.
8.2.4 Diagrama de secuencia.
En el diagrama de secuencia se muestra el orden de las llamadas en el sistema. Se utiliza un diagrama para cada llamada a representar. Es imposible representar en un solo diagrama de secuencia todas las secuencias posibles del sistema, por ello se escoge un punto de partida. El diagrama se forma con los objetos que forman parte de la secuencia, estos se sitúan en la parte superior de la pantalla, normalmente en la izquierda se sitúa al que inicia la acción. De estos objetos sale una línea que indica su vida en el sistema. Esta línea simple se convierte en una línea gruesa cuando representa que el objeto tiene el foco del sistema, es decir cuando el esta activo.
En esta pantalla podemos que tenemos tres objetos, y un actor, situado a la izquierda que es el que inicia la acción. Como podemos ver el objeto de mas a la derecha aparece mas abajo que los otros existentes. Esto se debe a que indica que la llamada que recibe es una llamada de creación. Es decir el objeto no existe en el sistema hasta que recibe la primera petición.
Los colores forman parte de la notación UML, y cada color dispone de un rol diferente.
