blog de amohr

Cuando hablamos o estudiamos WebServices nos aparece una infinidad de métodos y tecnologías desde los benditos WSDL, pasando por JSON, AXIS, SOAP, RPC y un largo etcétera. Si le sumamos a ello el acceso a base de datos y sus respectivas transacciones, la cosa se complica mas. Para ello, benévolamente, las grandes empresas tecnológicas nos ofrecen una y otra y otra más abstracción para que el desarrollo sea mas intuitivo y fácil de actualizar. Pero la pregunta del millón es: de verdad es más intuitivo y fácil de actualizar, además de rápido? Si ya todo esto tiene su problemática y su discusión aparece en la escena de esta tragicomedia tecnológica las aplicaciones móviles. Vemos todo tipo de aplicaciones móviles, miles, millones. Sin embargo, muy pocas apps son herramientas transaccionales/administrativas. Tenemos apps sociales, de multimedia, juegos, herramientas de productividad, editores, información, etc..

Es posible desarrollar sistemas y aplicaciones empresariales complejas que no sean WEB ? Es posible desarrollar Sistemas Modulares y distribuidos en JAVA capaces de ofrecer mejores interfaces, ergonomía, operación, transacciones seguras, velocidad y portabilidad. Qué al mismo tiempo sean fáciles de mantener, actualizar, modificar y crecer sin perjucio de afectar sistemas que actualmente están corriendo en producción ? Este blog no es para los tecnócratas o técnicos teóricos, este blog esta orientado a desarrolladores que desean y quieren comprobar la teoría con hechos prácticos y reales. Les dejo las preguntas y manos a la obra.

En este blog vamos a describir las opciones que hay para un pool de conexiones jdbc. Estos pools son necesarios cuando diseñamos una solucion empresarial. La problematica se centra fundamentalmente en el tiempo de la conexión, la cantidad de conexiones, las concurrencias de acceso a los datos y los diferentes proyectos que nos facilitan resolver esta necesidad. Finalmente, comprender y optar por una solución propietaria usando sólo los recursos que nos ofrece java, sin proyectos como apache DBCP.

ANTES QUE NADA UNA DISCULPA POR HABER DEJADO PENDIENTE EL DESARROLLO DE UN PUNTO DE VENTA EN JAVA. ESPERO ESTA VEZ COMPLETAR ESTA ENTREGA DE CODIGO EN JAVA PARA CREAR EL XML Y EL PDF EN JAVA PARA LA FACTURACION ELECTRONICA MEXICANA.
VAMOS AL GRANO ENTONCES.
LO PRIMERO QUE TENEMOS QUE TENER EN CUENTA ES LA ESTRUCTURA LOGICA DE LA APLICACION. EN PRIMER LUGAR TENDREMOS EL PAQUETE DEL PAC (PROVEEDOR AUTORIZADO CERTIFICADO) EN ESTE CASO "TIMBRE FISCAL". NO SE PREOCUPEN SI TIENEN OTRO, CASI TODOS SON MUY PARECIDOS Y SOLO CAMBIA EL PAQUETE. EN SEGUNDO LUGAR, LA APLICACION ESTA DISEÑADA PARA SOPORTAR VARIOS PACs, ESTO ES UNA GRAN VENTAJA PUESTO QUE SU APLICACION NO SERA DEPENDIENTE DE NINGUN PAC.
LUEGO TENEMOS EL Y LOS PAQUETES DONDE SE DESARROLLA LA FACTURACION ELECTRONICA Y POR ÚLTIMO EL PAQUETE DONDE SE LLAMA Y SE CARGAN LOS VALORES EN LA FACTURA. AQUÍ ES DONDE USTEDES PROGRAMARAN DE ACUERDO AL PERFIL O AL DISEÑO QUE HAYAN TENIDO CON SU APLICACION ACTUAL SEA DE ADMINISTRACION O DE LOQ UE FUERA. ES IMPORTANTE RESELTAR QUE LA INFORMACION QUE SE LE PASARA AL SISTEMA HA SIDO PROBADO DESDE JSF, JSP, STRUS Y COMO J2SE.

Hace muchos años, cuando comence de adolescene a meterme en todo esto de la programación, un profesor de matematica computacional me dijo que todo se resumia a 2 conceptos: prendido y apagado y a 10 palabras reservadas en el lenguaje ensamblador para poder desarrollar cualquier aplicación. Me hacia la comparación de los número ordinarios que desde el 0 al 9, podríamos definir infinitas convinaciones y complejos de formulas matematicas.

A que vengo con todo esto?. Acordarme de cuantas palabras reservadas tiene JAVA es un tema. Saber cuantas clases de terceros y de JAVA hay para desarrollar una aplicación es otro tema; pero acordarme de todos los benditos tags desde el html, pasando por muchos framework y hasta llegar a jsf es otro, muy diferente tema. Y si a esto le sumamos la dificultad de depurar las aplicaciones, definitivamente un desarrollador se pasa mas tiempo pensando donde encajar una pieza de un rompecabeza inmensamente grande en un complejo de invensiones raras que ofrecen los proveedores para desarrollar aplicaciones empresariales en internet. Como que te pasas 2 hora para hacer una pantalla y 5 minutos para las reglas del negocio.

Para correr nuestra aplicación JAVA de PUNTO DE VENTA vamos a necesitar los siguientes programas o herramientas.

Eclipse ver. Galilea con el PLUGIN de VE (Visual Editor)

Java Developer Kit 1.6.20 en adelante

IReport ver 3.7 en adelante.

Tomcat 6.0

Firebird 1.5. (Base de datos)

IBExpert IDE para el Firebird

Para que puedan correr esta aplicación deberán llamar un par de servlets y web services que se encuentra en la siguiente liga.

Aclaro que el ingreso a esta página se hace a través del puerto 8024 y no del 8080. Por lo cual es necesario que habiliten vuestro firewall o router para que los deje pasar por este puerto. Generalmente y en los modem residenciales o de casa, esto no es necesario. Esto se debe a que esta sitio tienen puertos “militarizados” por niveles de seguridad.

NOTA:

En este bloq vamos a entregar todo un sistema "Punto de Venta" hecho en java desktop distribuido. Esto quiere decir que, correremos la aplicación via Java Web Star y el cliente podrá operar el sistema como si estuviera corriendo localmente. Sin embargo, las transacciones y procesos serán hechos por distintos y diferentes servlets y servicios web que a medida vayamos entrando en el tema veremos la tecnologia. La idea es la siguiente. Estamos cansandos de tanta bibliografia y manuales del usuario de JAVA y nunca podemos salir de hacer pequeñas clases de algoritmos, numeros primos, factoriales. etc. A nosotros los mortales queremos acceder a bases de datos, grabar, recuperar, sacar informes y reportes eso es lo que nos da trabajo y dinero para vivir. Bueno, entonces la mejor manera de aprender es en la misma realidad. Por ello voy a proponer un sistema que es difícil de hacerlo en web (ahora parece que todo es web, pero ni google cree que es así y me remito a las pruebas de ANDROID, este sistema operativo va a reemplazar todo lo que hoy conocemos como WEB).