Preguntas por Dimensión para SIMM

En uno de los artículos anteriores (SIMM) se examinó la matriz de madurez para SOA SIMM. Modelo que fue creado por Ali Arsanjani y Kerrie Holley el 20 de septiembre del 2005 en IBM donde expertos de IBM publicaron tutoriales, código de ejemplo, estándares y otros recursos para ayudar a desarrolladores de software.

El modelo SIMM consta de dimensiones y niveles de madurez. En este nuevo artículo publico algunas preguntas generales que deben ser contestadas en cada una de las dimensiones de SIMM.

Negocio:

1. ¿Cuáles son los mejores procesos de negocio para la iniciativa SOA?
2. ¿Cuál es la visión y los objetivos, y cómo están relacionados a lo que IT está actualmente haciendo?
3. ¿Está documentada, definida y gobernada la actual arquitectura de negocio?
4. ¿Es su arquitectura de negocio completa y moderna?
5. ¿Cómo se mide el retorno de la inversión?
6. ¿Qué tan agiles son los procesos de negocio?
7. ¿Cuáles son las actuales prácticas de financiamiento?
8. ¿Cuál es el actual costo modelo?
9. ¿Quiénes son los dueños del portafolio de procesos, aplicaciones y servicios?
10. ¿Existe un modelo de costo por el uso que los clientes hacen a los servicios?
11. ¿Como hace actualmente para definir el costo total de arrendamiento (incluido software, hardware y futuros mantenimientos)?
12. ¿Cómo son medidos los actuales servicios de negocios?
13. ¿Cuál es la actual práctica para transformar SLAs de negocio hacia SLAs de IT?
14. ¿Esta formalizada la arquitectura empresarial?
15. ¿Esta formalizado el gobierno de su arquitectura empresarial?
16. ¿Existen múltiples líneas de negocio? ¿Cada una de esas líneas tiene sus propios procesos?
17. ¿Se comparte información entre los procesos de sus diferentes líneas de negocio?
18. ¿Comparte servicios de las líneas de negocio con clientes, proveedores y socios?

Organización:

1. ¿Qué tipo de características son comunes en el grupo de IT?
2. ¿Cómo gobierna actualmente IT la arquitectura empresarial?
3. ¿Qué tan alineado esta IT con el negocio?
4. ¿Existen procesos para gobernar la arquitectura, están esos procesos documentados, si es así, son esos procesos usados como servicios?
5. ¿Existen roles y responsables relacionados a la ejecución de los procesos de negocio?
6. ¿Cuáles son las funciones y responsabilidades para quien gobierna?
7. ¿Cómo se debería describir el costo de mantenimiento de  IT?
8. ¿Qué tipo de entrenamiento SOA está disponible en la organización?
9. ¿Qué tipo de relación existe entre el grupo de desarrolladores de la organización y el grupo de infraestructura?
10. ¿Qué autoridades existen para gobernar la arquitectura?
11. ¿Se ha solucionado los problemas de comunicación entre los departamentos internos, socios y proveedores?

Métodos y Procesos: 

1. ¿Cuáles son las actuales practicas para manejar los requerimientos de sistemas o requerimientos de aplicaciones?
2. ¿Qué metodologías de diseño y mejores practicas están actualmente adoptadas?
3. ¿Se practica alguna técnica de diseño SOA?
4. ¿Cuáles son las practicas actuales para diseñar y manejar servicios?
5. ¿Cuál es el actual Framework para manejo de proyectos?
6. ¿Cómo están organizadas las personas que manejan los Proyectos de IT?
7. ¿Qué procesos de aseguramiento de la calidad tiene la organización?
8. ¿Existe un grupo activo que trabaja por mejorar los procesos y prácticas de SOA?
9. ¿Tiene la organización desarrollado un repositorio para mejores prácticas y reutilización de recursos?

  

Aplicación:

1. ¿Cuál es el actual estilo de desarrollo de aplicaciones?
2. ¿Cómo se reúsa los recursos o funciones comunes?
3. ¿Qué tipo de reutilización se realiza y cómo se mide la reutilización?
4. ¿Cómo se integran las aplicaciones y sistemas?
5. ¿Qué tipo de lenguajes de programación se utilizan?
6. ¿Qué tipo de tecnologías de integración se utilizan?
7. ¿Cómo está representada la lógica de negocio dentro de las aplicaciones?
8. ¿Qué tan seguras son las aplicaciones más importantes de la organización?
9. ¿Que tanto se usa XML?
10. ¿Cuál es la taza de cambios y requerimientos en las aplicaciones?
11. ¿Se están usando las tecnologías habilitadas por SOA, tales como ESB, compartimiento de datos, registro de servicios?

Arquitectura: 

1. ¿Cómo caracterizaría la actual arquitectura?
2. ¿Qué tipos de repositorios de datos utiliza la organización?
3. ¿Cuál es el estilo de comunicación estándar dentro de la arquitectura?
4. ¿Cómo se está cumpliendo con la integración en la actual arquitectura?
5. ¿Qué métodos se utilizan para desarrollar bajo la actual arquitectura?
6. ¿Cómo maduran las implementaciones de servicios?
7. ¿Qué tan extensa es la arquitectura actual?
8. ¿Qué principios de arquitectura definen su actual enfoque?
9. ¿Qué tan extensa y sofisticada esta el uso de Frameworks en la actual arquitectura?
10. ¿Cómo se realizan las decisiones de arquitectura?
11. ¿Hace uso la organización de referencias de arquitecturas?

  

Información:

1. ¿Hay un modelo de datos común entre todas las aplicaciones?
2. ¿Hay modelos de datos independientes para diferentes aplicaciones?
3. ¿Se utilizan reglas de mapeo para conversiones entre diferentes modelos de datos?
4. ¿Hay dificultad en mover datos entre una aplicaciones y otra? ¿Para todas las aplicaciones?¿Para solamente algunas aplicaciones?
5. ¿Cómo se intercambian los datos? ¿A través de API's? ¿Por XSD? ¿Por documentos escritos? ¿Por herramientas externas?
6. ¿Están los modelos de datos en forma de Modelos de Objetos de Negocio, comprensibles para el negocio, o como modelo de objetos de IT, comprensible únicamente por el grupo de IT?
7. ¿Los modelos de datos están definidos por un lenguaje que incluye taxonomías, ontologías u otra representación de alto nivel?
8. ¿Se mantiene un directorio global o base de datos de objetos, con identificadores globales? ¿O se tienen mecanismos para mapear esos objetos entre diferentes directorios o bases de datos? Son estos mecanismos electrónicos o manuales?  Son todos los objetos mapeados o solamente algunos de ciertas aplicaciones?
9. ¿Se tienen mecanismos para buscar objetos globalmente buscándolos por sus características?
10. ¿Cómo se completa la transformación de los datos entre las aplicaciones? Se está usando un ESB para realizar la transformación, utilizando API's o llamando a un webservice?
11. ¿Existe o está en desarrollo un Modelo de Información de Negocio para estandarizar datos, formatos de mensajes y conceptos entre todas las aplicaciones?

  

 Infraestructura:

1. ¿Qué directrices está usando actualmente la infraestructura?
2. ¿Cómo son derivados los SLA's de IT desde los SLA's del negocio?
3. ¿Cómo se está monitoreando y midiendo la calidad de los servicios?
4. ¿Se tienen SLA's sobre seguridad y privacidad? Como se está monitoreando y midiendo?
5. ¿Qué nivel de monitoreo se tiene actualmente? Que herramienta de gestión están utilizándose actualmente?
6. ¿Qué plataformas están actualmente en uso y que puedan ser integradas?
7. ¿Qué recursos están situados bajo versionamiento?
8. ¿Qué procesos de gestión de cambios se están utilizando?
9. ¿Qué herramientas se están usando para gestión de la configuración?
10. ¿Qué recursos son considerados como bienes de la organización?
11. ¿Cómo es su actual arquitectura operacional?
12. ¿Cómo soporta la arquitectura operacional los requerimientos no funcionales para aplicaciones y servicios?

Primer Simposio Nacional de Oracle Exitoso

El 15 de marzo del presente año se llevó a cabo el Primer Simposio Nacional de Oracle en las instalaciones de la Universidad Internaciones, dicho evento contó con conferencistas de talla nacional e internacional, variedad de temas y una audiencia muy heterogénea que va desde estudiantes hasta personas técnicas y de negocio. 

A continuación los participantes de uno de los dos salones:

El evento se llevó a cabo con mucho éxito, la empresa Sequal Solutions donó 3 medias becas las cuales se rifaron entre todos los participantes del simposio. A continuación la carta en la cual se donan estas becas.

Contamos con invitados especiales como Everest Medinilla y Rafael Cordón de Datum, Oscar García Colom de Xerox y Guillermo de León de CONCYT.

Tanto Anibal García, como yo, estamos muy satisfechos con éste evento y esperamos con muchas ansias el Segundo Simposio Nacional de Oracle, el cual lo programaremos para el próximo año, esperando contar con conferencistas invitados de Argentina y Venezuela.

Las fotos del evento están publicadas en el siguiente link:

https://www.dropbox.com/sh/ff6bqm2k7cgepmc/HR07I_qn8P

Las Presentaciones del evento están publicadas en el siguiente link (lamentablemente algunas presentaciones no fueron autorizadas para compartirlas):

https://www.dropbox.com/sh/7f4sy97mtgy5t4g/VjHJ3XDVNj

Agradezco mucho a todas aquellas personas y/o empresas que hicieron posible este Simposio, como SISSA S.A., SISOFT, Universidad InterNaciones y Sequal Solutions; los conferencistas: Augusto López, Ronald Vargas, Fabriccio Diaz, Julio Mendez, Juan René Simon, Joel Perez, Daniel Cacia.

¡Hasta el próximo año!

Conferencia SOA en Escuela de Postgrado USAC

El día sabado 16 de febrero tuve la oportunidad de poder impartir la conferencia "Service-Oriented Architecture SOA" en las instalaciones de la Escuela de Postgrado de la Universidad de San Carlos de Guatemala, los temas tratados fueron los siguientes:

Agradezco mucho la invitación del Ing. Luis Fernando Alonzo, instructor del curso "innovacion de tecnologias de informacion" en dicha Escuela de Postgrado.

A continuación algunas fotos del progreso de la conferencia:

Agradezco también a la Escuela de Postgrado por el reconocimiento que me dieron por mi participación:

Verificar datafiles corruptos

Estimados tecnólogos Oracle reciban un cordial saludo nuevamente desde Guatemala, como ustedes saben, un DBA se enfrenta diariamente a diferentes problemas con las bases de datos que administra, problemas de performance, de IO, de red, storage, CPU, etc., para poder encontrar  la solución a estos problemas, el DBA debe ir delimitando la causa, y es por eso que en esta ocasión veremos una manera fácil de verificar si una base de datos posee corrupciones.

Oracle provee desde la versión 7.3.2, una herramienta llamada DBVERIFY la cual es usada para lo siguiente:

• Validar corrupciones en  la cabecera de un datafile
• Cada Bloque de dato dentro de un Datafile tiene un "wrapper" en el cual se encuentra metadata de  dicho bloque, este wrapper también es validado en busca de corrupciones.
• Validar Consistencia en tablas e índices dentro de los datafiles.
• Desde la versión 8.1.6 también se validan todos los demás tipos de bloques, por ejemplo  bloques de segmentos rollback.

Una de las ventajas de esta herramientas es que puede ser ejecutada cuando la base de datos está abierta, esto en ambiente de producción es muy importante pues se evita downtime.

La herramienta es muy sencilla de utilizar y provee los siguientes parámetros de entrada:

FILE:               nombre del datafile que se verificará.

START:           Bloque inicial

END:               Bloque Final

BLOCKSIZE: Tamaño del Bloque

LOGFILE:       Una archivo de log en el que se escribirá el feedback de la operación.

FEEDBACK:   Muestra detalladamente el avance del proceso.

PARFILE:        Archivo de parámetro

USERID:         Usuario/Constraseña

Entre las limitantes que tiene esta herramienta  están las siguientes:

• No valida errores entre tablas e sus indices.
• Solo puede ser utilizada con datafiles, no redologs, ni controlfiles.
• dbverify puede ser usada para bases de datos en ASM, sin embargo, la base de datos debe estar abierta y el parámetro USERID debe necesariamente ser especificado.
• Los datafiles necesitan tener una extensión.
• No se pueden validar datafiles mayores a 2GB  en 8.1.6 por los bugs: 710888 y 1372172.

El uso de la herramienta es muy fácil, a continuación describo la manera de validar una base de datos completa:

Primero obtenemos el tamaño del bloque que se está utilizando en la base de datos mediante la siguiente consulta:

SQL> SELECT value  FROM v$parameter WHERE name = 'db_block_size';

VALUE

-----------------------------------------------------------------

8192

Ahora continuamos realizando un script con las sentencias necesarias para validar todos nuestros datafiles:

SET ECHO OFF

set heading off

set feedback off

spool validardb.sql

select 'dbv file=' ||file_name|| ' logfile=archivo_'||rownum||'.log  blocksize=8192' from dba_data_files;

spool off

exit

Verificamos que el archivo haya sido generado correctamente:

[oracle@soa1 ~]$ ls -ltr

-rw-r--r-- 1 oracle oinstall      5092 Mar  8 01:25 validardb.sql

El archivo debería quedar de la siguiente manera:

Le damos permisos de ejecución al script creado:

[oracle@soa1 ~]$ chmod 777 validardb.sql

Ejecutamos el script:

[oracle@soa1 ~]$ ./validardb.sql

DBVERIFY: Release 11.2.0.1.0 - Production on Fri Mar 8 02:33:01 2013

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

Verificamos la salida del archivo:

[oracle@soa1 ~]$ ls -ltr

-rwxrwxrwx 1 oracle oinstall      1718 Mar  8 02:32 validardb.sql

-rw-r--r-- 1 oracle oinstall       729 Mar  8 02:33 archivo_2.log

-rw-r--r-- 1 oracle oinstall       726 Mar  8 02:33 archivo_1.log

-rw-r--r-- 1 oracle oinstall       809 Mar  8 02:33 archivo_3.log

-rw-r--r-- 1 oracle oinstall       739 Mar  8 02:33 archivo_4.log

-rw-r--r-- 1 oracle oinstall       736 Mar  8 02:33 archivo_5.log

-rw-r--r-- 1 oracle oinstall       738 Mar  8 02:33 archivo_6.log

-rw-r--r-- 1 oracle oinstall       734 Mar  8 02:33 archivo_7.log

-rw-r--r-- 1 oracle oinstall       740 Mar  8 02:33 archivo_8.log

-rw-r--r-- 1 oracle oinstall       735 Mar  8 02:33 archivo_9.log

-rw-r--r-- 1 oracle oinstall       729 Mar  8 02:33 archivo_10.log

-rw-r--r-- 1 oracle oinstall       733 Mar  8 02:33 archivo_11.log

-rw-r--r-- 1 oracle oinstall       726 Mar  8 02:33 archivo_12.log

-rw-r--r-- 1 oracle oinstall       732 Mar  8 02:33 archivo_13.log

-rw-r--r-- 1 oracle oinstall       728 Mar  8 02:33 archivo_14.log

-rw-r--r-- 1 oracle oinstall       738 Mar  8 02:33 archivo_17.log

-rw-r--r-- 1 oracle oinstall       729 Mar  8 02:33 archivo_16.log

-rw-r--r-- 1 oracle oinstall       732 Mar  8 02:33 archivo_15.log

Escaneamos los archivos con extensión .log en busca de corrupción:

[oracle@soa1 ~]$ grep Failing  archivo*.log

[oracle@soa1 ~]$ grep Corrupt archivo*.log

[oracle@soa1 ~]$ grep Influx archivo*.log

La salida sería parecida a lo siguiente, en mi caso, la base de datos que estoy usando para realizar este articulo no contiene corrupciones:

[oracle@soa1 ~]$ grep Failing  archivo*.log

archivo_10.log:Total Pages Failing   (Data) : 0

archivo_10.log:Total Pages Failing   (Index): 0

archivo_10.log:Total Pages Failing   (Seg)  : 0

archivo_11.log:Total Pages Failing   (Data) : 0

archivo_11.log:Total Pages Failing   (Index): 0

archivo_11.log:Total Pages Failing   (Seg)  : 0

archivo_12.log:Total Pages Failing   (Data) : 0

archivo_12.log:Total Pages Failing   (Index): 0

archivo_12.log:Total Pages Failing   (Seg)  : 0

archivo_13.log:Total Pages Failing   (Data) : 0

archivo_13.log:Total Pages Failing   (Index): 0

archivo_13.log:Total Pages Failing   (Seg)  : 0

archivo_14.log:Total Pages Failing   (Data) : 0

archivo_14.log:Total Pages Failing   (Index): 0

archivo_14.log:Total Pages Failing   (Seg)  : 0

archivo_15.log:Total Pages Failing   (Data) : 0

archivo_15.log:Total Pages Failing   (Index): 0

archivo_15.log:Total Pages Failing   (Seg)  : 0

archivo_16.log:Total Pages Failing   (Data) : 0

archivo_16.log:Total Pages Failing   (Index): 0

archivo_16.log:Total Pages Failing   (Seg)  : 0

archivo_17.log:Total Pages Failing   (Data) : 0

archivo_17.log:Total Pages Failing   (Index): 0

archivo_17.log:Total Pages Failing   (Seg)  : 0

archivo_1.log:Total Pages Failing   (Data) : 0

archivo_1.log:Total Pages Failing   (Index): 0

archivo_1.log:Total Pages Failing   (Seg)  : 0

archivo_2.log:Total Pages Failing   (Data) : 0

archivo_2.log:Total Pages Failing   (Index): 0

archivo_2.log:Total Pages Failing   (Seg)  : 0

archivo_3.log:Total Pages Failing   (Data) : 0

archivo_3.log:Total Pages Failing   (Index): 0

archivo_3.log:Total Pages Failing   (Lob)  : 0

archivo_3.log:Total Pages Failing   (Seg)  : 0

archivo_4.log:Total Pages Failing   (Data) : 0

archivo_4.log:Total Pages Failing   (Index): 0

archivo_4.log:Total Pages Failing   (Seg)  : 0

archivo_5.log:Total Pages Failing   (Data) : 0

archivo_5.log:Total Pages Failing   (Index): 0

archivo_5.log:Total Pages Failing   (Seg)  : 0

archivo_6.log:Total Pages Failing   (Data) : 0

archivo_6.log:Total Pages Failing   (Index): 0

archivo_6.log:Total Pages Failing   (Seg)  : 0

archivo_7.log:Total Pages Failing   (Data) : 0

archivo_7.log:Total Pages Failing   (Index): 0

archivo_7.log:Total Pages Failing   (Seg)  : 0

archivo_8.log:Total Pages Failing   (Data) : 0

archivo_8.log:Total Pages Failing   (Index): 0

archivo_8.log:Total Pages Failing   (Seg)  : 0

archivo_9.log:Total Pages Failing   (Data) : 0

archivo_9.log:Total Pages Failing   (Index): 0

archivo_9.log:Total Pages Failing   (Seg)  : 0

[oracle@soa1 ~]$ grep Corrupt archivo*.log

archivo_10.log:Total Pages Marked Corrupt   : 0

archivo_11.log:Total Pages Marked Corrupt   : 0

archivo_12.log:Total Pages Marked Corrupt   : 0

archivo_13.log:Total Pages Marked Corrupt   : 0

archivo_14.log:Total Pages Marked Corrupt   : 0

archivo_15.log:Total Pages Marked Corrupt   : 0

archivo_16.log:Total Pages Marked Corrupt   : 0

archivo_17.log:Total Pages Marked Corrupt   : 0

archivo_1.log:Total Pages Marked Corrupt   : 0

archivo_2.log:Total Pages Marked Corrupt   : 0

archivo_3.log:Total Pages Marked Corrupt   : 0

archivo_4.log:Total Pages Marked Corrupt   : 0

archivo_5.log:Total Pages Marked Corrupt   : 0

archivo_6.log:Total Pages Marked Corrupt   : 0

archivo_7.log:Total Pages Marked Corrupt   : 0

archivo_8.log:Total Pages Marked Corrupt   : 0

archivo_9.log:Total Pages Marked Corrupt   : 0

[oracle@soa1 ~]$ grep Influx archivo*.log

archivo_10.log:Total Pages Influx           : 0

archivo_11.log:Total Pages Influx           : 0

archivo_12.log:Total Pages Influx           : 0

archivo_13.log:Total Pages Influx           : 0

archivo_14.log:Total Pages Influx           : 0

archivo_15.log:Total Pages Influx           : 0

archivo_16.log:Total Pages Influx           : 0

archivo_17.log:Total Pages Influx           : 0

archivo_1.log:Total Pages Influx           : 0

archivo_2.log:Total Pages Influx           : 0

archivo_3.log:Total Pages Influx           : 0

archivo_4.log:Total Pages Influx           : 0

archivo_5.log:Total Pages Influx           : 0

archivo_6.log:Total Pages Influx           : 0

archivo_7.log:Total Pages Influx           : 0

archivo_8.log:Total Pages Influx           : 0

archivo_9.log:Total Pages Influx           : 0

¿Bug con Generador de XSD en JDeveloper 11.1.1.5?

Hace unos dias estaba desarrollando unos servicios en BPEL utilizando JDeveloper 11.1.1.5 para un ambiente SOA 11.1.1.5 en un sistema operativo AIX.

Uno de las tablas  legadas en un AS400 en el cual el cliente necesitaba realizar inserciones, recibia para dos campos distintos un mismo valor, es decir, el mismo valor era enviado a dos campos de la tabla legada.

Se fabricó un servicio BPEL utilizando un DBAdapter. Se utilizó la característidca "Pure SQL"  con la que cuenta el DBAdapter en el que ingresando una tarea SQL , el motor genera automáticamente el XSD del "Insert". Se generó la siguiente sentencia:

Insert into tabla values (1,1, #parametro1, #parametro2, #parametro3, #parametro4, #parametro5, #parametro6, #parametro7, #parametro8, #parametro9, #parametro10, #parametro11, #parametro12, #parametro13, #parametro14, #parametro15, #parametro1)

Vean que el #parametro1 fué enviado dos veces.

El XSD fué generado exitosamente por JDeveloper. En lo personal, pensé que el XSD se generaría con 15 parametros ya que el parametro1 es utilizado dos veces. Consideré que el motor de JDeveloper vería este detalle. Sin embargo, mi sorpresa fué cuando el XSD generado por JDeveloper ¡¡tenía dos campos con el mismo nombre (parametro1) y con el mismo tipo de dato (integer)!!

Intenté utilizar el "segundo" #parametro1, en un elemento ASSIGN y después en un elemento TRANSFORM, tal como se muestra en la siguiente imagen:

Mi sorpresa fué que el "segundo" #parametro1 ¡¡no podía ser utilizado!! Generaba el siguiente error que se muestra en la imagen y después el mapeo era redireccionado al "primer" #parametro1!.

Conceptualmente, el motor de BPEL en JDeveloper no debería dejar generar dos campos del mismo nombre con el mismo tipo de dato en el mismo XSD.  Y tal como lo vimos, aunque dos campos fuesen permitidos en el mismo XSD , el segundo, no puede ser utilizado.

Entonces preguntó a mis estimados lectores: 

¿Es este comportamiento un Bug?

Caracteristicas de un Servicio SOA

Un servicio es descrito como un servicio genérico de negocio. En los Sistemas de Información (IT), un servicio es un elemento que encapsula una funcionalidad atómica, usado para soportar los servicios de negocio que la organización proporciona.  Típicamente un servicio es parte de un completo servicio de negocio en una organización.  En un ambiente computacional orientado a servicios, los servicios se convierten en bloques pre-construidos usados en la construcción de bloques más complejos que solucionarán una necesidad. Para ser útil, un servicio necesita proveer una funcionalidad que sea utilizada en varios procesos de negocio. El servicio necesita ser implementado en software y necesita ser desplegado y manejado. A la combinación de varios servicios para crear un proceso más complejo se le da el nombre de “orquestación”.

Todos los servicios SOA deben contar con las siguientes características:

Definido: El servicio debe ser definido en términos de qué es lo que hace. Los procesos de negocio en los que formaran parte, la interfaz que están usando para comunicarse con otros servicios. Cómo debe ser invocado el servicio. Los datos que el servicio da como resultado. Cómo debe ser manejado el servicio.

Implementado: El servicio tiene que estar implementado con algún software, es decir, debe estar construido o desarrollado.

Desplegado: Para ser usado, el servicio necesita estar disponible para ser usado por otros servicios.

Manejado: El despliegue del servicio debe estar a cargo de alguien quien controle las versiones y el mantenimiento del mismo. Que monitoreé que el servicio está disponible y que está cumpliendo las funcionalidades para las cuales se creó.

Reusable: Al proveer una definición del servicio, su funcionalidad, su interfaz, cómo debe de ser usado, etc., habilita la reutilización del mismo, es decir, puede ser usado en otro proceso de negocio donde su funcionalidad sea requerida.

Comunicación: Un servicio debe ser accedido mediante envió y recepción de mensajes en el estándar eXtensible Markup Languaje (XML).

Abstracción: El servicio debe ser usado mediante su definición únicamente. No se debe saber cómo está construido. Debe ser una caja negra.

Orquestado: Un servicio debe ser fácilmente orquestado para formar procesos más complejos.

Granularidad: La complejidad de un servicio puede sencilla o muy compleja. Entre más sencilla sea la funcionalidad mejor. Un servicio no debe encapsular funcionalidad compleja dentro de él, sin reutilización. Debe buscarse siempre alcanzar esa funcionalidad compleja mediante orquestamiento.

Desacoplamiento: Mientras un servicio dependa menos de otro servicio se dice que esta desacoplado. Los servicios SOA deben desarrollarse tomando en cuenta el desacoplamiento, de esta manera cuando se necesiten hacer modificaciones a un servicio, pocos o ningún servicio serían afectados.

Estado: El servicio para poderse ejecutar sus tareas óptimamente debería de mantener información sobre su estado y qué tareas está ejecutando, para que en base a esos metadatos pueda ser gestionado lo más adecuado posible.