pbdd1000 PDF

PowerBuilder Distributed Developer v10.
0 PBDD10
Módulo 1: Arquitectura Distribuida
PowerBuilder Distributed Developer v10.0
Modulo 1: Arquitectura Distribuida
1- 1
Derechos Reservados de TechEra e-Learning
PowerBuilder Distributed Developer v10.0 PBDD10
Tópicos
Revisando la Arquitectura Two-Tier
Arquitecturas Multitier (Distribuida)
CORBA
1-2 TechEra e-Learning 2005 – Derechos Reservados, este producto solo puede ser usado para uso personal y no para otros fines
1- 2
Objetivos
Al finalizar este módulo, se debe estar hábil para:
z Listar la ventajas y desventajas de la arquitectura Distribuida
z Definir los componentes del estándar CORBA
IDL
Stubs
Skeletons
1- 3
Modelo de desarrollo de alto nivel

Este curso Task Analysis
se enfoca en
estos tópicos Application Design / Flow
Architecture (Object-Oriented)
Build Implement Implement

Interface Objects Business Logic System Logic
Connect with the Data Source
Combine Interface, Business, and System Management Logic
Deploy
A un nivel alto, desarrollando una aplicación two-tier, particionando una aplicación consiste
de los pasos mostrados en la diapositiva. No se tiene que abandonar la experiencia que se
tiene para desarrollar aplicaciones multitier con el EAServer. Aunque hay unas diferencias,
se puede perfeccionar lo que ya se sabe.
Este curso se focaliza en los detalles de implementación para los componentes de negocio
desplegados al EASErver y los cambios necesarios en la aplicación cliente para usar estos
componentes.
Esta no es una clase de Diseño; sin embargo, los pasos de diseño son críticos para este
ambiente. Muchos desarrolladores ven que ellos tienen más cambios en la fase de diseño que
la fase de implementación de una aplicación multitier. Esta clase señala las buenas y malas
estrategias y le da la oportunidad para definir y construir un componente EAServer ancestro
para sus componentes de negocio. Se debería, sin embargo, buscar información adicional
para la fase de diseño.
1- 4
Revisando la arquitectura Two-Tier
Servidor de
Cliente Base de Datos
Vendor / Platform-
Platform-Specific API
z Interfaz de usuario z Administración de los datos

z Alguna lógica de negocio z Lógica de negocio
“propietario” en
procedimientos almacenados
y triggers
Las características de las aplicaciones two-tier incluyen:

Trabajo grupal/departamental
Ud. Controla el número de clientes, y por consiguiente el número de transacciones.
Ud. Controla la plataforma (s).
1- 5
Problemas con la arquitectura Two-Tier

El manejo del código no
particionado Falta de control centralizado
Volver a probar los cambios Díficil de implementar la
La administración de la máquina seguridad

cliente
Cuello de bolletas en el
El despliegue de cambio de la
aplicación a los mútilples clientes servidor de la base de datos/
La administración de la por la muchas conexiones
performance Lógica de negocio
Dejando la inversión del

Hardware existente
almacenada en la base de
datos escrita en el lenguaje
propietario
1- 6
Arquitectura Multitier (Distribuida)
Servidor de
Cliente Servidor de Aplicaciones base de datos
z Interfaz de usuario z Lógica de negocio z Administración de los
z Alguna lógica de negocio z Caching datos

(reducida) z Manejo de las transacciones
z Transparencia de la ubicación
de los datos
z Balanceo de carga
Características de la arquitectura Multitier

número imprevisible de clientes/transacciones
Aplicaciones abiertas a la Internet/extranet
Principios de la arquitectura Multitier

Encapsula o particiona la lógica de negocio en objetos.
Mueve o distribuye la lógica de negocio a una máquina dedicada.
Proporciona acceso a los objetos almacenados en un servidor de aplicaciones.
El servidor de aplicaciones recibe los requerimientos de procesos desde los clientes. El

servidor direcciona los requerimientos a los objetos de negocio para procesar.
Ejemplos:
Lógica de Negocio: autorización de tarjeta de crédito, carga de impuestos
Cache de datos estáticos: Estados, partes/productos
Servicios para recursos especializados: Gateway para mainframe/fax server
1- 7
Ventajas / Desventajas
Ventajas Desventajas
z Cientes “más delgados” z Cambios en los hábitos de
z Disminuye la administración del programación
cliente z Más curvas de aprendizaje
z Encapsulación de la lógica z Mayor tiempo en el inicio del
z Mejor perfomance diseño y desarrollo
z Escalabilidad z Más puntos de falla
z Consistencia, control y
seguridad
z Reutilización de componentes
existentes
z Posicionamiento para la Web
1- 8
Tres principales razones para moverse a n-tier

Más escalable
Mayor reutilización de objetos
Planeando un futuro desarrollo web/wireless
1- 9
CORBA
C C
Java Java
PB PB
ORB ORB
IIOP
ORB
C
Java
PB
1 - 10 TechEra e-Learning 2005 – Derechos Reservados, este producto solo puede ser usado para uso personal y no para otros fines
CORBA proporciona comunicación para cualquier lenguaje hacia cualquier lenguaje y

cualquier plataforma.
plataformas soportadas:
z Plataforma independiente
Lenguajes y componentes soportados:
z Lenguaje independiente
1- 10
Componentes CORBA soportados en EAServer

CORBA-Java
PowerBuilder Non-Visual Objects
CORBA C++ / C
ActiveX
EJB (Enterprise Java Beans)
Los componentes CORBA-Java CORBA-Java siguen al modelo de componente CORBA y

usan la interface estándar de CORBApra el manejo de transacciones. Cualquier clase Java
con la conducta de un nonvisual puede ser adaptado para ejecutarse como un componente
EAServer.
Los componentes PowerBuilder NVO usando PowerBuilder 7.0 o superior, puede crear
objetos no visuales(NVOs) que pueden correr nativamente en EAServer como un
componente EAServer, entonces use los proxies en aplicaciones cliente PowerBuilder
Los componentes EAServer CORBA C++ y los componentes C++ son clases C++ que
contienen métodos con similar prototipo para la interfaz del componente EAServer.
Los Enterprise Java Beans pueden ser accesado desde clientes PowerBuilder a través de los
mappings EJB-CORBA.
1- 11
¿Qué es CORBA?
Common Object Request Broker Architecture
Estándar de la arquitectura del objeto distribuido desarrollada
por el Object Management Group (OMG)

z Establecido en 1989
z Incluye a 800 compañías (IBM, SUN, Oracle, Sybase, ...)
z No incluye Microsoft
DCOM compite con CORBA

Vendedor-independiente
Separa la interfaz de la implementación
La OMG proporciona las especificaciones y estándares. OMG no proporciona el software o

implementaciones. Varios vendedores implementan las especificaciones.
Un rasgo llamativo de CORBA es que escribe los software que interoperan con otros
softwares via el bus objeto, solo se necesita conocer la interfaz del software; no se necesita
conocer cualquier detalle de la implementación.
1- 12
Interfaz Versus Implementación
Implementación
on
off
Interfaz
Interfaz remoto=
Stub (o Proxy)
1- 13
CORBA Interface Definition Language

module finance {
interface Loan {
double calculate(in double amount, in long
months);
};
};
on
off
El module es un paquete o un container de clases relacionadas (como una amortización,

finanzas, o una orden de entrada).
La interfaz define una firma del método. Note que no hay ningún detalle de implementación
en la especificación del IDL.
CORBA soporta un grupo de tipos de datos estándar. Estos tipos de datos deben ser
mapeados para los varios lenguajes de implementación (como Java y C/C++).
En CORBA, las interfaces son especificadas en una manera orientada a objetos

usando el Lenguaje de Definición de Interfaz (IDL). Se usa el IDL para definir los
objetos del componente (o tipos de datos), incluyendo cosas como la herencia,
atributos, eventos, y métodos (incluyendo sus parámetros y excepciones). Los
métodos especificados en el IDL pueden ser implementados en, o invocados
desde cualquier lenguaje para que los IDL mapeados puedan estar definidso. No
se especifica cualquier detalle de la implementación en el IDL, así que el IDL es
estrictamente declarativo y relativamente simple. La sintaxis del IDL es un
subconjunto de C++, incluyendo las macros de preprocesamiento y pragmas, con
algunas palabras claves para los conceptos de la computación distribuida. La
independencia del Lenguaje del IDL provee flexibilidad. Esto le dá libertad para
que puedas escoger el lenguaje de programación y plataforma para cada
componente en tu aplicaicón y te permite integrarlo con tus componentes
existentes. Para usar componentes heredados, se puede modelarlos en el IDL y
entonces escribir el código de la envoltura en el lenguaje del legado para
trasladarlo desde la interfaz de definición del IDL hasta la interfaz del legado. Asi
que la lógica de negocio que está implementado puede ser hecha en objetos
CORBA. Se puede entonces ensamblar estos componentes como bloques de
construcción para nuevas aplicaciones distribuidas.
1- 14
CORBA IIOP Method Invocation
Implementation
Client Object
Object
9. Invoca la
1. Invoca el método
implementación
2. Empaqueta Stub Object Skeleton 8. Desempaqueta
5. Reenvia el
3. Envía el requerimiento
requerimiento 7. Invoca el método
ORB ORB
4. Localiza el ORB destino 6. Identifica el objeto

destino
IIOP
Para la invocación estática, la aplicación cliente necesita tener conocimiento de los servicios del objeto
que deberá necesitar, así que la especificación IDL debe ser incorporada en el cliente como un objeto
servidor, usando el lenguaje de programación escogido. Se debe tener cuidado de esto por usar el
compilador del IDL (proporcionado por el vendedor de su ORB) para compilar el IDL en las rutinas del
stub en el lado del cliente y código del skeleton del lado del servidor.
Este diagrama muestra los procesos de un método en un objeto remoto. Porque el objeto está en una máquina
diferente, el requerimiento simplemente no puede enviarse de un objeto a otro. Esto puede ser empaquetado
(encriptado) para que esto puede ser enviado sobre la red. Ambos tanto la máquina que envia y la que recibe deben
tener el mismo protocolo (Internet Inter-ORB Protocol, o IIOP). El requerimiento entonces necesita ser
desempaquetado (desemcriptado) y finalmente, los métodos de la implementación pueden ser invocados.
el objeto stub encripta los requerimientos y los somete al ORB del lado del cliente.
el ORB encuentra el ORB destino en la red y envia el requerimiento.
el IIOP define una norma para enviar el requerimiento del ORB encima de algunos protocoloes de comunicación
de bajo nivel.
el ORB destino recibe los requermientos y direcciona al objeto apropiado.
The skeleton unmarshals the request and invokes the implementation object.
el objeto de la implementación contiene la lógica que comprende las reglas de negocio.
1- 15
CORBA - Stubs
Objetos proxy local
Empaqueta los requerimientos de la
invocación de los métodos

Provee transparencia de la ubicación
Implementa la misma interfaz como el objeto remoto deseado
Implementa el IDL-defined de los métodos en el lenguaje de
programación
El stub contiene todos las firmas de un objeto remoto sin los detalles de la implementación.
El stub también contiene la lógica para empaquetar todas las invocaciones de los métodos
para que esto pueda ser enviado sobre la red.
1- 16
Object Request Broker (ORB)

Maneja todas las comunicaciones entre los objetos dentro de
un sistema de objetos distribuidos:
1. Acepta los requerimientos de los clientes
2. Localiza y activa los objetos destinos
a. identifica la máquina que ejecuta el objeto del servidor
b. pide al ORB de la máquina una conexión al servidor
3. Direcciona el requerimiento y recibe la respuesta
1- 17
CORBA - Skeleton
Implementa los mecanismos para los requerimientos de
invocación hacia el servidor para ser desempaquetados y
direccionados al método correcto.
Son la colas de la implementación del objeto para el runtime
del ORB
Desempaqueta los argumentos de los métodos
También conocido como las clases base de la aplicación
1- 18
Implementación
Define el comportamiento para todas las operaciones y
atributos de la interfaz que soporta
Es creado usando un lenguaje de programación o modelo de
componente como PowerBuilder, Java, C, C++, o ActiveX
1- 19
Servidor
Programa que contiene la implementación de uno o más
tipos de objetos
Provee un ambiente para almacenar los componentes
Instancia los objetos CORBA
Aplica la seguridad
Maneja:
z Transacciones
z Failover
z Balanceo de carga
El servidor también aplica la seguridad, maneja las transacciones, maneja el

failover, maneja el balanceo de carga
1- 20
Resumen
CORBA separa la interfaz de la implementación de un
componente.
La interfaz de un objeto es descrito usando el Lenguaje de
Definición de Interfaz (IDL).

Los Stubs son objetos local proxy y delega la invocación de
los métodos a la implementación del objeto remoto
1- 21
Módulo 2: El EAServer
1- 22
Tópicos
Los problemas con la Arquitectura Distribuida
Roles de un Component Transaction Server (CTS)
Ambiente del EAServer
z Servidor
z Componentes
z Packages
z Repositorio
1- 23
Objetivos
z Iniciar el EAServer
z Conectarse a un servidor EAServer a través del EAServer
Manager y navegar en el IDE EAServer Manager

z Examinar el log del servidor desde una ventana y desde el
EAServer Manager
z Describir el rol de un Component Transaction Server (CTS) y
dar ejemplos
1- 24
Problemas con la Arquitectura Distribuida

Cuántas instancias de un componente se pueden tener?
Cuántas conexiones a una base de datos de pueden tener?
Cómo se puede manejar las transacciones entre muchos
componentes?
Quiénes pueden acceder al servidor?
1- 25
Roles de un Servidor de Aplicaciones

Para manejar eficientemente
z La instanciación y Ciclo de Vida de los Componentes
z Conexiones a la base de datos
z Transacciones
z Seguridad:
Server
1- 26
Experiencia Requerida
Business Developers
Ciclo de vida
es
Th
accion
rea
ds
Trans
Se
u g
rida
d
es
GUI Developers ccion
Co n e
Componentes
System Developers
EAServer maneja mucho del desarrollo de los niveles del sistema, así que se puede focalizar
en la lógica de negocio.
1- 27
Roles de un Component Transaction Server (CTS)
Provee un framework para desplegar la lógica de la capa

media de una aplicación distribuida basada en componentes
Provee soporte para:
z La administración del ciclo de vida de los componentes
z El Connection caching
z La administración de las transacciones
z La Seguridad
EAServer proporciona un ambiente de ejecución para tus componentes distribuidos. Esto

almacena tus componentes mientras proporciona servicios como uno de los listados en el
slide como servicios de componentes y objetos compartidos.
Como se verá en los demás slides, EAServer también provee el Jaguar Manager, que es una
interfaz simple de administración para los servidores EAServer eso le permite cambiar las
propiedades a través de la interfaz.
1- 28
Administración del Ciclo de Vida de Componentes

Define como los componentes son:
z Instanciados
z Ligados a los clientes
z Destruidos
Provee soporte para el instance pooling
Limitar el número de objetos instanciados y la cantidad de tiempo que una instancia es

ligado a un cliente es crítico en un ambiente WebOLTP con cientos o miles de
requerimientos.
1- 29
El Connection Caching
Los Componentes comparten un pool de conexiones pre-
asignadas al servidor de la base de datos remoto
Connection
Cache
Controlar el número de conexiones y el tiempo de una conexión física que necesita ser
creado y destruido en ambientes impredecibles son criticos para una performance eficiente.
El Connection Caching le permite controlar el número de conexiones a su base de datos.
1- 30
Administración de las Transacciones

Le permite definir la semántica transaccional de un
componente parte de la interfaz del componente
Ud. Puede determinar como los componentes EAServer pueden manejar las transacciones y
que roles pueden jugar en una transacción. Ud puede cambiar el manejo de la transacción
sin cambiar el código en su componente, haciendo cambios en la hoja de propiedades con el
Jaguar Manager.
1- 31
Administración de la Seguridad
El soporte basado en roles para la autenticación y
autorización de usuarios
La autenticación de los usuarios cuando la aplicación cliente
crea los stub
La lista de control de acceso para componentes que
determina que usuarios pueden ser permitidos para invocar
el componente
z Si un usuario no está autorizado, falla la creación del stub
Soporta certificados digitales
Soporta el Secure Socket Layer (SSL)
Potencialmente, cualquiera en internet podría conectarse y usar su aplicación. La seguridad

es más importante en este ambiente. EAServer te permite que tu implementes un sistema de
seguridad o liberes un sistema de seguridad establecido. La seguridad puede ser aplicada a
los package, el componente o a un nivel de método.
1- 32
Clientes y Componentes soportados
Java COM
HTML
IIOP/TDS
PowerBuilder SQL EAServer
MASP CORBA
EAServer soporta los siguientes clientes:

PowerBuilder
Java: JDK 1.22, 1.3 usando un EAServer CORBA-compliant ORB o cualquier otro
CORBA-compliant Java ORB; Enterprise Java Bean (EJB) también soportado

componentes ActiveX usando el EAServer ActiveX proxy
C++ usando un EAServer CORBA-compliant ORB o cualquier otro CORBA-compliant
C++ ORB
Métodos como stored procedures (MASP); cualquier database-aware lenguaje/herramienta
que pueda ejecutar procedimientos almacenados ASE

clientes HTML ultraliviano usanod una extensón de Web server (como el PowerDynamo)
CORBA (un cliente CORBA es una aplicación escrita lenguaje con mappings CORBA)
EAServer soporta los siguientes componentes:

PowerBuilder custom class user objects (CCUOs)
Java: Java Development Kit (JDK) 1.1 o superior; soporta la especificación EJB (1.0, 1.1,
2.0) ActiveXs (solo Windows NT o Windows 2000): la interfaz MTS soportada permite
mover fácilmente los componentes almacenados en el Microsoft Transaction Server (MTS)
al EAServer
C, CORBA C++
1- 33
Soporta J2EE
EJB 2.0
J2EE applications
J2EE Web Applications
Object Caching
JavaMail electronic mail API
Java API for XML Parsing
Java Authentication and Authorization Services
EAServer está certificado en Sun J2EE compliant
1- 34
Ambiente del EAServer

El servidor Jaguar
Requerimientos IIOP
Librerías
9000
Clase
Requerimientos TDS
7878
Requerimientos HTTP
8080
Componentes
Package
EAServer Manager Repositorio

El ambiente del EAServer consiste de:

Servidor
El Jaguar Manager (un plug-in para el utilitario Java Sybase Central)
Componentes
Packages (contenedores de componentes relacionados)
Repository (una coleción de archivos leibles que contienen las propiedades de información
para los componentes)
Un conjunto de librerías clases para soportar varios lenguajes/Herramientas
ORB y compiladores IDL
El servidor Jaguar acepta requerimientos IIOP porque IIOP es un estándard CORBA.
Acepta requerimientos TDS para la compatibilidad dirigida hacia atras con versiones 1.x. el
servidor acepta requerimientos HTTP y puede también ser usado como un servidor de
páginas.
1- 35
Servidor EAServer
Provee un ambiente de ejecución para los componentes
Maneja los requerimientos de los clientes
Instancia los componentes
Maneja la seguridad, transacciones, el conection caching, el
balanceo de carga y el failover.
Definido usando el EAServer Manager
El servidor por defecto es nombrado JAGUAR
En general, el ambiente en tiempo de ejecución que almacena los componentes es llamado

un servidor EAServer. Se puede crear servidores específicos para diferentes aplicaciones.
Especialmente, EAServer tiene un servidor por defecto, nombrado Jaguar.
EAServer soporta IIOP porque es un estándard CORBA. TDS es soportado para clientes
MASP y la compatibilidad con versiones anteriores de EAServer. HTTP también es
soportado. EAServer puede actuar como un simple Web server.
1- 36
Iniciando el EAServer
1- 37
Conectándose al EAServer - EAServer Manager
El Jaguar Manager es un Java Sybase Central especial, que maneja los
componentes, la seguridad. Esto es una herramienta de administración.
Para los desarrolladores PowerBuilder, algunas de las funcionalidades del Jaguar
Manager es ahora localizada en el PowerBuilder IDE via el System Tree y las hojas
de propiedades desde los objetos projects.
1- 38
El EAServer Manager
Con el Jaguar Manager, ud. puede:

Configurar y administrar servidores, packages, y componentes
Generar un archivo IDL en un ambiente point-and-click
Generar los stubs y los skeletons
Define las propiedades de execution-time, como:
z El ciclo de vida de los Componentes
z Las características de las Transacciones
z El modelo Threading
z La Seguridad
Monitorerar la performance en execution-time
Configurar los clusters
Crear y administrar los connection caches
1- 39
Examinando el log del Servidor
1- 40
Qué es un Componente EAServer?

Una definición de un componente consiste de:
z Asignación de métodos
z Modelo de Componente
z Soporte de transacciones
z El nombre de la clase Java o librería ejecutable que
implementa el componente (PBD, DLL, …)
1- 41
Qué es un Package EAServer?

Grupo de componentes relacionados
Colección de componentes que trabajan en conjunto para
proveer aspectos de la lógica de negocio para la aplicación
Define un “limite de confianza” entre los componentes para
comunicarse más fácilmente
Unidad de distribución, que agrupa los recursos de la
aplicación para un fácil despliegue y manejo
1- 42
El Repositorio EAServer
El Repositorio EAServer
contiene:
z Información de la
configuración para
cada servidor
EAServer
z Los datos para los
packages,
componentes y
métodos de la
aplicación
El servidor EAServer
usa el repositorio para
encontrar e invocar los
componentes
El repositorio es un conjunto de archivos que ud. Puede revisar con un editor de texto.
Los servidores en la misma instancia del EAServer comparten los mismos archivos del
repositorio.
1- 43
Librerías Clase / Virtual Machines

El Jaguar provee un conjunto de librerías clase y virtual
machines
z Una librería clase/virtual machine para cada
lenguaje/modelo soportado por Jaguar
Las librerías Clase / virtual machines son:
z Lenguaje / model-specific implementaciones de
servicios EAServer
z Usado para implementar los servicios EAServer en
componentes PowerBuilder
EAServer almacena el virtual machine para

PowerBuilder versiones 7, 8 y 9
Los Componentes escritos y desplegados en
PowerBulder 7 no necesitan ser recompilados y
desplegados.
1- 44
Múltiples PowerBuilder VM Support

La nueva propiedad del componente indica la versión del
PowerBuilder VM para utilizar con el componente.
Hay una nueva Declarative Component Property definida en EAServer 3.6 y superior para
soportar los múltiples PowerBuilder VMs. Esto es
com.sybase.jaguar.component.pb.version. Esta propiedad no es presentada para
componentes PowerBuilder desplegados desde PowerBuilder 7.x. Si la propiedad no es
presentada por defecto en EAServer (Jaguar) para PowerBuilder 7.x VM. Los componentes
desplegados desde PowerBuilder 8.0 tiene esta propiedad definida automática con el
EAServer.
1- 45
Resumen
EAServer provee un framework para desplegar la lógica de la
capa media.
EAServer provee soporte para el ciclo de vida de los
componentes, las conexiones, transacciones, thread, y

administración de la seguridad.
EAServer soporta PowerBuilder, Java, ActiveX, C, C++ , y
los componentes Enterprise Java Bean (EJB).
1- 46
Resumen
EAServer soporta clientes PowerBuilder Java, ActiveX, C++,
MASP, y HTML.
Un package es una colección de componentes que trabajan
en conjunto con aspectos de la lógica de negocio de la
aplicación.
El Jaguar Manager es usado para configurar y manejar los
servidores, packages y componentes.
1- 47
Lab 2-1: Familiarizándose con el EAServer

El laboratorio es localizado en el Libro de Laboratorio
Referenccias: Guía de Tareas
z Iniciando el EAServer
z Iniciando el Jaguar Manager
z Viendo el Server Log File
1- 48
Lab 2-1 Preguntas

Explicar las diferencias entre el servidor EAServer y el
EAServer Manager
Liste algunas propiedades para el servidor, packages,
componentes, métodos, connection caches

Preguntas de los participante sobre este laboratio?
1- 49
Módulo 3 : Manejando los Exception

en PowerBuilder
1- 50
Tópicos
Evento Error
Sentencias de Manejo de los Exception
Jerarquía del Exception System Class
Emitiendo Exceptions
Custom Exception Classes
1- 51
Objetivos
Al finalizar este módulo, Ud. será capaz de
z Crear un Custom Exception Class
z Modificar el signature de un método para emitir un exception
z Invocar un custom exception
z Desarrollar lógica en PowerScript para Capturar y Manejar los
Exceptions
1- 52
Evento Error
Todavía mantenido para compatibilidad con versiones
anteriores
Si no hay código en el evento Error, la información será
pasada al objeto RuntimeError

z DWRuntimeError
z OLERuntimeError
El Error puede ser manejado en un bloque TRY-CATCH
Los eventos de Error pueden también ser emitidos por un error de comunicación
encontrados en una conexión cliente al EAServer
El evento Error todavía es contenido en los siguientes objetos:
z Connection
z DataWindow
z DataStore
z JaguarORB
z OLE
z OLEObject
z OLETxnObject
1- 53
Qué es un Exception?
Los Exceptions son objetos que se activan en alguna
condición o error y son usados para describrir la condición o
error encontrado.
Ejemplos:
z Referencia a objeto Null
z División por cero
z Invalido nombre de columna DataWindow
Los errores Standard, como una referencia a un objeto nulo o división por cero, son
típicamente emitos por el runtime system. Estos errores podrían ocurrir en cualquier parte de
la aplicación y Ud. puede incluir cláusulas catch en cualquier script ejecutable para poder
controlar estos errores.
Manejar un Exception le permite a Ud. diseñar una aplicación para que pueda recuperar
desde condiciones excepcionales y continuar la ejecución. Cualquier exceptions que son un
descendiente de RuntimeError que Ud. no captura son manejados por el runtime system y
puede resultar en la finalización de la aplicación. En PowerBuilder esto es manejado por el
evento del Application el SystemError.
1- 54
Manejando Exception en PB 9.0

El manejo del Exception es como Java
z Bloque de sentencias Try .. Catch .. Finally
z Sentencias Throw y Throws
z Exceptions definidas por Usuario
Los errores de los Componentes en EAServer pueden ser

mejor manejados
Con la adición del manejo del exception, los clientes PowerBuilder están hábiles para
capturar los exceptions a través de los componentes EAServer (CORBA, EJB, PB) y
recuperarlo desde estos. Los componentes desarrollados con PowerBuilder pueden también
definir y emitir sus propios tipos de exception, haciéndoles más consistentes con otros tipos
de Componentes EAServer como Java.
El manejo del Exception es realizado como los Lenguajes Orientados a Objetos, como
Java, C++ y Ada. La implementación en PowerBuilder es similar a la implementación del
manejo de exception en Java.
Esto significa que Ud. puede manejar los errores de código en cualquier parte de su
aplicación en lugar de un solo evento del error global.
1- 55
Sentencias para el manejo del Exception

TRY – Inicia el bloque de código
CATCH – coge un exception específico, puede tener muchas
condiciones catch como se necesite

FINALLY – realiza el trabajo de limpieza sin saber si el
bloque fue satisfactorio o no

END TRY – Termina un bloque TRY..CATCH..FINALLY
TRY – Inicia un bloque de código que puede posiblemente emitir uno o varios exceptions
que Ud. desee, sin tener el exception que ser enviado al evento SystemError del objeto
Application. El bloque TRY puede contener uno o más sentencias PowerScript. Esto debe
ser seguido por uno o más bloques CATCH o un FINALLY.
CATCH – Especifica el tipo de exception que Ud. desea capturar explicitamente. El
bloque CATCH puede manejar y procesar el exception permitiendo a la aplicación
recuperarse y continuar adelante o esto puede re-emitir el exception.
FINALLY – Es una cláusula opcional que aparece después de todos los bloques CATCH
dentro del bloque TRY. Los bloques FINALLY son usados para continuar el código que
Ud. ejecuta sin tener en cuenta si el bloque TRY generó un exception o no.
END TRY – Es usado para indicar el fin de un bloque TRY..CATCH..FINALLY y
aparece como la última sentencia en el bloque.
1- 56
Jerarquía del Exception System Class
Checked
Unchecked
Los PowerBuilder runtime errors son representados por la clase jerarquica RuntimeError. El
RuntimeErrors puede ser capturado en bloque de código TRY-CATCH-FINALLY-END TRY. No
es necesario declarar donde una condición de error pueda Ocurrir (PowerBuilder lo hace por Ud.
desde donde un error de Sistema puede suceder en cualquier momento que la aplicación que se está
ejecutando). Estas exception classes son conocidas como Unchecked exceptions.
El system class Exception puede ser usado como una clase ancestro para tipos de exception
definidos por usuario. Es la clase raíz para todos los exceptions checked. Checked exceptions son
exceptions definidos por el usuario que deben ser capturados en un error de TRY-CATCH, o debe
ser declarado en el prototipo de un método cuando emite fuera de un bloque TRY-CATCH.
1- 57
Manejando un Exception
Double ld_num
ld_num = Double (sle_1.text)
TRY
sle_2.text = string (acos (ld_num))
CATCH (runtimeerror e1)
MessageBox("Runtime Error", e1.GetMessage())
FINALLY
// Adicione el código de limpieza
this.of_cleanup()
END TRY
MessageBox(“Después", “Hemos finalizado.")
Este es un ejemplo de un bloque TRY-CATCH-FINALLY que captura un system error

cuando un argumento arccosine, ingresado por el usuario de aplicación (en un
SingleLineEdit) no está en el rango requerido. Si Ud. no captura este error, la aplicación
terminará.
Esto es importante para ordenar su cláusula CATCH. Esto ocurriría si la primera cláusula
CATCH captura un exception de tipo Exception y una subsecuente cláusula CATCH captura
un descendiente del Exception. Desde que ellos se procesan en orden, cualquier exception
emitido que es un descendiente de Exception debería ser manejado por la primera cláusula
CATCH y nunca por el segundo. El compilador PowerScript detectará esta condición y
emitirá un error si lo encontró.
1- 58
Las capas de Manejo de Error para clientes

conectados a EAServer
Manejando el Exception
Objetos en el Evento Error
z Connection
z JaguarORB
Evento SystemError
PowerBuilder proporciona tres capas de manejo de error que pueden ser usados por clientes
que se conectan a EAServer:
Un mecanismo, usando bloques try/catch/finally, para el manejo de exceptions emitidos por
componentes ejecutándose en EAServer.
Todos los errores system y runtime son convertidos en objetos que descienden del tipo
RuntimeError.
El evento Error en los objetos Connection y JaguarORB para manejar errores que ocurren
en el contexto de una conexión EAServer.
El evento SystemError de un objeto Application para manejar errores que no han sido
capturados por otros mecanismos.
1- 59
Manejando Exception en un Cliente

PowerBuilder a EAServer
TRY
... // invoque los métodos
CATCH (corbacommfailure cf)
... // Un componente abortó la transacción EAServer,
// o la transacción estuvo fuera de tiempo. Reitente la
// transacción si lo desea.
CATCH (corbatransactionrolledback tr)
... // posiblemente reintente la transacción
CATCH (corbasystemexception se)
... // informa el error pero no pruebe reintentarlo
FINALLY
// poner el código de limpieza aquí
END TRY
Una aplicación cliente puede manejar los errores de comunicación de varias maneras.
Por ejemplo, si un cliente se conecta a un servidor y proeba el invocar a un método de un
objeto que no existe, el cliente puede desconectarse del servidor, conectarse a un
servidor diferente y reintentar la operación. Alternativamente, el cliente puede mostrar
un mensaje al usuario y darle la oportunidad para controlar lo siguiente.
Cuando un error ocurre, si el cliente se conecta a un nuevo servidor para reintentar la
operación, esto debe instanciar el objeto remoto del nuevo servidor antes de invocar un
método del objeto remoto.
CORBA proporciona una manera estándar para que los componentes indiquen el error o
warnings. CORBA soporta dos tipos de exceptions:
1. System exceptions, Un system exception es uno de los erroes estándar levandos
por el servidor. Estos exceptions son definidos en la especificaciónCORBA.
2. Exceptions definidos por el usuario, un user-defined exception es un error o
warning defnido en el IDL del componente. Un exception de usuario es un
nuevo tipo de dato que describe un conjunto de elementos de datos que son
retornados al cliente cuando el exception es levantado.
1- 60
Funciones para el manejo del Exception

GetMessage()
z Retorna el mensaje de error del tipo de objeto Throwable
SetMessage(“newMessage”)
z Pone un mensaje de error para el tipo de objeto Throwable
z Usado para poner un mensaje personalizado en un objeto
exception definido por el usuario

z newMessage es una cadena conteniendo el mensaje que se
desea poner.
1- 61
Custom Exception Classes

Son definidos como Standard Class User Objects
Son tres tipos de Standard Class para escoger:
z Throwable – ancestro de todos los Exceptions

z RuntimeError – ancestro del Unchecked Exceptions
z Exception – ancestro del Checked Exceptions
Throwable es la clase ancestro de todos los exceptions, para ambos el Checked y el Unchecked. Los
descendientes que crea del Throwable son Exceptions Checked. En la mayoría de situaciones Ud. no estaría
utilizando este tipo de Standard Class User Object. En cambio use el Exception para definir su propia clase
Checked Exception.
El RuntimeError debe ser utilizado cuando Ud. desea crear una exception Unchecked que no necesita ser
capturado por un bloque TRY CATCH. Si no lo captura explícitamente, las Exceptions Unchecked se irán al
evento SystemError del Objeto Application dentro de una aplicación PowerBuilder.
El Exception es el ancestro común para los Exceptions Checked que Ud. crea. Como todas las jerarquías
de herencia, definir una clase base de exception proporciona la flexibilidad para hacer cambios y mejoras
que serán realizados por todos los descendientes de un solo origen. Este es el tipo de clase que es utilizado
para crear clases custom exception para componentes PowerBuilder desplegados al EAServer.
1- 62
Definiendo un Custom User Exception
Seleccionando el exception de la lista permite que Ud. defina un descendiente del

PowerBuilder System Class Exception.
1- 63
Creando un Custom Exception Classes
Propiedad
Propiedadpara
para
Sostener la
Sostener la
sentencia
sentenciade
deError
Error
Funciones
Funcionespara
para
Obtener y Poner
Obtener y Poner
sentencias
sentenciasde
deError
Error
La propiedad text es usado para contener la sentencia de error, la razón por la que ocurrió
el exception.
El Getmessage() proporciona una interfaz programatica para obtener el valor del texto y
debe ser utilizado en lugar de accesar a la propiedad de texto directamente.

El Setmessage() proporciona una interfaz programática para cambiar el valor del texto. La
mejor práctica es llamar este método para cambiar el valor de texto como el método puede
tener que ser extendido para aparecer en la propiedad del texto, en lugar de reemplazarlo.
1- 64
Poniendo un mensaje personalizado

Defina un mensaje estandar en el campo Text.
setmessage() puede extenderse.
El Setmessage() puede ser extendido pero no el Getmessage(). Esto es debido a las
restricciones del CORBA IDL. El SetMessage() y GetMessage() son métodos estandard de

la clase CORBA IDL Exception.
1- 65
Sentencias que levantan los Exception

THROW – causa una condición exception para existir
THROWS – puede agregarse al prototipo de una función
para indicarle la capacidad al método para levantar un tipo de

exception
THROW – Sentencia usada para emitir un exceptión con código. Debe seguirse
inmediamente por un objeto exception válido dentro de la gerarquía de la clase throwable.

Trabaja como una sentencia de RETURN inteligente. Ninguna línea de código dentro del
método que aparece después de que la declaración de THROW se ejecuta a menos que el
código se contenga dentro de un bloque TRY.
THROWS – Cláusula definida dentro de un método. Las funciones y eventos soportan la
definición de la cláusla THROWS. Su presencia le dice al compilador el tipo de de método

del objeto(s) throwable que es permitido para emitir el código que invoca este método. Los
exceptions Unchecked (class RuntimeError y sus descendientes) no tienen que ser
explicitamente definidos con la cláusula THROWS para el método para que ellos puedan ser
emitidos por su código. Los exceptions Checked (clase exception y sus descendientes)
necesitan ser explicitamente defnidos en las cláusulas THROWS para el método.
1- 66
Los Métodos pueden levantar Múltiples Exceptions

Múltiples exceptions pueden ser separados por una coma en
la cláusula throws
1- 67
Emitiendo Custom Exception Classes
Para implementar este exception custom con un componente Ud. debe:

z Definir una variable de tipo nex_outofstock
z Instanciar el exception
z Lanzar el exception
Para que el método soporte emitir nuestro exception debemos de definir que el método sea capaz de lanzar el
nex_outofstock. Esto es cumplido a través del campo Throws en la declaración del prototipo del método. La
falla para definir esto resultará en un error de compilación. Recuerde que estos son Exceptions Checked que
deben ser capturados en el método o emitidos fuera del método donde ocurre el exception.
Un método puede soportar emitir más de un exception. Separe cada exception en el campo Throws con una
coma.
1- 68
Resumen
Un Exception es un objeto que puede ser emitido en el
evento de condición excepcional o error.
PowerBuilder 9 soporta exceptios Checked y Unchecked.
Exceptions Unchecked no tienen que ser manejadas dentro
de un script.
Exceptions Checked deben ser manejados, un error de
compilar resulta si dejo sin verificar y si el método no tiene

definido el exception.
1- 69
Resumen
Las sentencias CATCH deben ser ordenadas basadas en su
jerarquía de herencia, Iniciando con los descendientes.
El bloque FINALLY siempre se ejecuta sin saber si se ejecutó
un exception o no.
El GetMessage y SetMessage pueden ser usados para
mostrar o modificar mensajes de errores

Los Custom Exception Classes son Standard Class User
Objects
Tres tipos de Standard Class para escoger:
z Throwable – ancestro de todos los Exceptions

z RuntimeError – ancestro de Unchecked Exceptions
z Exception – ancestro de Checked Exceptions
1- 70
Lab 3 –1
Crear una clase exception user-defined nex_negative
Modificar la signatura de una función para emitir un
exception
Manejar el exception desde un cliente
1- 71
Lab 3
1- 72
Lab 3 Interrogantes
Prototipo de una función throws exception
Signature
refleja el
exception que
será emitido
Debe ser
instanciado
Emite cuando
detecta un
error
1- 73
Lab 3 Interrogantes
Todos los exceptions emitidos de una función deben ser capturados en
un Exception Handler. El compilador fuerza esto.
1- 74
Módulo 4: Creando Componentes

EAServer
1- 75
El objetivo
Mover desde un Two-Tier a... Multitier
Lógica de Negocio
embedida en un
control de interfaz calculate( )
EAServer
Loan
En este laboratorio previo del capítulo, se puede particionar la aplicación Loan Calculator y
separar la lógica de negocio de la interfaz. Ud. Hará esto creando un NVO y cree un método
en el NVO para que realice el cálculo que es realizado presionando el botón.
Una vez que la lógica comercial es dividida, esto puede ser distribuida al EAServer.
Distribuir la lógica de Negocio al EAServer proporciona un ambiente de escalabilidad con
opciones de ayudarte a manejar los connection caches, administrar las transacciones, el pool
de instancias, y la seguridad.
Distribuir la lógica de negocio también le permite reusar la lógica de negocio en otras
aplicaciones clientes como Java, C++ y clientes Web.
1- 76
Tópicos
Modelo de desarrollo de Alto Nivel
Procesos de Desarrollo
z Definiendo un componente EAServer

z Desplegando un Componente EAServer
z Conectándose al EAServer
z Generando un Proxy
z Inicializando el Proxy
z Invocando métodos de un componente EAServer
1- 77
Objetivos
z Crear un Componente EAServer desde el EAServer
Component Wizard
z Desplegar un componente EAServer
z Generar los objetos Proxy y Connection en el cliente
z Conectarse al EAServer desde una aplicación Cliente escrita
en PowerBuilder
z Crear una instancia de un Componente EAServer
z Invocar métodos de un Ccomponente EAServer
z Anticipar y manejar los EAServer Component Exceptions
1- 78
Modelo de Desarrollo de Alto Nivel

Task Analysis
Application Design / Flow
Architecture (Object-Oriented)
Build Implement Implement

Interface Objects Business Logic System Logic
Connect with the Data Source
Combine Interface, Business, and System Management Logic
Deploy
Este es un modelo de desarrollo de alto nivel que puede ser familiar para el trabajo en un
ambiente two-tier.
Aunque un ambiente multitier con EAServer difiere del ambiente two-tier, Ud. Será capaz
de poder usar sus conocimientos actuales.
Este curso se enfoca en lo siguiente:
Implementando la lógica de negocio
Conectar la lógica de negocio con el origen de datos
Combinar la interfaz y la lógica de negocio
1- 79
Procesos de Desarrollo
Librerías Cliente Librerías del Servidor
1. Define un Componente
2. Deploy al Componente
3. Conectase al EAServer gn_connect = CREATE n_jaguar_connect

l_rc = gn_connect.ConnectToServer()
4.Generar un Proxy
5. Initializar el Proxy l_rc = gn_connect.CreateInstance (in_rules,&

“businessrules/insurance")
In_rules.calcRate()
6. Invocar Métodos
Para distribuir la lógica de negocio desde el cliente al Jaguar y entonces llamar la lógica de
negocio almacenada en el Jaguar, Ud. Puede seguir este proceso simple. PowerBuilder
proporciona wizards para ayudarte con estos pasos.
Una vez que se está familiarizado con este proceso, te puedes mover a un escenario más
complejo como la llamadas de entre componentes y configurar a los componentes para las
transacciones, que son cubiertas en módulos posteriores. En este tiempo, se tiene que
focalizar en este simple proceso para dominar los conceptos básicos.
Cada paso incluye una serie de sub pasos e información adicional que es especificada en la
Guía de Tareas.
1- 80
Definiendo un Componente EAServer

1)
PBL
3) Project para
deploy del
componente
2) NVO para deploy
Para definir un componente EAServer, ud. Necesita:

z 1) Una librería (PBL) que contendrá su componente o componentes.
z 2) Uno o más custom classes que se intenté desplegar como componentes
z 3) Un objeto project con la información de despligue
Hay EAServer Component wizards en varias páginas del diálogo New …. Dependiendo
donde se encuentre determine que wizard utilizará.
1- 81
El Target EAServer Component Wizard
Este EAServer Component wizard en el tab page Target crea las 3 piezas necesarias
z 1) Un PBL nuevo para contener su NVO y objeto project
z2) Un custom class user object vacio – que debe ser personalizado para contener la
funcionalidad que se desea desplegar.
z 3) Un objeto project con propiedades que tu especificas.
El EAServer Component wizard en el tab pate PB Object asume que tu tienes un target y
solo creará los pasos 2 y 3 de arriba
The EAServer Component wizard en el tab pate Project asume que tienes un target PBL y
un custom class user object. Esto simplificará crear un objeto project para desplegar el
componente o componentes que tu especifiques.
1- 82
Demo del Instructor

Usando el EAServer Component Wizard desde un Tab
Target
Referencia: Guia deTareas– Definiendo un Componente EAServer
1- 83
Desplegando el Componente EAServer
Referencia: Guía de Tareas – Desplegando un Componente EAServer

Cuando presionas click en el icono Deploy en el objeto project, el objeto project despliega el
NVO al EAServer y crea los skeletons en el servidor.
El EAServer Component wizard crea un objeto project para ti automáticamente.
Ud. También puede crear el objeto project usando el EAServer Component wizard en el tab
Project.
Una vez que el objeto es desplegado al EAServer, deberías estar hábil para ver esto en el
Jaguar Manager (se puede necesitar refrescar el Jaguar Manager).
1- 84
Conectándose al EAServer
Referencia: Guía de Tareas – Conectándose al EAServer

El Connection Object wizard crea un objeto connection para que te puedas conectar a un
servidor EAServer.
Deberías estar hábil para ver el nuevo objeto connection en el System Tree después
presionas el botón Finish en el wizard. El Connection Object es un objeto no visual de
PowerBuilder (CCUO)
Todo esto sucede en las PBLs del lado del cliente.
1- 85
Conectándose al EAServer
// Instanciando el objeto connection
gn_connect = CREATE n_jaguar_connect
// Conectarse al Jaguar
ll_rc = gn_connect.ConnectToServer()
IF ll_rc <> 0 THEN

MessageBox (“la conexión al EAServer falló", &
ll_rc)
return
END IF
Se debería instanciar el objeto connection después de que este fue definido por el
Connection Object wizard. Después de instanciar el objeto, llamar a la función
ConnectToServer( ) para conectarse al EAServer.
El objeto connection y conectarse al EAServer son análogos a un objeto transaction que se
conecta a un base de datos.
Como operaciones de conectarse y desconectarse a una base de datos, existe un método

DisconnectServer() para complementar el método ConnectToServer().
1- 86
Ejemplo de un Manejo de Error

// Instanciar el objeto connection
gn_connect = CREATE n_jaguar_connect
TRY
l_rc = gn_connect.ConnectToServer()
CATCH ( CORBAcommfailure ccf )
MessageBox("corbacommfailure Caught", &
"ConnectToServer caught: " +&
ccf.getMessage() )
l_rc = 998
CATCH ( CORBASystemException cse )
MessageBox("CORBASystemException Caught", &
"ConnectToServer caught: " + &
cse.getMessage() )
l_rc = 998
END TRY
Revisón:
Volver a llamar, el PowerBuilder Provee 3 capas de manejos de errores que puede ser usado
por los clientes para conectarse al EAServer:
Un mecanismo, usando bloques try/catch/finally, para manejar excepciones thrown por
componentes ejecutándose en EAServer.
Todos los errores de sistema o en tiempo de ejecución son convertidos en objetos que
descienden desde el tipo RuntimeError.
El evento Error en el Connection y el objeto JaguarORB para manejar errores en el

contexto de una conexión EAServer.
El evento SystemError en el objeto Application para manejar los errores que no tienen que
ser capturados por otros mecanismos.
Este slides ilustra usando los bloques try/catch en un manejo estándar del exception
El siguiente slide ilustra usando el evento Error de un objeto Connection
1- 87
Ejemplo de un Manejo de Error
En este ejemplo, asume un standard class user object n_jaguar_connect, que descienden del
tipo connection que fue creado. Este tiene una función of_logError que registra la
información del error.
Nota: este método para manejar el error y el uso del evento SystemError ambos son
mantenidos para compatibilidad con versiones anteriores. El método del bloque de try/catch
es preferible ser usado por los desarrolladores.
1- 88
Generando un Proxy Stub
Referencia: Guía de Tareas – Generando un Proxy
Use el EAServer Proxy wizard en el tab Project para definir un objeto project que pueda
crear un proxy. Este wizard no crea el proxy por si mimos. Esto crea el objeto project que
debes de desplegar para generar el proxy.
El Proxy están en el lado del cliente. Hace pensar al cliente que el objeto está
localmente.
1- 89
Generando un Proxy, continua
El wizard del proxy tendrá que seleccionar todos los componentes para los cuales deseas
crear proxies. Tu puedes seleccionar el package entero o solo algunos.
1- 90
1- 91
Una vez que el objeto project es definido, click en el botón Deploy para generar el proxy.
Tu puedes ver el nuevo proxy en el System Tree y el Library painter.
1- 92
Inicializando el Proxy
// Inicializando el proxy
ll_rc = gn_connect.CreateInstance(in_rules, &
“SurfsideVideoPB/n_businessrules" )
IF ll_rc <> 0 THEN

MessageBox (“Falló el CreateInstance ",
ll_rc)
return
END IF
1- 93
Invocando métodos de un Componente

EAServer
Boolean ib_OK
ib_OK = in_rules.verify( amount, months )
Nota: se debe necesitar un bloque try.. Catch

block si cualquier exception fue levantado.
Ud. debe estár dispuesto a ver el proxy
exceptions en el System Tree, Cuando Ud.
despliega el Proxy project
Después el proxy es instanciado, se puede invocar los métodos del componente usando la
notación familiar <object>.<method>.
1- 94
Algunos shortcuts en PowerBuilder 10

La programación Drag and Drop se realiza desde el System
tree
La programación Drag and drop está disponible desde el System Tree. Localice el proxy en
el System Tree y abra las funciones. Localice el método que deses para llamar y entonces
drag and drop y sueltalo en el código del objeto window. Podrás modificar este código para
usarlo con tu variable usando la notación familiar<object>.<method>.
Si tienes el autoscripting habilitado, (Design | Options) desde el menú principal de

PowerBuilder y tienes que habilitar “After a dot include .. Methods” entonces digitar la
variable y después del punto esperar un momento y aparecerán los métodos disponibles para
la selección.
1- 95
Invocación de Métodos
Implementation
Client Object
Object
3) Invoca el Método
PowerBuilder
provides
Stub Object Skeleton
2) CreateInstance( )
EAServer
provides
ORB ORB
1) ConnectToServer( )
IIOP
Si cualquier caja no está creada o si cualquier línea entre las cajas no está establecida, la
invocación del método fallará. Use este diagrama como un checklist para asegurarte que
tienes establecido cada objeto y todos los enlaces entre los objetos.
1- 96
Resumen
Invocando un método en un Componente EAServer involucra
estos seis procesos:
1. Definiendo un Componente EAServer
2. Desplegando un Componente EAServer
3. Conectándose al EAServer
4. Generando un Proxy
5. Inicializando el Proxy
6. Invocando Métodos en un Componente EAServer
Los Wizards te ayudan a crear los Componentes EAServer,
los objetos connection, y los projects para desplegar
componentes y generar proxys
1- 97
Lab 4-1: Creando el Loan Calculator
Client
calculate( )
EAServer
Loan
Seguir el Libro de Laboratorio para completar el laboratorio. El Libro de Laboratorio

proporciona referencias especificas a las secciones en la Guía de Tareas, para la
documentación de PowerBuilder, y/o la documentación de EAServer para ayuda adicional.
1- 98
Laboratorios Opcionales
Lab 4-2 (Opcional): Usando un Servidor Remoto
Lab 4-3 (Opcional): Administrando el mantenimiento
Lab 4-4 (Opcional): Depurando un Componente Remoto
Seguir el Libro de Laboratorio para completar estos laboratorios adicionales. Ud. puede
realizar estos laboratorios en cada orden. Según su interés. El Libro de Laboratorio
proporciona referencias a la Guía de Tareas, la documentación de PowerBuilder, y/o la
documentación de EAServer para ayuda adicional.
1- 99
Lab
Declare una referencia al proxy
n_loan in_loan
Instanciación (hacerlo en el Open en este caso)
in_loan = CREATE n_loan
Llamar al método
double ld_amount, ld_payment, ld_interest = 6.625
int li_months
ld_amount = Double ( sle_amount.text )
li_months = integer( ddlb_months.text )
try
ld_payment = in_loan.calculate(ld_amount, li_months)
catch (nex_negative e1)
MessageBox(“Captura un Exception ", e1.getMessage())
end try
sle_payment.text = string ( ld_payment )
1- 100
Módulo 5: Manejando el ciclo de Vida

de los Componentes
1- 101
El objetivo
Responder estos tipos de preguntas:
z Cuándo es instanciado y destruido un componente?
z Cuándo un componente es ligado a un cliente?
z Cuánto tiempo un componente es ligado a un cliente?
z Cómo es desligando un componente de un cliente?
z Cómo se maneja en un ambiente como Internet?
z Porqué son importantes estas preguntas?
Describir el ciclo de vida de un componente
1- 102
Tópicos
El ciclo de vida de un Componente EAServer
Eventos del ciclo de vida en EAServer
Diseño de componentes Stateful Versus Stateless
El Instance Pooling
1- 103
Objetivos
z Modificar un custom class user-object que contiene eventos
EAServer
z Diferenciar entre los componentes Stateful y Stateless
z Escribir el código necesario para mostrar información en el
archivo Log del EAServer

z Modificar las propiedades de un componente y predecir el
comportamiento basado en el tipo de componente
1- 104
El ciclo de vida del EAServer Component

Instanciación
Espera
Activación
ligar al cliente
Reciclar
Ejecutar el método
Si
Si
Automatic Pooling
deactivation Desactivación support No
Destrucción
No
Desactivación
Primitive
1- 105
Sobre la administración del ciclo de vida del Componente
Determinar como las instancias de un componente son:

z Instanciadas
z Ligadas a un cliente
z Desligadas de un cliente
z Reusadas
z Destruidas
En una aplicación de alto volumen, como un ambiente WebOLTP, la instanciación y

destrucción de componentes pueden ser operaciones caras que degraden la performance de
su aplicación.
El objetivo debe ser minimizar ambos el número de instancias y la cantidad de tiempo de
una instancia de componente ligado a un cliente, y para que no pueda ser accesado por otros
clientes.
EAServer proporciona características que te permiten tener un pool de instancias de
componentes y administrar el ciclo de vida de los componentes para obtener una mejor
performance para tu aplicación.
1- 106
Facilidades y Beneficios del EAServer

Facilidades
z El Instance pooling
z Soporte de componentes Stateful y stateless
Beneficios
z Minimiza el número de objetos creados y destruidos
z Maximiza la compartición y reuso de recursos
z Minimiza la posibilidad de que un cliente monopolice un
recurso del servidor
El ciclo de vida EAServer se refiere a cuando un componente es instanciado, cuando esto es

destruido, cuanto tiempo es ligado a un cliente, y si el componente puede ser reusado.
Como establecer una conexión a una base de datos es un proceso largo y debe manejarse en
un servidor, el instanciar un objeto es también un proceso que consume tiempo y debe ser
manejado para la performance.
1- 107
Eventos del ciclo de vida del EAServer

Un componente puede implementar los eventos del Ciclo de
Vida del EAServer
z Constructor
z Activate
z Deactivate
z CanBePooled
z Destructor
EAServer invoca estos eventos
El servidor EAServer llama a estos eventos en el momento apropiado en el ciclo de vida de

los componentes. Esto le dá una oportunidad para la realización de cualquier lógica
necesitada, como la inicialización.
El EAServer Component wizard define estos eventos para tí. Si tu estas convirtiendo un
objeto de negocio existente a un componente EAServer, Ud. tiene que declarar estos eventos
y asignarle el event ID apropiado. Considerar adicionar un componente ancestro EAServer.
Vea en la sección “Definiendo un Componente EAServer Ancestro” en la Guía de Tareas
para más detalles.
1- 108
Eventos del ciclo de vida del EAServer

Constructor
z Invocado cuando el componente es inicialmente creado
(primer método llamado)
z El evento constructor es estándar para cualquier custom class
user object (CCUO)

Activate
z Invocado cuando el componente es ligado al cliente
z Usado para (re)inicializar las instancias con datos específicos
Deactivate
z Invocado cuando el componente es desligado del cliente
z Usado para liberar recursos
Si el componente usa recursos como un manejo de archvos, liberar el manejo en el evento

Deactivate. Instanciar variables en el componente puede ser inicialzado en el evento Activate.
1- 109
Eventos del ciclo de Vida del EAServer

CanBePooled
z Invocado justo después del Deactivate
z Invocado para determinar si la instancia puede ser usado
Destructor
z Invocado cuando el componente es destruido
z El evento destructor es estándar para cualquier CCUO
Evento CanBePooled :
Este evento es llamado solo cuando la opción instance Pooling es desactivada.
si el evento retorna 1, entonces la intancia es reusada.
El EAServer Component wizard no declara automáticamente esto para ti. Tu debes de
insertar un evento y asignarle el event ID apropiado. Ver la Guía de Tareas para más
detalles.
1- 110
Estrategias de diseño
Los componentes pueden ser diseñados para ser:
z Stateful
La instancia permenece ligado al cliente entre llamadas de
métodos
Las instancias pueden almacenar estados de información
El desarrollador es responsable para inicializar la desactivación
z Stateless
La Instancia es automáticamente desactivada después de
cada llamada del método.
Para cada llamada del método, Ud. no puede asumir que la
instancia será ligada al cliente.
El desarrollador es responsable para inicializar la instancia.
Los componentes Stateful son buenos para almacenar información sobre el cliente para ser
usados en el manejo de una transacción. Por ejemplo, un componente que ubica una orden
puede tener muchos métodos para permitir al cliente configurar un customer ID,
información sobre la orden, e información sobre cada item de la orden. En esta caso, tu
puedes usar componentes stateful para retener la información entre la invocación de
métodos.
En muchos casos, sin embargo, un componente no tiene que mantener la información entre
la llamada de métodos. Si el componente es stateful, el componente podría ser asignado al
cliente por un periodo largo y la performance de la aplicación se degradaría porque el
servidor necesita instanciar más instancias del componente.
1- 111
Componentes Stateful
Instance Pool
Componentes Stateful:
Mantener la información sobre un cliente entre la invocación de métodos
Almacena la información en propiedades (variables de instancia)
Exponga los métodos para manipular las propiedades
1- 112
setAmount(15000) 15000
setMonths(24) 24
calculate( )
return 725
Instance Pool
Una instancia es removida desde el pool y ligada a un cliente. La información sobre el

cliente es almacenada en la variable de instancia entre la llamada de varios métodos.
La instancia no puede ser usada por otros clientes mientras esté ligado a un cliente
específico.
1- 113
Como el cliente libera una instancia?
Que sucede si el cliente se olvida de liberar la instancia?
Instance Pool
Una vez que el cliente desactiva o libera la instancia, la instancia retorna al pool y puede ser
usada por otros clientes.
1- 114
Componentes Stateless
Instance Pool
Los componentes Stateless no pueden acumular o almacenar datos específicos de instancias

entre la invocación de métodos. Ellos no retienen información de una invocación del método
para el siguiente.
El cliente necesitará pasar la información como parámetros a lo métodos en cada uso o usar
algún tipo de almancenamiento persistente para mantener los estados de información.
1- 115
Calculate(15000,24)
return 725
Instance Pool
Con un componente stateless, se asume que la instancia es retornada al pool, la instancia es

desactivada y retornada al pool de instancias inmediatamente después de cada llamada al
método. Esto limita la cantidad de tiempo a la instancia de estar ligado a un cliente.
Dos invocaciones de métodos usando el mismo proxy puede ser servidas por diferentes
instancias.
in_customer.getData( )
in_customer.save( )
1- 116
Instance Pool
1- 117
Componentes Stateful Versus Stateless

Stateful Stateless
z Las instancias son ligados z Las instancias son ligados
a los clientes por largos a clientes por periodos
periodos cortos
z El servidor tiene iniciadas z El servidor tiene iniciado
más instancias pocas instancias

z Las instancias son z Las instancia son
reusadas poco reusadas más

frecuentemente frecuentemente
z El servidor requiere más z El servidor requiere pocos
recursos, limitando la recursos

escalabilidad
Nota: use componentes stateless, si es posible.
1- 118
Definiendo Componentes Stateful y Stateless

Desplegando el atributo de
tiempo
La instancia
automáticamente es
desactivada cuando el
método es retornado
9 Stateless (por defecto)

Stateful
Esta parte de la pantalla es de las propiedades del objeto project de despliegue
1- 119
El Instance Pooling
Permite a una sola instancia de un componente para
sucesivamente servir a múltiples clientes
La instancia es removida del pool
cuando es ligado al cliente(activated)

La instancia retorna al pool cuando
se desliga del cliente (deactivated)
Instance Pool
El pool de instancias es similar al pool de conexiones. Crear una conexión física para una
base de datos o inicializar una instancia física de un componente es una operación que
consume bastante tiempo que degrada la performance. El pool de instancias reduce el
número de tiempo que el EAServer debe físicamente crear y destruir una instancia de un
componente.
El objetivo es reducir el número de objetos instanciados.
Los Beneficios de esto incluyen:
Mejor escalabilidad
Compartir el número limitado de instancias por muchos clientes
Improvisar la performance en un ambiente impredecible
1- 120
Diseño para el Instance Pooling

Si las instancias son reusadas, como debería diseñar el
componente?
z Inicializar todas las variables de instancias en el evento
Activate
z Liberar todos los recursos en el evento Deactivate
1- 121
Implementando el Instance Pooling
Esta diapositiva muestra la hoja de propiedades de un objeto project que despliega un NVO
al EAServer.
Se puede activar la opción instance pooling en la hoja de propiedades. Por defecto soporta el
instance pooling.
Nota: muchas propiedades que se configure (como este) pueden también ser configurado en
el Jaguar Manager. Sin embargo, si tu configuras enel Jaguar Manager, la propiedad deberá
sobreescribirlo en el siguiente tiempo que despliegues desde PowerBuilder. El lugar
apropiado para poner estas configuraciones es en la hoja de propiedades de PowerBuilder.
1- 122
Propiedad Timeout
Esta hoja de propiedad es mostrada desde el painter del objeto Project in PowerBuilder
La propiedad Timeout permite configurar un periodo máximo del tiempo que una instancia
puede ser ligada a un cliente. Cuando el timeout expira, el EAServer desactiva la instancia
desde el cliente. Vea la documentación para más información.
1- 123
Como son las instancias desligadas del cliente?

Si el componente es stateless, entonces el componente es
desactivado después de cada
llamada del método
Si el componente es stateful,
entonces el desarrollador debe llamar a los métodos
primitives para desactivar las instancias
Si la propiedad Timeout es fija y expira
Los componentes Stateless son desactivados automáticamente al final de cada invocación.

Los componentes Stateful permanecen ligados al cliente hasta que una función
SetComplete( ) o SetAbort( ) del objeto TransactionServer es llamado. Si un state primitive
no es llamado, la instancia no es desligada del cliente. Si el cliente cierra, la instancia queda
huerfana.
Considere configurar la propiedad Timeout para los componentes stateful. Después que el
tiempo expire, el EAServer desactiva el componente.
1- 124
Desactivando un componente Stateful

El objeto TransactionServer provee state primitives (funciones)
Los state primitives son llamados antes de que el método sea
retornado para:
z Llamar al engine del Jaguar execution-time para desactivar la instancia
z Verifica si la transacción debe ser satisfactoria o fallida*
Retorne un objeto TransactionServer referenciado en el evento
Activate
TransactionServer its_jag
this.GetContextService ("TransactionServer", &
its_jag )
* Cubierto en el Módulo 7, “Manejando Transacciones”
1- 125
TransactionServer Primitives
Métodos TransactionServer:
z SetComplete( ) – Desactiva el componente
z SetAbort( ) * – Desactiva el componente
z EnableCommit( ) * – No desactiva el componente
z DisableCommit( ) * – No desactiva el componente
Ejemplo
// el método ejecuta la lógica de negocio
…
//Llama al EAServer para desactivar la
//instancia
its_jag.SetComplete()
return
* Cubierto en el Módulo 7, “Manejando Transacciones.”
El TransactionServer es un objeto que debería ser creado en el evento Activate. El

TransactionServer almacena la información sobre el componente. Se usa los state primitive
en la interfaz para el control del ciclo de vida para obtener y configurar la información en el
TransactionServer. El TransactionServer puede almacenar la información de la transacción
como la información del ciclo de vida.
1- 126
Ejemplo 1
Qué método(s) deberían desactivar la instancia?
setAmount(15000) 15000
setMonths(24) 24
calculate( )
Instance Pool
Se puede llamar a la función SetComplete( ) desde la función calculate( ). Se puede también

crear otra función que debería simplificar la llamada a la función SetComplete( ). El cliente
podría hacer muchas interacciones llamando al setAmount( ), setMonths( ), y calculate( )
almacenadas en la misma instancia. Entonces se podría llamar a estas otras funciones que
deberían llamar a SetComplete( ) para finalizar la liberación de la instancia.
1- 127
Ejemplo 2
Asuma que un componente customer es stateful con los
siguientes métodos:
z Retrieve( ) retorna los datos almacenados
z Update( ) aplica los cambios a los datos almacenados y los
actualiza
Qué método (s) deberían desactivar la instancia?
retrieve(blob)
update(blob)
Customer
Se puede llamar a la función SetComplete( ) desde la función update( ).
1- 128
El ciclo de vida del Componente EAServer

Invocación del método
Idle (in pool or
bound to client)
Already no Instance no
bound? in pool?
si Recycled
si
Execute method Bind to client Instantiate
Activate Constructor
si si
Automatic Deactivate CanBe
Pooling
deactivation no Pooled
no no
Deactivate
Primitive
EnableCommit( ) / SetComplete( ) /
DisableCommit( ) SetAbort( ) Destructor
El soporte de Pooling incluye el checkbox y el evento CanBePooled. Si Pooling es

seleccionada, la instancia es automáticamente reciclada y el evento CanBePooled no es
llamado. Si el Pooling checkbox es desactivado, entonces el evento CanBePooled es
llamado. Si el método retorna 1, entonces la instancia es reciclada o “pooled.” si el método
no retorna 1, entonces la instancia no es reciclada y esto es destruida.
El checkbox Automatic Deactivation determina si el componente es stateless o stateful. Si el
componente es stateless (seleccionado), entonces la instancia es deslgada del cliente y
verificada para ser reciclada. Si el componente es stateful, entonces el componente
determina cuando esto es desligado por la llamada a un state primitive.
1- 129
Ejemplo: El Carrito de Compras de Los Logos
Ud. implementa esta transacción

en los siguientes módulos
Para empezar:
Qué componentes pueden ser
pooled?
Qué componentes pueden ser
stateless? Add( )
n_order
n_cart
Add( ) PlaceOrder( )
n_order_items
1- 130
Resumen
El ciclo de vida de un componente refiere a como las
instancias son creadas, ligados a un cliente, desligados de
un cliente y destruidos.
Los componentes stateless son desactivados en el retorno
del método.
Los componentes stateful permanecen ligados al cliente.
El desarrollador del componente es responsable de
desactivar un componente usando los state primitives.
1- 131
Lab 5: Manejando el Ciclo de Vida del

Componente
Lab 5-1: Adicionando Eventos EAServer a un Custom Class User
Object
Lab 5-2: Escribiendo al EAServer Log
z Adicione la capacidad de anotar el error a n_loan
z Ver el mensaje en el server.log
z Adicione un command button Deactivate
Lab 5-3: Manejando el Ciclo de Vida del componente
z Escenario 1: Stateful – Primera llamada, segunda llamada
z Escenario 2: Stateful – Cliente A desactiva, pooling, no pooling
z Escenario 3: Stateless / pooling – Primera llamada, segunda llamada
z Escenario 4: Siga su curiosidad
1- 132
Lab 5 Preguntas
Preguntas?
Preguntas a los alumnos sobre el Lab 5-3
1- 133
Módulo 6: Procesando información de

la base de datos
1- 134
El objetivo
Cliente
Save( )
EAServer
GetData( )
Customer
1- 135
Tópicos
Qué es un Connection Cache?
Instalando un Connection Cache
Obteniendo una conexión de la base de datos
Trabajando con DataWindows en un ambiente Distribuido
z Sincronización de los DataWindow

z Recuperando un DataWindow en un Componente EAServer
z Actualizando un DataWindow en un Componente EAServer
1- 136
Objetivos
Al finalizar este módulo, se debe estar hábil para
z Instalar un Connection Cache en el EAServer
z Hacer Ping al cache en el Jaguar Manager
z Conectarse a un connection cache desde un programa
PowerBuilder
z Definir y codificar un método que retorne un result set usando
la sincronización del DataWindow

z Mostrar un result set retornado desde un método remoto
usando la sincronización del DataWindow
1- 137
El Connection Management
IIOP
Connection
Cache
Connection
Cache
El Connection
Manager
EAServer te permite que establezcas un pool de conexiones a varias base de datos. Cuando
un componente necesita una conexión, esto pregunta al Connection Manager para esto. El
Connection Manager provee una conexión desde el pool si existe uno, o establece una nueva
conexión física si no hay conexiones disponibles en el pool.
Cuando un componente libera una conexión, el Connection Manager retorna la conexión al
pool pero no se desconecta de la base de datos.
1- 138
Qué es un Connection Cache?

Un pool de conexiones disponibles para una base de datos
específica
Todas las conexiones en un cache comparten:
z User ID y password
z Base de datos
z Librerías de Conectividad
Todas las conexiones en un cache comparten el mismo user ID, password, base de datos, y
librerías de conectividad.
Sin embargo, muchas aplicaciones WebOLTP pueden asignar usuarios a los grupos y crear
connection caches sobre estos grupos. En estos casos, se puede obtener grandes beneficios
desde un connection cache.
1- 139
Beneficios de un Connection Cache

Mejora la performance
z Elimina la necesidad de crear una configuración a una
conexión cuando es requerida
Mejora la escalabilidad
z Permite a los servidores EAServe servir a cientos de clientes
usando solo unas pocas conexiones a la base de datos
Control sobre el número de conexiones a la base de datos
z Establece un número máximo de conexiones en un ambiente
impredecible
1- 140
Nota: vea en el Task Guide y el capítulo 24 “Using Connection Management,” en el

EAServer Programmer’s Guide para detalles de implementación. La documentación Online
para este libro está disponible cuando el EAServer es ejecutado desde la siguiente URL:
http://localhost:8080/docs/jagpg/main.htm
hay una manera para especificar un número mínimo de conexiones que el EAServer debería
establecer al inicializarse?
Respuesta: No hay una propiedad en el Jaguar Manager que permite especificar un número
mínimo de conexiones al EAServer cuando se inicializa. El EAServer provee eventos que
pueden ser codificados. Hay un evento Start que el cual se puede especificar un número fijo
de conexiones. Tu puedes codificar el evento en C en este tiempo.
1- 141
Nota: Use las tablas en la Guía de Tareas.

1- 142

1- 143

1- 144
Laboratorios 6
Lab 6-1: Instalando un Connection Cache
Lab 6-2: Familiarizarse con la Aplicación los Los Logos
1- 145
Obteniendo una conexión de la Base de datos

Como un componente obtiene una conexión desde un cache?
z Usa el objeto transaction y
z Usa la sentencia CONNECT Using <objeto transaction >;
Valores dbparm
z CacheName – Nombre del cache definido en el Jaguar Manager
z GetConnectionOption – vea la documentación de PowerBuilder
z ReleaseConnectionOption – vea la documentación de PowerBuilder
z UseContextObject – Use la opción YES para administrar las
transacciones*
* Cubierto en el Módulo 7, “Manejando Transacciones”
1- 146
El GetConnectionOption
JAG_CM_FORCE
JAG_CM_NOWAIT
JAG_CM_WAIT
Especificar como el EAServer debería comportarse si todas las conexiones en un cache

estan siendo usadas. Este parámetro DBParm es aplicado solo cuando un PowerBuilder
custom class user object es desplegado como un componente EAServer.
Los valores son:·

JAG_CM_FORCE (Defecto) asigna y abre una nueva conexión. La nueva conexión no es
ubicada en el cache y des asignada cuando la conexión explicitamente o implicitamente es
cerrada por el componente.
JAG_CM_NOWAIT Falla con un error si no se puede hacer las conexiones.
JAG_CM_WAIT No retorna hasta que una conexión esté disponible.
1- 147
GetConnectionOption del dbparm

Puede ponerse en el painter del Database Profile o en código
SQLCA.dbParm = "GetConnectionOption =&

'JAG_CM_NOWAIT'
1- 148
Obteniendo una conexión de una Base de datos

Componente
//Variables de Instancia
Protected:
Transaction itr_trans
// Evento Activate
If NOT IsValid(itr_trans) then // Evento Deactivate
itr_trans = CREATE transaction //Release the connection
END IF Disconnect using itr_trans;
Itr_trans.dbms = “ODBC”
Itr_trans.DBParm =&
“UseContextObject=‘Yes’,CacheName=‘EASDemoDB’”
CONNECT USING itr_trans;
If itr_trans.sqlcode <> 0 THEN … process error
1- 149
Trabajando con DataWindows en un Ambiente

Distribuido
z Como trabajar con DataWindows en un ambiente distribuido?
z Puedes compartir datos entre los clientes?
1- 150
Sincronizacion de los DataWindow

La sincronización del DataWindow provee un API para:
z Fácilmente transferir un DataWindows via blobs, incluyendo:
Datos
Flags de Status
Definición de DataWindow
DropDown DataWindow
o
z Transferir solo cambios de datos, incluyendo:
Datos
Flags de Status
1- 151
Funciones de la Sincronización de los DataWindows
Función Descripicón
GetFullState( ) Empaqueta un
DataWindow en un blob
SetFullState( ) Desempaqueta un blob

desde el GetFullState( )
en un control DataWindow
GetChanges( ) Empaqueta los cambios en un
DataWindow dentro de un blob
SetChanges( ) Aplica los cambios desde
el GetChanges( ) a un
DataWindow
1- 152
Sincronización del DataWindow : Recuperar
Componente
data
GetFullState( ) store
blob
Retrieve( )
Data
Window SetFullState( )
El objeto DataWindow y cualquier dropdown DataWindows no son necesarios en la

aplicación cliente. GetFullState( ) proporciona las definiciones para esto.
Sin embargo, el objeto DataWindow debe estar disponible en la librería del servidor si el
componente servidor usa la función GetFullState().
1- 153
Sincronización del DataWindow : Actualización
Componente
data
SetChanges( ) store
blob
Update( )
Data
Window GetChanges( )
El datastore en el componente EAServer no necesita ser asignado con un SetFullState( ).

SetChanges( ) puede ser aplicado para un datastore vacio.
Asignar los datos al DataStore permite al componente trabajar sin el estado de información.
1- 154
Recuperando un DataWindow
en un Componente EAServer
Client Application Component
Instance Variables Instance Variables

n_customer in_customer Protected:
datastore ids_data
Transaction itr_trans
Client connects to Jaguar and creates Activate

proxy (i.e., Open event) // Code to get a connection. See Task Guide
gn_connect = CREATE n_connect // Create data store
gn_connect.ConnectToServer() IF NOT IsValid(ids_data) THEN
// check for errors ids_data = CREATE datastore
gn_connect.CreateInstance(in_customer, END IF
"orderentry/n_customer") ids_data.dataobject = "d_customers"
// check for errors ids_data.SetTransObject(itr_trans)
Client initiates data retrieval (i.e., blob getData ( )

Retrieve event) blob lbl_data
blob lbl_data ids_data.Retrieve()
lbl_data = in_customer.getData ( ) ids_data.GetFullState( lbl_data )
dw_1.SetFullState ( lbl_data ) return lbl_data
Deactivate
// Release the connection
DISCONNECT USING itr_trans;
Este ejemplo asume que el componente es stateless, y que el componente debería ser
reusado. Note que el objeto transaction y el DataStore no necesitan ser recreados. Ellos
pueden ser creados y reusados por cada cliente para que la instancia sea ligada. Ud. No
necesita realizar la instanciación y destrucción de estos objetos cada vez se Activa y
Desactiva una instancia. Cuando la instancia es retornada al pool, este toma su objeto
transaction y datastore con él. Sin embargo, asegurarse para inicializar estos objetos en el
evento Activate y liberar todos los recursos en el evento Deactivate.
Nota: Se podría también reestablecer el DataStore en el evento Deactivate para liberar
cualquier dato de memoria.
1- 155
Actualizando un DataWindow
en un Componente EAServer
Codifique el cliente y el componente del servidor
Revise la Guía de Tareas
1- 156
Resumen
Un connection cache es un pool de conexiones disponibles
para una base de datos específica.
Usando connection caches mejora la performance y
escalabilidad de la aplicación.
Se define un connection cache usando el EAServer Manager.
EAServer provee un API para acceder a un connection cache
desde un componente
1- 157
Lab 6-3: Recuperando clientes

Opcionales: el objeto ResultSet
GetData( )
Customer
1- 158
Lab 6-4: Actualizando Clientes
Save( )
EAServer
Customer
1- 159
Laboratorios
Lab 6-3:
z Examine el código del n_customer para el método getData()
z Revise los procesos
z Revise solucionando los problemas con los tips del Libro de
Laboratorio
Lab 6-4
z Examine el código del n_customer para el método save()
1- 160
Módulo 7: Manejando Transacciones
1- 161
Tópicos
Qué es una Transacción?
Transacciones en un ambiente basado en Componentes
Manejando Transacciones
Llamadas entre componentes
Los Transaction Coordinators
1- 162
Objetivos
z Modificar la propiedad del componente que determine el
soporte de transacción
z Identificar el tipo de transacción y los valores de la propiedad
para cada componente en una transacción multicomponente

z Describir como el componente responde un satisfactorio o
falla
1- 163
Qué es una Transaction?

Una secuencia de sentencias SQL que completan una
unidad lógica de trabajo
z Cada sentencia SQL realiza parte de una tarea
z Todas las sentencias SQL deben ser satisfactorias para que
la transacción sea completa

z Si cualquier sentencia falla, todos los pasos previos
satisfactorios son deshechos
Ejemplo: Asumir que se desea transferir dinero desde una cuenta de ahorros para una cuenta
corriente. Hay dos pasos en este proceso:
1) Debitar desde su cuenta de ahorros.
2) Depositar a su cuenta corriente.
Porque ambos pasos son necesarios para que sean satisfactorios, ellos necesitan estar
ejecutados en una transacción. Si el débito fue satisfactorio, pero el depósito falla, se debería
desear desactivar el débito. Solo si todos los pasos son satisfactorios debería realizar un
commit para la transacción.
1- 164
Ejemplo
transferencia
Cajero Savings
1. retiro
Checking
2. deposito
Log
3. escribir
Qué sucede si al escribir el Log falla?
Este ejemplo demuestra una función de transferencia en una cuenta bancaria. Una
transferencia de ahorros a corriente debe satisfacer el débito y acreditar la verificación.
El root instance coordina la transacción.
1- 165
Transacciones 2 Tier
/* Si el Log es parte de /* Si el Log es separado
la transacción*/ de la transacción*/
IF Savings.withdraw()ok IF Savings.withdraw()ok
THEN THEN
IF Checking.deposit()ok
IF Checking.deposit()
THEN
IF log.write() ok ok THEN
THEN COMMIT;
COMMIT; ELSE
ELSE ROLLBACK;
ROLLBACK; ELSE
ELSE ROLLBACK;
ROLLBACK; END IF
ELSE IF log.write() ok THEN
ROLLBACK;
COMMIT;
END IF
ELSE
ROLLBACK;
1 - 166
END IF
TechEra e-Learning 2005 – Derechos Reservados, este producto solo puede ser usado para uso personal y no para otros fines
1- 166
Transacciones en un ambiente Basado en

Componentes
Múltiples componentes pueden participar en una sola
transacción
Cada componente realiza parte de una tarea
EAServer permite que un grupo de actualizaciones a la base
de datos sean realizados por múltiples componentes en una

sola unidad de trabajo
La transacción en una aplicación two-tier fue manejada en el código para verificar el código
de retorno desde los métodos y codificar un commit o rollback. Si la lógica cambia requiere
un cambio en como la transacción es manejada, el código también necesitará ser cambiado.
EAServer permite que definas y cambies la salida de una transacción a través del property
sheets. Cambiar a la transacción puede ser hecho también a través de código.
1- 167
El EAServer Transaction Management

EAServer ejecuta todos los componentes en una transacción
EAServer convierte las transacciones en propiedades en
deployment-time
La propiedad Deployment-time descrie como los
componentes se comportan en una transacción

multicomponente
El comportamiento transaccional puede ser definido a nivel
de método
Trabaja solo con conexiones obtenidas desde el EAServer
Connection Manager
Se debe usar un Connection Cache en orden para usar el administrador de transacciones del
EAServer cuando el EAServer es configurado para usar el Shared Connection transaction
coordinator
1- 168
Demo
Ejecutar la aplicación Bank con el Log como parte de la
Transacción
z Realice la transferencia exitosa y escriba
z Falle y escriba al log
Ejecutar la aplicación Bank con el Log separado de la

Transacción
z Realice la transferencia exitosa y escriba
z Falle y escriba al log
See the setup.txt file in the \Demos directory for instructions.
1- 169
Manejando Transacciones
1. Determine el soporte de transacciones de los componentes
2. Configurar la propiedad Transaction Support
3. Invocar los state primitive de una transacción
El EAServer Transaction Manager asegura que los cambios

a la base de datos sean realizados o no.
El Transaction Manger del EAServer asegura que los cambios a la base de datos realizados
por la participación de componentes sean todas guardadas o deshechos.
EAServer asegura que todos los componentes participantes en la transacción usen la misma
conexión física si el Shared Connection coordinator es seleccionado. Cuando un
componente requiere una conexión desde un connection cache, EAServer automáticamente
asegura que el componente obtenga la misma conexión como otros componentes en la
misma transacción.
1- 170
1. Determinar el soporte de Transacciones de

los Componentes
Seleccionar el valor Transaction Support
z Requires New
z Requires
z Supports
z Not Supported
z Mandatory*
z Never*
z OTS Style*
* Adicionales desde PowerBuilder 8

Requires Transaction – El componente debe ejecutarse en una transacción. Si hay una

transacción abierta, el componente se ejecuta en este. Si no hay una transacción abierta, el
componente inicializa la transacción.
New Transaction – el componente debe ejecutarse en una nueva transacción; por
consiguiente, esto siempre inicializa una transacción.
Supports Transaction – el componente no necesita una transacción. Si hay una transacción
abierta, el componente se ejecuta en la transacción, si no hay una transacción abierta,
entonces el componente no crea una transacción, esto se ejecuta sin una transacción.
Not Supported – El componente nunca puede ejecutarse en una transacción.
1- 171
Nuevas propiedades Transaccionales desde

PowerBuilder
Mandatory
OTS Style
Never
Mandatory – los métodos pueden ser solo invocados por otros componentes que tienen
una transacción excelente. Llamando a este componente cuando no hay transacción
excelente genera un error en tiempo de ejecución.
OTS Style – el componente puede manejar las transacciones. Esto puede heredar una
transacción del cliente. Si llamó sin una transacicón, el componente puede explícitamente
iniciar, guardar, y deshacer transacciones usando una instancia del objeto de servcio de
contexto CORBACurrent.
Never – los métodos no pueden ser invocados cuando hay una transacción excelente.
Llamando estos componentes cuando hay una transacción excelente genera un error en
tiempo de ejecución.
1- 172
El Root Instance
Usando la tabla en la Guía de Tareas, puede A y B estar
siempre en la misma transacción si ambos son llamados
directamente desde el cliente?
Component A
Component B
1- 173
Root Instance
Coordinator Component A
Component B
No, se crea un componente coordinator.

1- 174
Identificar el Transaction Support

Transferencia
Root Instance
Savings
Cajero 1. Retiro
Checking
2. Depósito
Log
3. Escribir
Empiece opciones que no trabajarían.

Un componente puede tener múltiples posibilidades para las características de la transacción

(en otras palabras, Requires Transaction y Requires New Transaction pueden ser ambas
válidas).
Asegurarse de ver el mayor alcance. Los componentes pueden ser llamados desde otros
componentes que pertenecen a una transacción separada o aplicación.
1- 175
2. Configurar la propiedad Transaction Support
Este es la hoja de propiedad de un objeto project que despliega un NVO al EAServer.
1- 176
3. Invocar los Transaction State Primitive
Desactiva No Desactiva
Satisfactorio SetComplete( ) EnableCommit( )
Falla SetAbort( ) DisableCommit( )
Un voto para satisfactorio significa que el rol del componente en la transacción fue satisfactoria. Algunas otros
componentes podría todavía causar que la transacción falle.
un voto para fallar significa que el rol del componente en la transacción fue insatisfactoria, y sin embargo la
transacción es obligada a fallar.
El diseño de un componente en el EAServer debería ser complementametne encapsulada. El componente debería no
necesitar conocer la salida de la transacción o que otros componentes están participando en la transacción. El
componente simplemente debería indicar donde será su participación en la transacción que fue satisfactoria..
Cuando es una instancia desactivada?
z En el retorno del método, si el Automatic demarcation/deactivation es configurado en TRUE
z En el retorno del método, después del SetComplete( ) o SetAbort( )
z Si instancia está participando en una transacción, después el root instance guarda la transacción con el
SetComplete( ) o deshace la transacción con el SetAbort( )

Aquí hay otras dos funciones del TransactionServer :
zIsInTransaction( ) le permite preguntar si el método actual está ejecutando en el contexto de una
transacción.
zIsTransactionAborted( ) le permite consultar si la transacción actual es obligada a deshacerse o estar
todavía viable.
1- 177
Satisfactorio o Fracaso
// Proceso parte de una transacción

// its_jag es el objeto TransactionServer
...
IF successful Then // satisfactorio
its_jag.SetComplete( )
ELSE // fracaso
its_jag.SetAbort( )
// Log error
return
END IF
PREGUNTAS: Si una transacción falla, se tiene que usar la función SetAbort( ) otra vez, si
es esto fue llamado por otro componente?
RESPUESTA: No se necesita llamar a SetAbort( ) para causar que la transacción falle si
otro componente ya había llamado a SetAbort(). En este caso, porque la transacción falla, la
función SetAbort maneja el ciclo de vida del componente y instruye al EAServer para
desactivar la instancia.
1- 178
Llamada entre componentes

Como se pueden llamar un método de un componente
desde un cliente?
1. Definir un objeto connection
2. Crear y publicar el objeto connection
3. Conectarse al EAServer con el ConnectToServer( )
4. Generar el objeto proxy
5. Inicializar el proxy con el CreateInstance( )
Como se puede llamar a un método de un componente
desde otro componente?
z Usar el mismo proceso
z Usar un shortcut
1- 179
Llamada entre componentes: Shortcut

Si los componentes son almacenados por el mismo servidor
EAServer
z Crear un objeto TransactionServer
z Llamar al CreateInstance( ) en el TransactionServer
Ejemplo: Suponer que el componente n_cart desea llamar al

método Add( ) del componente n_order
this.GetContextService ( &
"TransactionServer", its_jag )
its_jag.CreateInstance ( in_order, &
"orderentry/n_order" )
in_order.add()
Usando el shortcut requiere menos código y es más simple. Sin embargo, si el componente
está siempre ubicado en diferentes máquinas, entonces este código no debería funcionar.
1- 180
Si la transacción es abortada?
Usar el IsTransactionAborted( ) para verificar si la
transacción pueda ser deshecha
El Método del TransactionServer retorna un valor Boolean
Ejemplo
in_order.add() //llama al componente

IF its_jag.IsTransactionAborted() THEN
its_jag.SetAbort()//desactiva el componente
return
ELSE
// continua el proceso de la transacción
END IF
PREGUNTA: Tienes que emitir la función SetAbort() si ya conoces que la transacción es

fallida?
RESPUESTA: No necesitas emitir el SetAbort( ) para decirle al EAServer para abortar la
transacción porque algunos otros componentes participantes en la transacción votaron para
fallar. Tu puedes desear para llamar a SetAbort( ) para asegurarte que el componente es
desactivado.
1- 181
Los Transaction Coordinators
EAServer 4 ofrece transaction coordinators: el Shared Connection coordinator, el Microsoft Distributed Transaction
Coordinator (DTC), y el OTS/XA Transaction Coordinator, y el JTS/XA Transaction Coordinator. (no mostrado en
este pantalla)
1) Para el Shared Connection coordinator, todos los componentes participantes en una transacción deben compartir
una sola conexión física a la base de datos. Los componentes participantes utilizan el transaction management service
para votar para un éxito o falla. Al final de la acción de la transacción comercial el servicio de administración de la
transacción usa la información proporcionada por los componetnes para decidir donde hace un commit o un rollback la
transacción en la base de datos.
2) EAServer proporciona soporte para usar el Microsoft DTC, que maneja transacciones que usan múltiples
conexiones físicas de la base de datos. El DTC soporta el two-phase commits y requiere la plataforma Wintel (NT,
2000, XP), ODBC, y una base de datos DTC-compliant.
3) La opción OTS/XA (Object Transaction Service X/Open Architecture Transactions) usa el Transarc Encina
transaction coordinator que es creada en el EAServer. El Encina transaction coordinator usa two-phase commit para
coordinar las transacciones entre las base de datos múltiples. El OTS/XA transaction coordinator habilita para el
control del EAServer basado en transacciones desde un aplicación cliente EAServer.
1- 182
Resumen
Una transacción es una secuencia de sentencias SQL que
completan una unidad lógica de trabajo.
EAServer provee el manejo implicito de las transacciones.
El objeto TransactionServer permite a los componentes
influenciar en la transacción en los que están participando.

Las propiedades transaccionales pueden ser definidas a nivel
componente o método.
1- 183
Lab 7-1: Identificando el tipo de propiedad de

Transacción
Root Instance
n_cart n_order
n_order_items
1- 184
Lab 7 – Laboratorio
Identifique los posibles tipos de transacción para
z n_cart
z n_order
z n_order_items
1- 185
Módulo 8: Migrando aplicaciones
1- 186
El objetivo
Cliente
EAServer
add( )
n_order
n_cart
add( ) placeOrder( )
n_order_items
1- 187
Tópicos
Actualizando un componente con una Lista
Definiendo un componente ancestro
Trabajando todo en conjunto
1- 188
Objetivos
z Identificar tareas comunes que realiza un componente
EAServer
z Declarar variables de instancias en un componente ancestro
z Insertar eventos relacionados al EAServer en un componente
ancestro
z Codificar la inicialización típica de la funcionalidad en los
eventos EAServer
1- 189
Como cambiar un CCUOs para ir al EAServer?
Distributed
PowerBuilder
PowerBuilder
???
CCUO
CCUO
EAServer
Component
1- 190
Actualizando un Componente
Crear grupos de 2–3
Preparar una lista de items que tienen que cambiar para
actualizar su componente a EAServer

Compartir su lista con la clase
Revisar el checklist en la Guía de Tareas
1- 191
Jerarquía del Componente

Qué es común entre Componentes?
Variables Variables Variables
instancias instancias instancias
n_cart n_order n_order_items
Constructor Constructor Constructor

Activate Activate Activate
Deactivate Deactivate Deactivate
CanBePooled CanBePooled CanBePooled
Destructor Destructor Destructor
1- 192
Definiendo un Componente Ancestro
Variables Constructor
instancias Activate
Deactivate
CanBePooled
n_ancestro Destructor
n_cart n_order n_order_items
Extienda y sobreescriba los Eventos Descendientes como sea necesario
1- 193
Resumen
Los Objetos no visuales Two-tier y distributed requieren
cambios para tener funcionalidad en el Jaguar.
Use el checklist en la Guía de Tareas cuando actualice un
objeto no visual.
Use un componente ancestro para el Jaguar.
1- 194
Laboratorio 8
Lab 8-1
z Identificar las tareas comunes que un componente EAServer realiza
z Declare variables de instancias relacionadas a EAServer en un
componente ancestro
z Inserte eventos relacionados a EAServer en un componente ancestro
z Codifique la funcionalidad típica de inicialización en eventos EAServer
Lab 8-2
z Identifique las tareas necesarias para actualizar un componente
z Implementar el EAServer vote-style transaction management
z Invoque un método de otro componente EAServer
Identificar las tareas necesarias para actualizar componentes

Implementar el EAServer vote-style transaction management
Invocar un método en otro componente EAServer
1- 195
Lab 8-2: Implementando la transacción del Carrito

Cliente
EAServer
add( )
n_order
n_cart
add( ) placeOrder( )
n_order_items
1- 196
Lab 8 Interrogantes
Revisar el código del Lab 8-1 y Lab 8-2
Preguntas / Discusiones?
1- 197
Módulo 9: Tipos de Componentes
1- 198
Piense sobre
Cliente Cliente Cliente
getData( )
getData( ) getData( )
Jaguar
Product
Product
Product
1- 199
El objetivo: Cache Data

Cliente Cliente Cliente
getData( ) getData( ) getData( )

Jaguar
ServiceProduct Product
1- 200
Tópicos
Componentes Shared
Componentes Service
1- 201
Objetivos
z Describir los beneficios y características de un componente
shared
z Definir y desplegar un componente shared
z Describir los beneficios y caraterísticas de un componente
service
z Definir y desplegar un componente service
z Comparar y contrastar un componente service y shared
1- 202
Componentes Shared
Tipo de componente EAServer
Puede ser usado por múltiples clientes
Permite trabajar con datos persistentes y compartidos
Provee acceso conveniente a datos comunes
No soporta el instance pooling
Bueno para retener los datos relativamente estáticos para
muchos usuarios
Reduce el número de conexiones a la base de datos
1- 203
Diseñando Componentes Shared

Porque hay una sola instancia de un componente shared:
z Es el diseño diferente que un componente standard?
z Donde debería refrescarse los datos?
z Cuando debería obtener una conexión a la base de datos?
z Que debería ejecutarse en el evento Activate? Evento
Constructor?
1- 204
Diseñando Componentes Shared

Crear un método refresh( ) que debe hacer:
z Obtener una conexión a la base de datos
z Crear un DataStore sino está creado
z Activar el DataStore
z Liberar la conexión a la base de datos
Crear un método getData( ) que debe hacer:

z Retornar los datos concurrentes en el DataStore via la
sincronización de DataWindow
Llamar al método refresh( ) desde el getData() si el
DataStore es invalido
Llamar al método refresh( ) desde otro componente cuando
los datos deberían ser refrescados
1- 205
Implementando Componentes Shared
Este es la hoja de propiedades del objeto project que despliega un componente al EAServer.
1- 206
Componentes Service
Los Componentes Service realizan procesos internos o
proporcionan los servicios comunes como:
z Manteniendo las copias comunes de los datos usados
z Moviendo o replicando datos entre los origenes durante la
espera del servidor
z Maneja los archivos log de las aplicaciones
EAServer activa los servicios cuando es iniciado
1- 207
Implementando un Componente Service
Nota: vea la Guía de Tareas para más detalle.
1- 208
Interfaz de un Componente de Servidor

Un componente service provee tres métodos:
z start( )
Llamado cuando el servidor es iniciado
Usado para la inicializaicón
z run( )
Llamado inmediatamente después de completar el método
start( )
Realiza un loop por siempre para una tarea, y tiene un periodo
de espera específico.
z stop( )
Usado para parar el método run( )
1- 209
Plantilla para el Run( )

// tareas de inicialización
…
// use una variable Boolean para más control
Do while true
// realiza tareas
...
Sleep(10) // 10 Segundos para el sleep
Loop
* La función Sleep( ) fue introducido en PowerBuilder 8
1- 210
JagSleep( )
Usado si escribimos en versiones anteriores de PowerBuilder
y no tenemos la función Sleep( ).
Declare una subrutina local external
Use libjdispatch.dll como el library
1- 211
Resumen
Los componentes Shared permiten trabajar con datos
persistentes y compartidos.
Los componentes Shared proveen acceso conveniente a los
datos comunes.
Los componentes Shared no soportan el instance pooling.
Los componentes Service son activados e inicializados
cuando el servidor Jaguar es iniciado.

Los componentes Service tienen un método run( ) que puede
ser ejecutado perpetuamente, independiente de cualquier

interacción con el cliente.
Use componentes service para realizar procesos internos y
servicios comunes.
1- 212
Lab 9-1: Implementando el Catálogo de Productos

Client Client Client
getData( ) getData( ) getData( )

EAServer
Product
1- 213
Lab 9-2: Implementando un Componente Service

Client
EAServer
Product ServiceProduct
1- 214
Módulo 10: Web Targets y

Componentes EAServer
1- 215
Tópicos
Ambiente Web / Arquitectura
Ambiente de Desarrollo de los Web Target
Usando el Editor Web
Desplegando el Web Target
Llamando componentes EAServer desde un página Web
4GL Web Pages
1- 216
Objetivos
z Crear un Web Target y el profile de Deployment
z Crear una página 4GL Web usando el 4GL Web Page Wizard
z Modificar una página existente no-4GL Web Page para darle
capacidades de 4GL
z Escribir código usando el Coding Aids desde el System Tree
z Deploy y Run a un Web Target
z Ligar controles y variables
z Accesar a un componente EAServer desde una página Web
1- 217
Ambiente Web / Arquitectura
HTTP Web
Server
Browser API
Application
Server (JSP/
ASP)
PowerBuilder
Web Targets Corporate
EAServer
Data
Base de datos
Almacena los recursos Web y los datos. Estos podrían combinarse en la misma
base de datos. A menudo ellos están separados en su propia base de datos.
Application Server
Extiende la funcionalidad del Web Server. PowerDynamo (incluido en EAServer)
es un servidor de páginas que permite crear páginas web dinámicas. Microsoft
ASP es otro ejemplo para la creación de páginas web dinámicas.
API
Soporta las comunicaciones entre el Web server y el servidor de páginas
(PowerDynamo).
EAServer
Almacena los componentes que pueden procesar la lógica de negocio, el manejo
de las transacciones y la seguridad.
Los Web Targets de PowerBuilder
Es el ambiente de desarrollo integrado para desarrollar páginas Web, las
utilidades incluyen la generación rápida de documentos HTML, rápida generación
de código para el lado del cliente y del lado del servidor, depuración JavaScript,
Wizards para la creación y despliegue, design time controls y property sheets
“programming by property”. Se puede desplegar las páginas web a sites FTP, a
una base de datos en PowerDynamo y sitios Active Server Pages.
1- 218
Arquitectura para construir Aplicaciones Web
Static Web sites

Dynamic Web sites
WebOLTP
Estos son los tres tipos de soluciones que los negocios desean implementar en el Internet.
Como los productos Sybase encajan en las soluciones para estas necesidades comerciales
comunes?
1- 219
Web Sites estáticas
HTML HTTP
Web Browser
Web Server
El primer desafio para muchas compañías es ir a a la Web. Las compañías desean una
presencia en Internet, siempre que la presentacia ea limitada para una colección de páginas
Web Estáticas.
PowerBuilder 9 permite la creación de Web Targets. Con los Web Targets, los usuarios
pueden créar páginas a través de un editor WYSIWYG. PowerBuilder Web Targets puede
también importar páginas web creadas con otras herramientas Web como Microsoft
Frontpage y Macromedia DreamWeaver.
1- 220
Web Sites Dinámicas
JSP
HTML HTTP
Web Browser
Web Server
PowerBuilder Web Targets ASE / ASA
Para publicar páginas Web dinámicas, PowerDynamo es un servidor de páginas rápido que
puede acceder a una base de datos y formatear el contenido dinámico. PowerBuilder te
brinda el editor HTML WYSIWYG HTML con soporte para:
Codificar
Funcionalidad drag & drop desde el System Tree
4GL Web Pages para la fácil integración con los componentes EAServer
Design Time Controls para los Web DataWindow
Property Sheets para habilitar el “coding by property”
Esto es una solución Web pura. Sin embargo, la lógica de Negocio escrita en script
PowerDynamo o JavaScript no es fácil reusar. El manejo de Transacciones, multithreading,
y el soporte de conexión debe codificarse. Esto es perfecto para usar los Componentes
EAServer.
Generalmente, esto es una buena solución para aplicaciones que no son transaccionales,
stateless, o no interactivos: la publicación de la base de datos – Revisar el perfil del cliente
(por ejemplo, frecuencia de millas de vuelo), mostrar la lista de productos y colección de
datos (por ejemplo, registro en línea para eventos, seminarios y así sucesivamente).
1- 221
WebOLTP
Enterprise
Application Server
JSP
Java COM Web Server
HTML HTTP
IIOP
PowerBuilder
CORBA
EAServer
Soporta WebOLTP de alto volumen, aplicaciones transaccionales. Muchos clientes están
moviendo sus aplicaciones cliente/servidor existente a Web. Estas aplicaciones encajan en

esta categoría.
Como trabaja la comunicación?
Para clientes no HTML, el cliente se comunica con el EAServer a través del IIOP.
Para clientes HTML, El cliente se comunica con el servidor web a través del HTTP.
El servidor web usa CGI, ISAPI, o NSAPI para comunicarse con PowerDynamo.
PowerDynamo se comunica con el EAServer a través de un Java stub, MASP, o
ActiveX. EAServer puede aceptar requerimientos HTTP directamente. Applets
ejecutados en una página Web pueden conectarse al EAServer directamente a
través del IIOP.
Las características de una aplicación WebOLTP incluyen :
a) Un volumen con muchas conexiones, b) Transaccional, c) Habilidad para
manipular los resultados de datos, d) Una necesidad para la encriptación de datos
seguro, e) Habilidad para mantener el estado de información, f) Diseño basado en
componentes, g) Soporte para clientes heterogéneos, y h) Un ambiente de carga
impredecible.
Ejemplo: Comercio Electrónico, Banca electrónica.
1- 222
Una solución WebOLTP

El Enterprise Application Server (EAServer)
z La capa media se ocupa del proceso de la aplicación
z La capa media es el componente más crítico en una
arquitectura WebOLTP
z JSP – incluido en el EAServer
Soporte para clientes ultradelgados (HTML)

Servidor de Páginas
1- 223
Arquitectura
1 Base de datos
3
6
4
2
Web Server / Page Server Servidor de Componentes
1. El cliente inicia un requerimiento para una página Web

2. Si la página Web contiene un requerimiento para un componente EAServer o
un Web DataWindow, la información es enviada al Servidor de Componentes. Este
es el EAServer
3. El EAServer, a su vez puede necesitar acceder a la base de datos (si un
componente tiene una sentencia SQL o la información se necesita para refrescar
un Web DataWindow).
4. La base de datos retorna la información necesaria al Servidor de Componentes.
5. El Servidor de Componentes (EAServer) entonces pasa la información al
servidor de Páginas la estructura de la información.
6. La información estructurada es pasada al usuario
1- 224
Desarrollando Web Targets en PowerBuilder

Simplifica la creación de Aplicaciones Web
Automatiza la configuración de deployment
Dinámicamente extendido para los modelos de objetos
soportados
Automatiza el manejo de los links de los recursos Web
Soporta la depuración para páginas web y scripts
Simplifica la creación de aplicaciones Web porque te brinda muchos wizards para

este desarrollo, así como utilizar objetos de PowerBuilder como los DataWindows,
las curvas de aprendizaje utilizando PowerBuilder son menores.
Automatiza la configuración de despliegue(deploy) a través del wizard de
Deployment Configuration. Se especifica el tipo de servidor en la cual se desea
ejecutar los archivos Web como: PowerDynamo, Active Server Pages o un file
system que puede ser usado por cualquier servidor que se escoja. El Deployment
Controllers ajusta / transforma la sintaxis del script del archivo de origen para
convertirlo a los requerimientos del servidor Web escogido.
Dinámicamente extiende el soporte a los modelos de objetos para proveer un
modelo de objeto genérico con herramientas gráficas y propiedades de hojas para
simplificar la obtención de las conexiones a la base de datos, integra el Web
DataWindows, y los componentes EAServer. Si se sabe que la plataforma
escogida es PowerDynamo o Active Server Pages se utiliza las especificaciones
de la plataforma más allá del modelo de objetos genérico proporcionado.
Automatiza el manejo de los links de los recursos Web. El proceso de
construcción para los Web Targets verifica los enlaces entre archivos y reportes de
cualquier enlace roto. Un enlace roto es una referencia a un recurso Web que no
es localizado en una locación específica.
Soporta la depuración para HTML y soporta los lenguajes de codificación
1- 225
Arquitectura Abierta
El modelo de objeto Basic Web Target object soporta
codificación para mútlples applications servers
Permite el despliegue a múltiples application servers
Provee contenido dinámico para implementar el
comportamiento usando cualquier script ECMA-compliant :

z JavaScript
z DynaScript
z VBScript
z JScript
z Etc..
1- 226
Ambiente de Desarrollo del Web Target

System Tree
HTML Editor
Script Editor
Cascading Style Sheet Editor
Frameset Editor
Design-Time Controls (DTCs)
1- 227
Ambiente de Desarrollo
Creando PowerBuilder Web Targets
Importando páginas existentes, imágenes y código
Usando el Editor Web para crear Páginas Web
Usando el Coding Aids en el Editor Web
Desplegando los Web Targets
1- 228
Creando PowerBuilder Web Targets

Los Web Targets contienen todos los elementos necesarios
para crear su website
Un Web target es una aplicación Web, que contiene todos los elementos necesarios para construir un
Web site, archivos HTML, scripts, imágenes, componentes downloaded, como opciones de
configuración de conexiones a una base de datos, y despliegue.
PowerDynamo Web Site, Este wizard crea una base de datos ODBC que deberá contener al web
target. Esto configura un mapping ODBC para el website, crea la base de datos, publica la base de
datos y configura el despliegue por defecto para esta base de datos. También crea un mapping para la
URL para acceder a los archivos desde el web server.
Web Site, Este wizard simplifica las preguntas para el nombre del web target y crea un target vacío en
la ubicación que se especifique. Este wizard debería ser usado cuando el web target no está bajo el
mando de source control y si es un nuevo target (no un proyecto PowerSite existente creado en una
versión anterior de PowerSite)
JSP Target, Se usa el wizard del target JSP para construir una aplicación Web y te ayuda a configurar
las opciones de despliegue para desplegar una aplicación Web hacia un application server, como
EAServer o Tomcat.
Migrate PowerSite 7.1 Project, Use el wizard del Migrate PowerSite 7.1 Project para traer un proyecto
de PowerSite a PowerBuilder como un Web target. Se debe mantener una copia accesible a la base de
datos del Component Manager en orden para migrar los proyectos PowerSite.
Nota: PowerSite fue herramienta para diseñar páginas Web que venía con el PowerBuilder 7.0 a partir
de la versión 8.0 fue integrada a PowerBuilder y ahora es representada por los Web Target.
Source Controlled Web, Se usa el wizard del target Source Controlled para abrir un Web target que se
encuentra dentro de un sistema de source control.
1- 229
Importando Páginas Existentes, Imágenes y Código

RMB sobre el Web Target
z Import Files…
z Import Folder…
Gráficos existentes, páginas

HTML y archivos
JavaScript pueden ser
importados desde el file
system
Presionar el botón derecho en el Web target donde deseas importar los archivos. Se puede
importar uno o más archivos de un directorio o todo el directorio.
Import Files… permite que se pueda seleccionar uno o más archivos en el Web
Target.
Import Folder… permite que se puede seleccionar e importar un directorio con todo
su contenido. Un fólder con el mismo nombre como fue seleccionado debe ser
creado en el Web Target.
1- 230
Creando una Página HTML en PowerBuilder
Quick Web Page, es usado para poner una página rápida en el editor web.
Web Page, es un wizard simple que crea una página web simple. El wizard
pregunta alguna información básica acerca del cascading style sheet,
headers/footers y la imagen para el background.
4GL Web Page, es un wizard más sofisticado que configura las propiedades del
4GL. La Página Web 4GL permite que se pueda declarar la creación e
instanciación de componentes EAServer, crea variables, maneja errores y otras
opciones. Esto deberá ser discutido en detalle en este capítulo como una manera
de acceder a los NVOs de PowerBuilder y otros componentes CORBA y EJB.
Web DataWindow Page, es un wizard sofisticado que consulta al usuario para
poner un DataWindow existente en un design time control en la página web.
Frameset Page, es un wizard que consulta al usuario para crear una página
HTML frame. El wizard te pide la ubicación y el nombre de los framesets.
Script, crea un archivo de texto en el web target que contendrá el código que
haya escrito el usuario (como un archivo JavaScript para ser incluido en una
página Web).
Cascading Style Sheet, este es el wizard que induce al usuario a crear una hoja
de estilo con formato propio para asignarlas a las páginas que se van a crear,
como para tener un estándar de desarrollo.
1- 231
Usando el Editor Web para crear una Página Web
1- 232
Usando el Coding Aids en el Editor Web

Programación Drop Programming desde el System Tree
1- 233
Configuraciones de Deployment
Las configuraciones de
Deployment pueden ser
modificadas o adicionadas
accediendo a las
propiedades del web target
Ud. puede tener múltiples
configuraciones de
Deployment (Dynamo,
ASP, basic)
El orden de las
configuraciones puede ser
modificado
Si se crea un Web Target usando el PowerDynamo WebSite Wizard, una configuración de
deployment fue configurada para el web Target.
Se puede crear configuraciones de deployment adicionales accediendo a las propiedades de
los Web Target.
z Dynamo
z ASP
z Basic (static file or FTP)
Para Desplegar un web target es similar a desplegar cualquier objeto objeto project de
PowerBuilder. Se presiona el botón derecho en el target en el system tree y se selecciona
Deploy desde el menú popup.
1- 234
Deploy a un Web Target
1- 235
Llamando a EAServer desde una Página Web

Debe generar y compilar Stubs para el componente
EAServer
Dos métodos para llamar desde un cliente Web
z Codificación Manual (Necesario en versiones anteriores de

PowerSite)
z A través de una Página Web 4GL (preferido en PowerBuilder
8 y 9)
Page Properties
Programación Drag & Drop
1- 236
Generar y Compilar un Java Stub
Generate Java stubs en el Jaguar Manager.

Se puede generar Java stubs para un componente PowerBuilder.
1.Presionar el botón derecho en el componente o package y seleccionar Generate
Stub/Skeleton.
2. Especificar el directorio que deseas donde el Jaguar escribirá los archivos stub.
3. Activar el Check del Compile Java Stubs.
Muchos archivos Java son generados por el EAServer. Estos archivos comprenden el stub y
las clases.
1- 237
Manualmente llamando componentes EAServer
<HTML><TITLE>Result.stm</TITLE><BODY><H1>Loan
Calculator</H1>

</BODY></HTML>
El DynaScript para inicializar un Java proxy es una declaración simple de variable y

llamada de la función .
La función CreateComponent( ) inicializa el stub e identifica el servidor EAServer.
Si la llamada es satisfactoria, se puede entonces invocar los métodos del
componente.
El document.value es DynaScript que permite obtener los valores desde un campo en su
pagims web. Por ejemplo, document.value.amount obtiene el valor en el campo llamado
“amount”.
La función document.WriteLn( ) permite mostrar la información dinámica en la
página web.
1- 238
Páginas Web 4GL

Manejo de datos de páginas entre páginas Web (usando
parámetros de páginas, variables de páginas, y variables
session)
Acceder a los datos desde componentes EAServer
Ligar datos a controles en su página
Manejar la nevegación de la página
Crear server scripts con un mínimo de esfuerzo de
codificación
Procesos de depuración de páginas
1- 239
Creando una página Web 4GL

Wizard
Modify Page Property
Si se está creando una nueva página web, se puede usar el 4GL Web Page Wizard. El Wizard puede
acceder a los componentes EAServer que puedes necesitar usar, opciones de depuración y otras
opciones.
Si ya hay una página web existente, se puede modificar esto para que se convierta en una página
web 4GL, activando el Checkbox en las propiedades de la página la opción es “Enable the 4GL Web
Server Side Event Model”.
1- 240
Creando Variables 4GL Web Page
La cración de variables para toda una sesión se ha simplificado con las páginas Web 4GL.
En páginas Web no 4GL, las variables son declaradas en código. Las variables Session son
creadas llamando a métodos en el script del servidor. Con 4GL Web Pages, sin embargo,
este proceso es simplificado declarando variables en las propiedades de las páginas web.
1- 241
Ligando Controles a Variables
Una vez que las variables son declaradas ellos pueden se ligados a los controles en las
páginas Web 4GL. Ligando el el single line edit a la variable session username en este
ejemplo, cuando el usuario ingrese algo en el singleline edit en tiempo de ejecución, la
variable contendrá lo ingresado. Esta variable entonces puede ser usado en scripts del
servidor según el tiempo de vida especificado para esta variable.
1- 242
Llamando Componentes EAServer (4GL)

STEP 1
Use el 4GL Web Page Wizard y cuando pregunte por los componentes
EAServer, seleccionar todos a los que desea accesar o
Acceder al tab EAServer en el Page Properties de un 4GL Web Page.
Adicionar los componentes que se desea acceder
STEP 2
Localizar el método en el componente EAServer en el tab Components
del System Tree. Use la programación Drag & Drop para su server
script (o simplemente digitar la llamada de la función)
1- 243
Revisar
1 Database
3
6
4
2
Web Server / Page Server Component Server

1) El cliente inicia un requerimiento para una página web

2) Si la página Web contiene un requerimiento para un componente EAServer o un Web
DataWindow, la información es enviada al servidor del Componente. Este es el EAServer.

3) El EAServer, puede acceder a la base de datos (si un componente tiene acceso a SQL o la
información es necesaria publicar en el Web DataWindow).
4) La base de datos retorna la información necesaria para el Servidor del Componente
5) El Servidor del Componente (EAServer) entonces pasa la información al Servidor de Páginas con la
información formateada
6) La información formateada es pasada al usuario
1- 244
Resumen
Un Web target es una colección de archivos y componentes
usados para crear una aplicación Web que puede
representar todo un Web site.
Los Web sites Database pueden ser replicados para proveer
acceso fuera de línea o a usuarios conectados

ocasionalmente .
Los Web targets pueden contener cascading style sheets,
imágenes, páginas HTML, Framesets, archivos de código

JavaScript y páginas HTML especiales que contienen los
componentes DataWindows .
1- 245
Resumen
Se puede invocar los métodos de los componentes EAServer
desde un cliente HTML.
Las Páginas Web 4GL simplifican
z El reporte de Errores
z Creación de Variables
z Ligar datos a controles
z Instanciación de componentes
El código DynaScript es para invocar un método de un

componente que usa un Java stub.
Generar el Java stub desde el EAServer Manager.
1- 246
Lab 10-1
Crear Stubs/Skeletons para el componente Loan
Crear un Web Target para la aplicación Loan
Crear un 4GL Web Page para accesar al método calculate
del Componente
Desplegar y probar
1- 247
Lab 10-1 Interrogantes

Revisar los pasos para acceder al Componente EAServer
desde una página Web
Preguntas?
1- 248

pbdd1000 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

pbdd1000 PDF

Cargado por

Copyright:

Formatos disponibles

PowerBuilder Distributed Developer v10.

PowerBuilder Distributed Developer v10.0

Modulo 1: Arquitectura Distribuida

Modelo de desarrollo de alto nivel

Build Implement Implement

Connect with the Data Source

Combine Interface, Business, and System Management Logic

Revisando la arquitectura Two-Tier

z Interfaz de usuario z Administración de los datos

Las características de las aplicaciones two-tier incluyen:

Problemas con la arquitectura Two-Tier

 La administración de la máquina seguridad

Arquitectura Multitier (Distribuida)

z Interfaz de usuario z Lógica de negocio z Administración de los

z Alguna lógica de negocio z Caching datos

Características de la arquitectura Multitier

 Aplicaciones abiertas a la Internet/extranet

Principios de la arquitectura Multitier

 Mueve o distribuye la lógica de negocio a una máquina dedicada.

 Proporciona acceso a los objetos almacenados en un servidor de aplicaciones.

El servidor de aplicaciones recibe los requerimientos de procesos desde los clientes. El

 Cache de datos estáticos: Estados, partes/productos

 Servicios para recursos especializados: Gateway para mainframe/fax server

Tres principales razones para moverse a n-tier

 Planeando un futuro desarrollo web/wireless

CORBA proporciona comunicación para cualquier lenguaje hacia cualquier lenguaje y

Componentes CORBA soportados en EAServer

 EJB (Enterprise Java Beans)

Los componentes CORBA-Java CORBA-Java siguen al modelo de componente CORBA y

por el Object Management Group (OMG)

 DCOM compite con CORBA

La OMG proporciona las especificaciones y estándares. OMG no proporciona el software o

Interfaz Versus Implementación

CORBA Interface Definition Language

El module es un paquete o un container de clases relacionadas (como una amortización,

En CORBA, las interfaces son especificadas en una manera orientada a objetos

CORBA IIOP Method Invocation

2. Empaqueta Stub Object Skeleton 8. Desempaqueta

4. Localiza el ORB destino 6. Identifica el objeto

invocación de los métodos

 Implementa la misma interfaz como el objeto remoto deseado

 Implementa el IDL-defined de los métodos en el lenguaje de

Object Request Broker (ORB)

 También conocido como las clases base de la aplicación

componente como PowerBuilder, Java, C, C++, o ActiveX

 Instancia los objetos CORBA

El servidor también aplica la seguridad, maneja las transacciones, maneja el

Definición de Interfaz (IDL).

los métodos a la implementación del objeto remoto

PowerBuilder Distributed Developer v10.0

 Ambiente del EAServer

Manager y navegar en el IDE EAServer Manager

Problemas con la Arquitectura Distribuida

 Cómo se puede manejar las transacciones entre muchos

Roles de un Servidor de Aplicaciones

z Conexiones a la base de datos

Roles de un Component Transaction Server (CTS)

 Provee un framework para desplegar la lógica de la capa

EAServer proporciona un ambiente de ejecución para tus componentes distribuidos. Esto

Administración del Ciclo de Vida de Componentes

Limitar el número de objetos instanciados y la cantidad de tiempo que una instancia es

Administración de las Transacciones

Potencialmente, cualquiera en internet podría conectarse y usar su aplicación. La seguridad

La administración de la máquina seguridad

Aplicaciones abiertas a la Internet/extranet

Mueve o distribuye la lógica de negocio a una máquina dedicada.

Proporciona acceso a los objetos almacenados en un servidor de aplicaciones.

Cache de datos estáticos: Estados, partes/productos

Servicios para recursos especializados: Gateway para mainframe/fax server

Planeando un futuro desarrollo web/wireless

EJB (Enterprise Java Beans)

Los componentes CORBA-Java CORBA-Java siguen al modelo de componente CORBA y

DCOM compite con CORBA

Implementa la misma interfaz como el objeto remoto deseado

Implementa el IDL-defined de los métodos en el lenguaje de

También conocido como las clases base de la aplicación

Instancia los objetos CORBA

El servidor también aplica la seguridad, maneja las transacciones, maneja el

Ambiente del EAServer

Cómo se puede manejar las transacciones entre muchos

Provee un framework para desplegar la lógica de la capa

C++ usando un EAServer CORBA-compliant ORB o cualquier otro CORBA-compliant

J2EE Web Applications

JavaMail electronic mail API

Java API for XML Parsing

Java Authentication and Authorization Services

EAServer almacena el virtual machine para

Jerarquía del Exception System Class

Custom Exception Classes

El Error puede ser manejado en un bloque TRY-CATCH

Los errores de los Componentes en EAServer pueden ser

Este es un ejemplo de un bloque TRY-CATCH-FINALLY que captura un system error

Seleccionando el exception de la lista permite que Ud. defina un descendiente del

Para implementar este exception custom con un componente Ud. debe:

Exceptions Unchecked no tienen que ser manejadas dentro