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.