TALLER DE CAPACIÓN ORACLE SOA SUITE 12c

El presente post es brindado para dar detalles por el servicio de capacitación enfocado al equipo de (programadores, arquitectos, funcionales, etc) de las diferentes empresas deseosas en iniciar y/o tener conocimiento con relación al manejo de la plataforma Oracle SOA Suite 12c, (OSB, BPEL) tanto en teoría como práctica.

La capacitación se deberá brindar en las instalaciones del cliente, quien deberá proveer el ambiente propicio para la capacitación.

El servicio de capacitación seguirá al 100% el sílabus propuesto y compartido por el expositor. Así mismo, los interesados en el contenido del sílabus con la cotización respectiva, escribir a:

- Email:         cesarricardo_guerra19@hotmail.com
- WhatsApp: 997541831

Cesar Ricardo Guerra .A.

http://www.linkedin.com/pub/cesar-ricardo-guerra-arnaiz/28/8b2/225

CONSIDERACIONES EN LA APLICACIÓN DE 'TIMEOUT'.

En esta oportunidad tocaré un punto importante que es el 'Control de TimeOut' aplicado en el desarrollo SOA, este tema rinde un papel muy importante ya que hace referencia al delimitante de tiempo aplicado a los BE (BackEnds).

(BE: "Hace referencia a toda Interface de comunicación reutilizada como: BD, WS, EJB, PLATAFORMA, etc, que no forma parte del desarrollo principal").

Explicándolo de una manera más detallada, cuando se desarrolla un servicio independientemente del tipo que sea: SOAP/REST o EJB, es importante que exista un 'Control de TimeOut' obligatoriamente con relación a todos los BE (Síncronos) que son parte del flujo del 'Servicio Principal'. 

Resalto esto ya que en mi experiencia me he encontrado con todo tipo de servicios: Bien, Mal y Pésimamente construidos. Así mismo, en muchos de estos servicios mal construidos estaban usualmente enfocados en sus flujos a exponer una 'Lógica de Negocio', pero sin aplicar un control relacionado a los BE.

¿QUE IMPLICA QUE LOS BE, NO TENGAN TIMEOUT?.

El impacto es por ejemplo que ante un problema interno propio del BE, este demore más de lo normal incluso quedarse como se dice pegado y si no hay un 'Control TimeOut', el hilo de la ejecución se quedará ahí esperando hasta que el término de procesamiento del y eso está mal (ya que no puede durar eternamente). 

El impacto va contra el tiempo de respuesta del 'Servicio Principal', el cual justamente como RNF (Requisito No Funcional), un servicio consumido debería cumplir con un tiempo de procesamiento máximo.

¿COMO SABER CUANTO TIEMPO DEBERÍA ASIGNAR?.

Así los servicios sean muy rápidos, el tiempo a aplicar se debe se estimar en segundos y es dependiendo el tamaño del flujo existente, así como de la cantidad de las iteraciones contra BE que se requiera. Pero analizando en si no es bueno que un servicio tenga internamente más de 10 BE dentro de su flujo, ya que si se tiene más lo mejor es segmentar en otro servicio. Sobre el tiempo se podría aplicar un tiempo máximo por BE entre 10 y 15 seg.

¿Y QUE HAY DE LOS REINTENTOS?.

Los reintentos son tratamientos que deben de ser considerados también para los BE, pero para los que analizando de alguna manera son inestables (se caen cada cierto tiempo), o también sus respuestas algunas veces demoran más de lo normal, etc. Los reintentos se debe activar ante alguna Exception de tipo Técnica de tipo: 'No Dispobilidad', 'Error en BE', 'TimeOut', etc.

En estos casos se recomienda aplicar un Máximo de Reintentos de 3 veces, luego de estos retornar el response con la falla. Así mismo, es importante considerar que el TimeOut debe ser es incremental, que por ejemplo ante cada reintento del mismo BE el TimeOut se debe duplicar:

Ejemplo:

• Reintento#1 => TimeOut => 5 seg.
• Reintento#2 => TimeOut => 5 seg. 
• Reintento#3 => TimeOut => 5 seg. 

Esto quiere decir que sí tenemos un 'Servicio Principal' que por ejemplo llama solo a 1 BE con 3 reintentos de 5 seg. La ‘aplicación consumidora’ debería considerar asignarle al consumir el: 'Servicio Principal', un mínimo de tiempo de: 16 seg. 

¿Y QUE HAY DE LAS 'HUMAN INTERVENTIONS'?.

Lo conocido como 'Human Interventions’ son Políticas enfocadas a un control diferente (normalmente trabajadas de la mano con los 'Rententos'), por ejemplo para casos en que los servicios son de tipo Asíncronos y los flujos llaman a BE reutilizables. Así mismo, el manejo de 'Human Interventions’ normalmente son soportadas por servicios directamente relacionados a plataformas SOA de vendors como ORACLE / IBM.

Su aplicación se realiza con apoyo del negocio identificando los casos especiales con relación a BE que se requieren controlar de manera diferente. La política está enfoca a que ante alguna Exception de tipo Técnica como: 

'No Dispobilidad', 'Error en BE', 'TimeOut', etc. El hilo del flujo se queda en un estado especial, hasta que un operario se conecte a la plataforma, identifique dicho estado, revise la excepción, mande a corregirla y luego de estabilizarla, procesa a desde donde se cayó manualmente relance el mensaje al BE y el hilo del flujo continúe. 

Finalmente contra de la aplicación de 'Human Interventions', es justamente la necesidad de un operario, que producirá una demora considerable en el proceso, debido a ello su aplicación debe estar de la mano con la coordinación con el negocio.

Espero que este artículo les sirva para más adelante cuando se escuche la palabra Timeout se le considere con más seriedad de la que normalmente se le tiene.

MODELO DE DATOS: 'CANÓNICO'

Este modelo consiste en definir atributos estándares y sus respectivas características, diseñados a nivel de entidades. Esto con la finalidad de la reutilización de esta información a nivel de los contratos de servicio, evitando de esta manera cualquier tipo de duplicidad en los datos.

El objetivo es que el modelo canónico proporcione los formatos de intercambio de datos del negocio, de manera que todos los componentes (servicios, aplicaciones, etc), sólo necesiten saber (como máximo) su propio formato de datos y el formato de datos predeterminado (el que comparte dentro del bus de servicio), ya que el modelo canónico de mensajes tambien representa el formato estándar utilizado para intercambiar información de negocios en un bus de servicio.

Dicho modelo está enfocado en la aplicación dos patrones:

- SCHEMA CENTRALIZATION.
- CANONICAL SCHEMA.

Dando solución a los PROBLEMAS siguientes:

¿Cómo pueden los contratos de servicio ser diseñados para evitar la definición de datos redundantes?.

Esto se refiere específicamente al contenido de los esquemas redundantes (muy comúnmente) y/o mal diseñados que en si son difíciles de gobernar.

¿Cómo pueden los servicios diseñarse para evitar la transformación del modelo de datos?.

Esto se refiere e impacta directamente a servicios con esquemas diferentes, con datos similares (Redundantes) y que requieren de transformación, con esto aumenta el esfuerzo de desarrollo, la complejidad del diseño y la sobrecarga de rendimiento en tiempo de ejecución, ya que el objetivo es llegar a la Interoperabilidad  intrínseca (de manera natural). 

La SOLUCIÓN sería:

Crear y seleccionar esquemas existentes físicamente separados del contrato de servicio (.WSDL), ya que justamente la representación más común que se utiliza para el modelo canónico mensaje es un conjunto de esquemas XML. Esto tiene la ventaja de hacer el tipo y definiciones de mensajes (esquemas) con el fin de reutilizarlos y compartirlos entre varios contratos.

Un modelo de datos canónico es conjunto definido de tipos, elementos, atributos y relaciones que representan las entidades de negocios, estas están justamente basadas en los requerimientos del negocio para el proyecto SOA. Los modelos de datos (esquemas) deben estar estandarizados (Modelo Canónico) a nivel de entidades, almacenado y versionado por medio de alguna herramienta que permita centralizar todo el Modelo Canónico (MDL) de entidades, para que ante algún requerimiento de información por parte de un servicio dentro del contrato se importe la referencia a la entidad y se reutilice el dato requerido. Esto evitará cualquier tipo de redundancia de información, problema de transformación a nivel de Xsd, etc.

¿Cómo diseñar un MDL?

Dependiendo de cuan grande sea la empresa puede que ya tenga algunos modelos de referencia (para las Telecomunicaciones existe SID-TM Forum, etc.).  La idea es tener un modelo base inicial para poder trabajar y que se ajusta a las necesidades, al cual se puede complementando con más entidades en base al levantamiento de información que se realice. Aquí están algunas ideas sobre cómo lograr un buen modelo conceptual MDL (muy similar a cualquier otro modelo de datos):

- Validar si se seguirá algun modelo base del modelo canónico (como SID).
- Enumerar todas las entidades principales que requiere su empresa (cliente, pedido, etc.).
- Relacionar las entidades.
- Especificar los atributos de las entidades.

TeleManagement Forum (TMF) han definido un conjunto de cuatro marcos conocidos colectivamente como Frameworx. Los marcos clave proporcionan un valor empresarial que son el 'Marco de la Información' (SID) y el 'Marco de Procesos' (eTOM). Ambos pueden ofrecer una mayor agilidad en los negocios. Dichos modelos SID representan el ejemplo más importante de los esfuerzos puestos en desarrollar formas eficientes de compartir información entre sistemas de telecomunicaciones. Incluso, el SID debe convertirse en el lenguaje que SOA proporcione como vocabulario, gramática y sintaxis base que utilicen los servicios para proporcionar o recibir información. Así mismo, se debe de asegurarse de que todo el tráfico de mensajes a través de la ESB esté alineado SID, así el esfuerzo necesario para integrar los servicios se reducirá drásticamente así como también se reducirá los costos de mantenimiento respetivamente.

Por otro lado, una contra que se debería tener en consideración es que ante algún cambio en el 'tipo/tamaño' del dato perteneciente a la entidad, se debe de considerar que esto impactará en las ‘N’ aplicaciones que reutilizan dicha entidad (por medio de sus Xsd), y en las otras ‘N’ aplicaciones consumidoras que también reutilizan en sus comunicaciones.

¿Cómo implementar un MDL?

Para implementar un MDL como ya se ha mencionado se debe de diseñar, modelar y relacionar las entidades de negocio, para esto uno se puede apoyar en herramientas empresariales como Enterprise Architect (Sparx), que permitira diseñar desde un Diagrama de Clases 'UML', poder modelar las entidades y a si mismo y generar en base al diagrama de clases, esquemas .XSD y clases .JAVA.

El Modelo Canónico de las entidades completo puede ser diseñado exportado y reutilizado en los para cada servicio dentro de sus contratos respectivamente:

Tal como se mencionó durante el desarrollo de un Servicio Web la idea es reutilizar el Modelo Canónico estandar dentro del Contrato tal como se puede apreciar en la imagen:

Finalmente, una de las cosas más importantes que se debe también hacer, es educar a la empresa en el uso del MDL, y las ventajas a largo plazo de la misma. La gente a menudo no se enfocan a largo plazo y prefieren optar un enfoque más pragmático para resolver los problemas que se enfrentan sin tener en cuenta el impacto de la misma en el futuro.

Para los intersados se pueden descargar los archivos utilizados desde aquí:

Modelado:
http://www.mediafire.com/download/zkfz3x3xazkrci6/XSD_Model_Generator.zip

Wsdl/Xsd:
http://www.mediafire.com/download/n2lbxbnxnk40i24/ModeloCanonico_Dummy.zip

Weblogic Overload Error ...

Es importante saber que Weblogic internamente maneja un pool de conexiones por cada DataSource (XA / NOXA), que es creado en su entorno. Normalmente este DataSource al ser creado se le asigna un soporte automático de 15 hilos (paralelos) de conexión (capacidad máxima), los cuales se irán liberando conforme a su correcto uso.

Para la simulación de este error Overload en Weblogic se ha preparado un Dummy en Java que se conectará por medio de un JNDI de Weblogic a un Store Procedure y lo estresará de diferentes maneras para poder obtener dicho escenario de error.

Este error típico de Weblogic se puede dar si es que se incurre en alguna de las dos formas siguientes .........

Los interesados pueden descargar el artículo completo desde aquí: http://www.mediafire.com/download/6be8xbna38qa65x/Weblogic_Overload_Error.pdf

Para descargar las fuentes del Dummy (Eclipse): http://www.mediafire.com/download/d425dsgkgfmqm33/Dummy_JNDI_Overload.zip

APACHE JMETER (Enfoque WS)

Un tema muy importante durante los proyectos de tipo SOA, son las pruebas unitarias que se le hagan durante las construcción de los servicios. Aquí se podrá verificar que tal fluye la lógica de negocio  plasmada y como la arquitectura definida del servicio es tan robusta como para poder distribuir bien, rápida y correctamente la información. Así mismo, en muchas de estas pruebas es muy importante medir resultados lo que se conoce como tps (transacciones por segundo), entre otros resultados estadísticos, que son necesario ya que al tenerlos uno podrá validar que la velocidad y el rendimiento del servicio son los ideales. Aquí nace la necesidad de una herramienta que facilite dicha tarea de prueba.

Apache JMeter es un proyecto de Apache que puede ser utilizado como una herramienta de pruebas unitarias para analizar y medir el desempeño de servicios especialmente las de tipo aplicaciones web, así mismo soporta aserciones para asegurarse que los datos recibidos son correctos y brinda una variedad de reportes.

Con dicha herramienta se podrá obtener también automáticamente gráficas atractivas y significativas de nuestro resultado con las cuales se podrá analizar más rápidamente resultados de las pruebas e incluirlas el en un informe requerido. Además, se puede utilizar para realizar un análisis gráfico de rendimiento o para probar el comportamiento de respuesta del servidor bajo gran carga concurrente.

El siguiente tutorial mostrará justamente una parte de todo lo que esta herramienta brinda, que es el enfoque de como configurar y justamente cómo estresar un Servicio Web utilizando esta herramienta. Así mismo, se están cubriendo detalladarmente los siguientes puntos:

- Requerimientos.
- Instalación.
- Configuración y Prueba.

Para descargar este tutorial paso a paso ingresar aquí:
http://www.mediafire.com/download/03m0w2k8kefhiii/Tutorial+Apache_JMeter_v2.0.pdf

BENEFICIOS DE MANEJAR VARIOS DOMINIOS

Un dominio de Weblogic Servidor (WLS), es una unidad administrativa perteneciente a un Servidore de Aplicaciones. Asi mismo, sólo un administrador debería de tener conocimiento de dominios existentes.

Actualmente una empresa puede tener diferentes tipos de aplicaciones dispersas geográficamente y organizadas en diferentes áreas. Debido a ello, puede existir muchos dominios separados. Pensando en ello si analizamos cada dominio es una unidad que se administra por separado y se puede organizar dicha administraciónde manera departamental dentro de una empresa (contabilidad, manufactura, transporte, etc).

Por otro lado, una empresa puede querer tener todas sus aplicaciones en diferentes dominios que puedan ir incorporando. Debido a que a menudo es imposible ampliar uno solo dominio para abarcar el total de aplicaciones de toda la empresa. Así mismo, se debe considerar que teniendo un solo dominio a nivel empresa, acarrearía el ser administrado en su conjunto y la configuración se convertiría casi imposible de manejar y requeriría un esfuerzo mayor en la administración que en el desarrollo e implementación de las aplicaciones propiamente.

Finalmente, para mantener un correcto dominio (segmentado / distribuido) para la administración, se debe de separar las aplicaciones en 'multiples dominios' permitiendo que las aplicaciones en un dominio, puedan acceder a los servicios en otros dominios. 

CENTRALIZAR INICIO DE SERVERs

Muchos de nosotros que trabajamos en nuestros ambientes con muchos servidores de aplicaciones, contenedores de servlets, etc, de diferentes vendors y con diferentes dominios creados por cada uno, tenemos la necesidad de que por cada escenario que queramos probar, tengamos que conocer la ruta donde Iniciar y/o Detener cada uno de estos Servidores. Así mismo, mientras más de estos tengamos más difícil será que nos acordemos las ubicaciones de ellos.

Una solución común a este problema es tener un .txt con todas las rutas como informativo por medio de un acceso directo en nuestro escritorio. Otra es ir a inicio/windows/NOMBRE_SERVER/... , pero si nos ponemos a pensar son muchos pasos los que se deben realizar constantemente. Analizando estos casos como informático debemos innovar con una mejor solución para este problema común.

Para ello la solución pensada y planteada es: Centralizar todas estas ubicaciones de rutas de servidores en un archivo .bat que como se menciona centralice y en base a una orden Inicie y/o Detenga los Servidores requeridos. Para ello haremos lo siguiente:

1. Se debe crear un archivo .bat de la siguiente manera:

2. En el 1er cuadro en Rojo se definen el menú que se visualizará para seleccionar.

3. En el 2do cuadro en Rojo se matricula las letras definidas en el 1er paso, según el orden, para el Choise correspondiente.

4. En el 3er cuadro en Rojo se ingresar los IF's correspondientes a las Letras anteriores y que invocarán a LABELs por cada configuración a crear más a abajo:

5. Se crearán  la configuración por cada LABEL un bloque con la DOMAIN_HOME y en base a esta, las variables: COMANDO_START y COMANDO_STOP para los controles respetivos. Esto se deberá realizar por cada configuración nueva que se requiera hacer:

El resultado de esto es un herramienta que centralizará todos los acceso al inicio de los servidores de manera facil e intuitiva y que hará que uno ya no se preocupe de este problema común. En este caso se puede apreciar una variada gama de servidores entre los que resaltan: SOAUITE. OSB, Tomcat, ETOM, etc ...

Para los interesados pueden descargar el .bat desde aquí:
http://www.mediafire.com/download/p76ttp6ppry6or2/Iniciador_Servidores.zip

TRANSFORMACIONES DE FORMATOS CON 'MFL' EN OSB

Usualmente en BPEL se acostumbra utilizar el 'File Adapter' para leer archivos NO XML y transformarlos a formato XML, pero en OSB junto con el adaptador de archivos también existe otra forma NO muy conocida de realizar dicha tarea. Esta se conoce como MFL y la podemos utilizar para transformar datos NO XML a datos XML y viceversa.

En este post se procederá a mostrar cómo transformar los datos NO XML a datos XML utilizando MFL. Para mostrar este funcionamiento, se ha preparado un dummy de un Servicio Virtual que consistirá en lo siguiente:

"Se ingresará una trama (Formato: NO XML) en una ubicación específica, que será procesada por el OSB. Esta trama procederá a ser transformada en formato XML para ser enviada de Request contra el WS. El Response del WS será transformado a formato NO XML (Trama), para ser finalmente depositado en una ubicación de salida como archivo generado".

DUMMY:

1. Considerando que la Trama INPUT tendrá este formato y será ubicado en una ruta local (especificada en el Proxy Service más adelante):

2. Definir y crear una RUTA BASE, que contendrá 4 directorios:

- TEMP: Directorio encargado de procesar los archivos de manera temporal.

- ERROR: Directorio encargado de almacenar los archivos con error en el proceso.

- INPUT: Directorio donde se ubicarán las tramas a procesar.

- OUTPUT: Directorio donde se generarán las tramas de respuesta del proceso.

3. Definir la estructura de directorios de muestro proyecto OSB:

4. Creamos un BusinessService que referencie y controle por medio del WSDL incrustado en el proyecto al WebService: 'http://localhost:8090/mockDatosClienteService?wsdl',(Un MockServices que he iniciado por medio de SOAPUI):

5.  Crear los archivos MFL (sobre el proyecto: new/MFL), tal como se explicó por medio de estos archivos se configurarán las transformaciones NO XML a XML y XML a NO XML. Con esta lógica ya podremos definir el MFL INPUT: encargado de transformar TRAMA a REQUEST y el MFL OUTPUT: encargado de transformar RESPONSE a TRAMA:

Para esto se debe de conocer antes de definir las tramas, los datos REQUEST/RESPONSE del WS a consumir:

5.1. Crear el archivo: DatosCliente_IN.mfl, para la transformacion INICIAL,considerando la configuración mostrada considerando los valores de los DELIMITADORES, sobre todo el del salto de linea del campo final (\n):

5.2. Crear el archivo: DatosCliente_OUT.mfl, para la transformacion FINAL, considerando la configuración mostrada considerando los valores de los DELIMITADORES, sobre todo el del salto de linea del campo final (\n):

6. Crear los XQuery consideranto las transformaciones que se manejaran:

6.1.  DatosCliente_IN.xq: Encargado de transformar la Trama (NO XML) hacia el REQUEST del WS: 

6.2.  DatosCliente_OUT.xq: Encargado de transformar la el RESPONSE del WS hacia la Trama (NO XQML) a generar:  

7. Crear un BusinessService de tipo Messaging Service que referencie y controle un MFL (Trama):

Definir el directorio donde se generarán las tramas de respuesta (OUTPUT) al finalizar procesamiento:

 

Definir parte del nombre de los archivos que se generarán para cada procesamiento, así mismo la extensión de los archivos de salida propiamente:

8.  Crear un ProxyService que controle los mensaje INPUT (Trama), que se dejarán en la ruta configurada:

Definir la ruta INPUT donde se depositará la trama:

Configurar tiempo, intervalo, formato y directorios (rutas) de control con relación a las tramas INPUT:

Creamos desde Message Flow los nodos que soportarán el funcionamiento del Servicio Virtual:

Con esto tenemos el Servicio Virtual completado, para las pruebas simplemente bastaría con depositar la trama INPUT en el directorio definir y automáticamente el flujo del Servicio Virtual se activará y a nivel de consola se visualizará el resultado:

PRUEBA:

1. Ubicar la trama en la ruta INPUT definida (C:\Ficheros\MFL\INPUT):  

2. El Servicio Virtual en un tiempo determinado procesará el mensaje (Trama):

3. Finalmente, por cada registro en la trama se generarpa y consumirá un REQUEST del WS y así mismo generará un archivo OUTPUT por cada RESPONSE:

Para los interesados se pueden descargar las fuentes del Dummy (OSB 11g - '11.1.1.7') desde aquí:  http://www.mediafire.com/download/fdz82c149nt8yfq/DummyNoXml_To_Xml.jar

SEGMENTACIÓN EN DISEÑO DE .WSDL

Todos sabemos que la importancia que tiene en el ciclo de vida SOA la interface .WSDL, esto debido a que es el 'Description Language' de los Web Service y porque es el punto de acceso expuesto para la comunicación entre todos los servicio de tipo Web Service.

Debido a ello, es importante que durante la etapa de diseño uno se dé el tiempo debido en diseñar un correcto archivo .WSDL, de preferencia ya sea por medio de una herramienta o si se tiene práctica a mano, pero definir un buen diseño, considerando el posterior Topdown que se realizará.

En esta oportunidad mostraré como crear un .WSDL basado en un diseño segmentado "no común", pero altamente recomendado en los escenarios en que se requiere definir un .WSDL con gran cantidad de capacidades (operaciones) dentro de este.

Los modelos clásicos para diseñar un .WSDL (v1.1) son los siguientes:

 _ Un solo archivo .WSDL que contenga todo en su interior: (types (complexType, simplexTypes), message, portType, binding, service).  

_ Un archivo .WSDL que contenga en su interior: (message, portType, binding, service) y un archivo .XSD que contenga en su interior: (types (complexType, simplexTypes) ). El .WSDL import ó include el .XSD.  

_ Un archivo .WSDL que contenga en su interior:  (message, portType, binding, service), un archivo .XSD que contenga en su interior el modelo de datos propio de todas las operaciones: (types (complexType) ), un archivo .XSD que contenga datos 'genéricos' entre todas las operaciones. (types (complexType, simplexTypes) ). El .WSDL import ó include el .XSD propio y este import el .XSD genérico. 

Estos modelos de diseño de .WSDL son los conocidos y según el orden van mejorando el diseño propiamente. Así mismo, existe un modelo aún mejor pero que no es tan aplicado, este modelo de diseño se basa en segmentar la interface .WSDL de las operaciones en sí, haciendo que cada operación maneje su propio .WSDL y que exista un .WSDL principal. En otras palabras el diseño sería de esta manera:

_ Un archivo .WSDL (principal) que contenga en su interior:  (portType, binding, service), varios archivos .WSDL (según el número de operaciones existente) que contenga en su interior:  (message y types (complexType) propios de la operación), un archivo .XSD que contenga datos 'genéricos' entre todas las operaciones. (types (complexType, simplexTypes) ).  El .WSDL principal import todos los .WSDLs según el número de operaciones existentes y cada uno de estos .WSDL secundarios import  el .XSD genérico.

La ventaja de este modelo de diseño de .WSDL, es que está enfocado en las operaciones y hará al momento del Topdown respectivo que las clases .java (por ejemplo), se autogeneren en directorios independientes por cada operación respectivamente. Esto hará que no exista riesgo en el problema clásico de la duplicidad de clases usadas por cada operación al momento del Topdown:

La relación entre archivos es a nivel de NameSpace, debido a ello es bueno que se defina un correcto estándar en lo relacionado a los nombres, ya que en base a esta definición, se creará el orden de los directorios luego del Topdown respectivamente. Así mismo, todo lo demás es un juego de imports entre los archivos definidos:

- Archivo .WSDL (principal):

- Archivo .WSDL secundario por operación (Operación#1):

- Archivo .WSDL secundario por operación (Operación#2):

- Archivo .XSD genérica: 

Para los interesados en utilizar este tipo de modelo de diseño de .WSDL, pueden descargarlo desde aquí: http://www.mediafire.com/download/8nl9nuv6tmnpqr9/DisenioSegmentado_Wsdl.zip

ANÁLISIS SOA: [TOP-DOWN / BOTTOM-UP]

En muchas empresas NO se les da la importancia debida al trabajo del Rol: 'Analista SOA', es más en muchas empresas este Rol ni exíste. Este es un error grave, ya que la tarea que realiza dicho Rol es en si la base de toda Arquitectura SOA, debido a que el resultado de dicho análisis ('modelado y arquitectura orientada a servicios') que estos profesionales hagan, definirá los 'Servicios Candidatos' que posteriormente se verán reflejados como base en el Inventario de Servicios (con relación a los ‘servicios compuestos’).

Cuales son las consecuencias de un incorrecto Análisis SOA: que los servicios base en el inventarios de servicios NO sean altamente reutilizables (en muchos casos NI existen), que exista rebundancia constante a nivel de codificación en los procesos, que se creen servicios compuestos por crear, problemas con la gobernanza y el posterior mantenimiento de cada servicios, etc. Y lo peor es que el impacto es incremental a media que el inventario de servicios va creaciendo.

Actualmente, existen algunos enfoques SOA (ejemplo: SOMA y MSOEM) que definen un conjunto de técnicas para identificación de 'Servicios Candidatos'. Dichas metodologías SOA, tienen muchas cosas en común, ya que existen entre los resaltantes dos caminos posibles: TOP-DOWN y BOTTOM-UP.

- Técnica BOTTOM-UP:  

La cual se enfoca en realizar un análisis, para la obtención de los servicios candidatos, partiendo de  las aplicaciones y/o sistemas legacy (antíguas) ya existentes en los cuales los procesos de negocio no están definidos.

- Técnica TOP-DOWN:

La cual se enfoca en realizar un análisis, para la obtención de los servicios candidatos, partiendo de los procesos de negocio (si no se tienen estos, deben ser obtenidas del Feedback de los 'Analistas Funcionales' y modelando los BPMN respectivos). Descomponiendo dichos áreas funcionales, en proceso de negocio en  hasta llegar a procesos, subprocesos y tareas. Es importante recalcar que esta técnica descompone los elementos del nivel más bajo de la granularidad.

Así mismo, se debe tener en claro que todo el proceso de negocio tarde o temprano tenderá a ser un TOP-DOWN (es recomendable), de lo contrario no se llegara a una Arquitectura SOA ideal, donde IT esté alineado al negocio.

Por otro lado, se debe tener claro que este enfoque de análisis debe ser iterativo, ya que no se debe de querer hacer desde el inicio TODA la descomposición del total de los procesos existentes en la empresa. Es recomendable hacerlo por partes, en base a los procesos principales a medida que los requerimientos vayan saliendo. Esto debido a que los servicios serán altamente modificables y apuntan a la reutilización, por lo que se debe analizar por partes los procesos de negocio de la empresa, para definir y formalizar los primeros Servicios Candidatos base del Inventario de Servicios. 

Finalmente, para su posterior investigación los enfoques más resaltantes actualmente son:

- SOMA (IBM).
- MSOAM (Thomas Erl).

Particularmente, prefiero la segunda, pero se pueden complementar.