Existe una funcion en oracle que puede ser utilizada para hacer el split, que es tan comun en lenguajes de programación, esta es regexp_substr. La diferencia con un split normal es que esta te extrae solo el principio de la cadena, a menos que establezcas otra posición de comienzo.
Enel ejemplo
select regexp_substr( 'una cadena','[^ ]+') from dual
Se extraera ‘una'(entiendase qu despues del simbolo ^ hay un espacio).
Complementando información anteriormente dada, el string e conexion a RAC de Oracle también se define en el caso de SQL Developer, pero como una configuracion avanzada. O sea, se debe establecer de esta forma para llagar al RAC
Como aqui puedes ver en la configuracion estandar no puedes cambiar el string de conexión, por lo que es necesario la avanzada.
Yo creo que SOA más que una evolución natural de las TI fue una necesidad. Muchos alumnos me preguntan más de una vez porque las empresas tienen distintos sistemas para lo mismo, bases de datos de clientes no consolidadas, cosas en donde la teoría nos indica que esta mal pensado o mal construido.
La verdad es que los negocios se mueven por si solos, y obligan a que la tecnología se adapte. O sea, muchas veces cuando una multinacional llega a un pais elige a una o mas empresas para comprar, cada una de las cuales tiene lineamientos TI distintos, lo que implica que luego de la compra hay que proveer recursos para fusionar bases de datos, eliminar productos por el licenciamiento, etc.
SOA aqui llega como ayuda para que todas estas integraciones puedan provocarse, para TI el argumento debe ir por
Reuso. O sea, crear nuevos procesos de forma rápida.
Composición. La capacidad de alterar un proceso de negocio de forma rapida y rentable.
La capacidad de cambiar un sistema incrementalmente. Cambiar de proveedores, extender servicios, modificar proveedores y consumidores de servicios.
La capacidad de construir un sistema incrementalmente. Esta es una de las bondades de SOA.
Pero quiero ir más alla, creo que convencer a TI no es lo díficil, sino que en un plano gerencial, responder a la pregunta ¿porque SOA? no tiene los mismos argumentos, pero si la misma raíz.
Reducción de costos en el desarrollo de sistemas. Si la empresa se orienta a los servicios una de las primeras cosas que debe definir son los datos empresariales, obligando a la empresa a conocerse a si misma. Lo que provoca un estudio de los procesos de negocio. Teniendo esto como base, la inserción de un nuevo sistema será con un menor costo, ya que los procesos serán conocidos y las estructuras también
Reducción del ‘Time to market’. El reuso de servicios empresariales, además de la reutilización de las entidades empresariales (o datos de empresa) reducen el tiempo de desarrollo de un nuevo sistema, debido a que este se adhiere a las normativas creadas, pero además reutiliza servicios se negocio o procesos de negocio, logrando una sinergía de sistemas.
Procesos de negocio adaptable a cambios. Uno de los aplicativos muy ligados a SOA son los BPM (Bussiness Process Modeler), para quienes hemos trabajado con estas herramientas, la posibilidad de tener un repositorio de servicios granular posibilita la construcción de procesos de negocio de forma rápida es más cercana cuando existe una implantación de SOA bien manejada. Además de una creación rápida, las modificaciones son tanto más rapidas que permite una mejor adaptación a los negocios.
Mejora en la experiencia del Cliente. El tener mejores procesos, poder tener la capacidad de ofrecer servicios multicanal, debido a la reutilización tecnológica, cae a través del tiempo en una mejor percepción de los clientes a los cuales está focalizado el servicio.
Ahora bien, para implantar SOA debes seguir ciertos pasos. No esperes pasar de un día para otro a SOA si no existen definiciones de negocio claras, creo que el primer paso de una empresa es conocerse a sí misma (en cuanto a datos y procesos) antes de querer hacer algo.
La verdad sea dicha, carecemos de recursos ilimitados para poder probar aplicaciones en ambientes ni siquiera similares a los que poseen nuestros clientes, esto solo existe para productos más consolidados. Por lo mismo hay que buscar las estrategías necesarias para que en un servidor quepan multiples instancias y así rentabilizar más los recursos.
Cuando se habla de multiples instancias estamos hablando de que JBoss se puede configurar para correr en más de un puerto, una explicación bastante buena esta en un blog de una compañía argentina Avant Garden Technologies. Con este artículo podrás tener multiples instancias de JBoss, aun cuando el único reparo que debo hacerle es que el cambiar por «fuerza bruta» los puertos Sí funciona, yo lo pude hacer cuando aun no entendía bien como funcionaba el tema de las instancias, ellos indican lo contrario. Aun así ellos entregan con argumentos conceptuales y practicos para poder establecer más de una instancia.
Pero llegue al punto en donde tengo una aplicacion que debo mantener multiples versiones. Aun cuando tenga multiples instancias algunas configuraciones se solapan. Es posible mantener en multiples instancias multiples datasources debido a que esta dentro de la carpeta deploy. Pero muchas veces requieres leer un archivo especifico, que debes colocar en una ruta externa a JBoss, para lo cual te vales del CLASSPATH de Java… y ahí existe un problema cuando deseas ejecutar distintas versiones de la aplicación en el mismo servidor, no importando que tengas multiples instancias el CLASSPATH para JBoss es único, para todas sus instancias, por lo que se te provocan algunos problemas.
La aplicación lee un archivo de propiedades x.properties, este archivo esta ubicado en alguna parte dentro del CLASSPATH si tu deseas modificar una llave de este archivo la modificarás para ambas versiones de la aplicación, y eso no es lo que ando buscando, sino que cada aplicación lea su propio properties. Inicialmente hice que la version de producción leyera x.properties y la version de qa y.properties, pero nos paso la cuenta el control de versiones, en donde estos archivos son distintos por lo que las nuevas llaves creadas en y.properties no eran traspasadas a x.properties siempre, con los inherentes problemas de ejecución.
Ahora bien, la exigencia de que el properties este fuera de JBoss (el servidor de aplicaciones) es un petición del cliente, es más solucionable si esto estuviese dentro, debido a que cada instancia vería su ambito solamente.
Entonces como habían dos CLASSPATH excluyentes lo que hice fue copiar la carpeta JBoss completa, y con las multiples instancias ya aplicadas fue hacer un
/usr/local/jboss/bin/run.sh -b 0.0.0.0 -c default
y un
/usr/local/jbossqa/bin/run.sh -b 0.0.0.0 -c qa
Y así tuve dos instancias de JBoss con la misma aplicación y distinta versión, apuntando a distintos CLASSPATH
Es importante para cada uno ver como ocupa el tiempo, más si estas en ingenierías donde el tiempo es un bien escaso. Bien es cierto que por mi parte utilizo conceptos de PSP (Personal Software Process) para gestionar mi tiempo, existen personas que hacen mucho más que yo y el tiempo les alcanza y les sobra.
Por lo mismo es interesante compartir un articulo (una traducción) de Martin Marsavsky que es un inversor en nuevas tecnologías además de dirigir más de una compañía… lo ideal es que solo trabaja de 9 a 14hrs.