XML Standards for XML-Message based integrations (Oracle SOA).
Background:
- Now a days, majority of the enterprise integration solutions (especially that are using SOA design patterns) and packaged ESB applications such as Oracle's SOA/OSB/BPM, SoftwareAG's Webmethod, TIbco's ActiveMetrix, IBM's Websphere, Mule's MuleESB and many more are are extensively using XML based configurations and messages to integrate different kinds of heterogeneous applications.
- So, standardizing the XML-Model is one of the key-success criteria in designing the SOA based integration solutions.
XML Message/Schema Standards
- Always define the definition of an xml message in hierarchical pattern. example: xml structure for an employee in finance department should follow : <department><finance><employee>xxxx</employee></finance></department>, instead <dep_fin_emp>xxx</dep_fin_emp>.
- Where ever possible, use elements rather attributes. There is always a debate whether to use attributes or elements to represent the properties of an object. Using elements (instead attributes) provides more flexibility to extend the properties of that object/element. Here the main point is - element can easily extendable, where as attribute is not. Example: extending <department><name>xx</name><rev>xx</rev><exp>xx</exp></department> causes lesser cost than changing <department name="XX" rev="xxx" exp="XXX"/>. Reason: Elements are more flexible than attributes, particularly when it comes to writing extensible schemas, as you can always add additional elements to an element. However, once an attribute has defined, it cannot be extended any further.
- Always follow a specific pattern to name the xml elements and attributes. Meaning, either follow the camelcase or simplecase but not both. Example: use either xxxXXX or xxx_XXX but not both patterns (there is nothing harm in using both, but it looks ugly especially when you expose your service to external world).
- If you are defining types (complex or simple types) then always post-fix name with "type" for better readability . Example <complexType name="employeeType"> .. </complexType>
- Always keep Elements and attributes name between 12 char to 15 char length.
- Always tend to use real-life objects for Element names. Example: use employee, party, partner, address, user, status etc for element names., instead prefix with company or product names. example : use <item><type>engineering</type> .. </item> instead <enggItem> .. </enggItem>
- Always define schema with a target namespace. Namespace is equivalent to a package name in plsql and java programming languages. This approach provides better readability and clarity on the elements that are using in the messages.
- Where ever possible, use Qualified element and attribute names in the XML messages. This approach provides clarity on what namespace an element belongs to, and removes the confusion or ambiguity and provides the context in which an element is defined.
- Namespace should follow http://org.<<your company name>>.com/<<domainname>>/<<xsd or wsdl>>/<<functional area>> example: http://org.ppk.com/purchasing/xsd/order
- Preferably, try to define element types (complex or simple types) and use it while defining the elements (messages) instead creating the local elements. Example: use <xsd:schema ...> <complexType name="employeeType"><sequence><firstname type="xxx"/><lastname type="xxx"/></sequence></complexType> and refer this type in the element <department><employee type="employeeType"/></department> instead <department><firstname type="xxx"/><lastname type="xxx"/></department>. This approach provides modularity and reusability in defining the XML Elements and messages.
- Preferably, try to construct a canonical model based on multiple, reusable and logical schema models. Example: avoid creating a single schema definition abc.xsd by "including" sales.xsd, employee.xsd, order.xsd, finance.xsd, though it provides single namespace and easy development. Instead "import" required schemas to create a name space for your particular domain/project (just like importing required packages in a java classes).
- For Oracle SOA (SOAP) based message integrations, due to the limitations defined by WS-I , preferably choose document style binding with the combination of Document Wrapped style (with this approach, the request and response parameters for an operation are wrapped within a single request and response element). This ensures that the SOAP body only contains a single nested element who name matches that of the operation.
- Make sure that, all the canonical schemas and common xml types stored/procured in a common repository from where all the SOA projects (Oracle SOA Projects) shares/references these schemas and types appropriately. In my next blog, I will provide more details on common-repository (MDS) setup and usage.
XML Standards for XML-Message based integrations (Oracle SOA).
Background:
- Now a days, majority of the enterprise integration solutions (especially that are using SOA design patterns) and packaged ESB applications such as Oracle's SOA/OSB/BPM, SoftwareAG's Webmethod, TIbco's ActiveMetrix, IBM's Websphere, Mule's MuleESB and many more are are extensively using XML based configurations and messages to integrate different kinds of heterogeneous applications.
- So, standardizing the XML-Model is one of the key-success criteria in designing the SOA based integration solutions.
XML Message/Schema Standards
- Always define the definition of an xml message in hierarchical pattern. example: xml structure for an employee in finance department should follow : <department><finance><employee>xxxx</employee></finance></department>, instead <dep_fin_emp>xxx</dep_fin_emp>.
- Where ever possible, use elements rather attributes. There is always a debate whether to use attributes or elements to represent the properties of an object. Using elements (instead attributes) provides more flexibility to extend the properties of that object/element. Here the main point is - element can easily extendable, where as attribute is not. Example: extending <department><name>xx</name><rev>xx</rev><exp>xx</exp></department> causes lesser cost than changing <department name="XX" rev="xxx" exp="XXX"/>. Reason: Elements are more flexible than attributes, particularly when it comes to writing extensible schemas, as you can always add additional elements to an element. However, once an attribute has defined, it cannot be extended any further.
- Always follow a specific pattern to name the xml elements and attributes. Meaning, either follow the camelcase or simplecase but not both. Example: use either xxxXXX or xxx_XXX but not both patterns (there is nothing harm in using both, but it looks ugly especially when you expose your service to external world).
- If you are defining types (complex or simple types) then always post-fix name with "type" for better readability . Example <complexType name="employeeType"> .. </complexType>
- Always keep Elements and attributes name between 12 char to 15 char length.
- Always tend to use real-life objects for Element names. Example: use employee, party, partner, address, user, status etc for element names., instead prefix with company or product names. example : use <item><type>engineering</type> .. </item> instead <enggItem> .. </enggItem>
- Always define schema with a target namespace. Namespace is equivalent to a package name in plsql and java programming languages. This approach provides better readability and clarity on the elements that are using in the messages.
- Where ever possible, use Qualified element and attribute names in the XML messages. This approach provides clarity on what namespace an element belongs to, and removes the confusion or ambiguity and provides the context in which an element is defined.
- Namespace should follow http://org.<<your company name>>.com/<<domainname>>/<<xsd or wsdl>>/<<functional area>> example: http://org.ppk.com/purchasing/xsd/order
- Preferably, try to define element types (complex or simple types) and use it while defining the elements (messages) instead creating the local elements. Example: use <xsd:schema ...> <complexType name="employeeType"><sequence><firstname type="xxx"/><lastname type="xxx"/></sequence></complexType> and refer this type in the element <department><employee type="employeeType"/></department> instead <department><firstname type="xxx"/><lastname type="xxx"/></department>. This approach provides modularity and reusability in defining the XML Elements and messages.
- Preferably, try to construct a canonical model based on multiple, reusable and logical schema models. Example: avoid creating a single schema definition abc.xsd by "including" sales.xsd, employee.xsd, order.xsd, finance.xsd, though it provides single namespace and easy development. Instead "import" required schemas to create a name space for your particular domain/project (just like importing required packages in a java classes).
- For Oracle SOA (SOAP) based message integrations, due to the limitations defined by WS-I , preferably choose document style binding with the combination of Document Wrapped style (with this approach, the request and response parameters for an operation are wrapped within a single request and response element). This ensures that the SOAP body only contains a single nested element who name matches that of the operation.
- Make sure that, all the canonical schemas and common xml types stored/procured in a common repository from where all the SOA projects (Oracle SOA Projects) shares/references these schemas and types appropriately. In my next blog, I will provide more details on common-repository (MDS) setup and usage.
No comments:
Post a Comment