(XSD) INCLUDE vs (XSD) IMPORT

Tanto en los proyectos SOA donde existe la necesidad de orientar la arquitectura a nivel de servicios, como en las exposiciones de sistemas Legacy y Virtualizaciones de Servicios por medio de OSB, en todos estos proyectos nace la necesidad de desarrollar servicios de tipo Web Service. Ahora, durante el diseño de dichos Web Service lo primero que se requiere hacer son los contratos de servicio (.wsdl), ahora nace aquí el problema ¿cómo los diseño?..., por medio de una IDE o manualmente, en mi caso yo recomendaría inicialmente apoyarse en una IDE como JDeveloper o Eclipse que manejan editores que facilitan de algún modo su creación, posteriormente cuando ya tengan práctica y como yo acostumbro hacer, por rapidez y conocimiento, es definir una plantilla base y desde ultraEdit aplicar replace a los nombres estándar de: wsdl:definitions, Namespace, xsd:element, wsdl:message, wsdl:binding, wsdl:service, wsdl:port, soap:address, wsdl:part, wsdl:operation. Así mismo, la edición del modelo de negocio dentro: wsdl:types.

Jústamente, aquí es la idea de este post, ya que es recomendable NO embeber el modelo por medio de los: wsdl:types, dentro de las interfaces: .wsdl. Aquí se genera la gran duda de muchos profesionales que es: ¿Cómo lo manejo con Include o con Import?, ¿Cual es la diferencia de ambos?, y que así nomás no se encuentra su explicación. La diferencia es la siguiente:

xsd:include: 

Se debe usar cuando se requiere manejar los datos de un .xsd con un mismo Namespace.

xsd:import:  
Se debe usar cuando se requiere manejar los datos de un .xsd con un diferente Namespace. 

Esto quiere decir que la gran diferencia entre ambos en a nivel de como uno diseñe su contrato de servicio, específicamente a como segmentará .wsdl y .xsd's con relación a sus Namespace.

Procederé a explicar mejor por medio de un dummy de un diseño que he creado para su mejor entendimiento, este consiste en un .wsdl y tres modelos .xsd:

ObtenerTecnologia.wsdl, este es el contrato de servicio el cual se ha diseñado para que NO se alterado y/o modificado posteriormente. Maneja un Namespace definido como: http://pe.com.eai.dummySOA/bean/obtenerTecnologiaWS, y segmenta su modelo de negocio de manera externa a el, por medio de un xsd.include ya que manejará el mismo Namespace: 

[xsd:include schemaLocation="./ObtenerTecnologia.xsd" /]

ObtenerTecnologia.xsd, es el modelo principal y base del contrato, este se ha diseñado para manejar un mismo contrato que dicho contrato: http://pe.com.eai.dummySOA/bean/obtenerTecnologiaWS. Así mismo, desde el se referenciará a los demás modelos .xsd que se han creado:

- Persona.xsd: la referencia con relación a este modelo, será por medio de xsd.include: [xsd:include schemaLocation="./Persona.xsd" /], ya que dicho .xsd SI manejará el mismo Namespace:  http://pe.com.eai.dummySOA/bean/obtenerTecnologiaWS

- Auditoria.xsd: la referencia con relación a este modelo, será por medio de xsd.import: [xsd:import namespace="http://pe.com.eai.dummySOA/bean/auditoria" schemaLocation="./Auditoria.xsd" /], ya que dicho .xsd NO manejará el mismo Namespace (ya que este modelo será REUTILIZABLE entre diferentes proyectos). El NameSpace que manejará será: http://pe.com.eai.dummySOA/bean/auditoria

Persona.xsd, es el modelo donde será definido los campos embebidos en los objetos: simpleType, complexType, relacionados directamente al negocio que el servicio implementado utilizará.

Auditoria.xsd, es el modelo donde será definido los campos de auditoría especificamente, embebidos en los objetos: simpleType, complexType, que serán REUTILIZADO en diferentes proyectos (modelos).  

Finalmente, con esto se completa la explicación del post. Para los interesados en el diseño explicado, pulsar aquí:
http://www.mediafire.com/download/l152h524h6l2rrb/xsd.include++VS++xsd.import.zip