Introducción.

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    XML25

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-BUSSINESS34

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:

Product
Description,
Special
features (See Servlet
Manufacturer Product(s) Legend Key) EJB API JSP
JRun Server J2EE Server,1.1 2.2 1.1
Allaire JMS, Servlet-
JSP Web Server
ATG Dynamo J2EE Server,1.0 2.2 1.1
Application Server Servlet-JSP
Web Server
Weblogic J2EE Server,2.0 2.2 1.1
BEA Systems Application ServerJMS, WAP/WML
Weblogic
Enterprise Server
Bluestone Total E-Server J2EE Server 1.0 2.2 1.1
WebSphere J2EE Server,1.0 2.1 1.0
IBM Application Server WAP/WML, JMS
Inprise Inprise ApplicationJ2EE Server 1.1 2.1 1.0
Server
Oracle 8i iASJ2EE Server 1.0 2.2 1.1
Oracle Oracle 8i ORDBMS
iPlanet ApplicationJ2EE Server, 2.2 1.1
1.1
Sun Server WAP/WML

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 XML
        

XML 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-BUSSINESS
        

E-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.