All things are permissible, but not all things are beneficial; when developing an XML Schema, this is a good rule of thumb. XML Schema provides many options for developing robust, flexible data structures. One such option is the ability to define nested content model definitions.
All XML elements have a content model. A content model defines the validation rules and structure of an element’s content. Element content can consist of character data, child elements, or a mixture of both. In the cases where an element contains child elements, a content model is used to define the order, cardinality and presence of the child elements. Continue reading
(This is the third in a series of articles that attempts to expose some of the more common mistakes and misunderstandings people make when implementing a SOAP Web Service.)
This is somewhat related to the previous post about trying to be too flexible. However, usually this problem is accidental, where the previous was intentional. This problem also is usually the result of misunderstanding or misusing a Web Services development tool.
XML has an element type called “any.” It basically means, “Anything that is valid XML is OK here.” It’s a way to make your document more flexible without the burden of defining type extensions. It should be used very sparingly though, because the point of a structured data format like XML is to define a structure for a piece of data. When you use the “any” element, it completely ignores that point and allows any structure.
One cause of this problem is misuse of a Web service tool. There are many tools available to ease your creation of Web services. There are tools for most programming languages where you can hand it a business object, and it will generate a WSDL that defines an XML version of that object, and even the code to handle transferring it and converting it into the actual object. You just then need to write the code that does the real work. The tool does all the mundane communication work. Continue reading
(This is the second in a series of articles that attempt to expose some of the more common mistakes and misunderstandings people make when implementing a SOAP Web Service.)
XML is a quite flexible data format. It allows the user many options, such as Choices, Sequences, Complex Types, Type Extension. But the flexibility can very easily be overdone. While it may seem like a good idea to have your service be flexible, it also makes using the service that much harder to use because of all the different formats that need to be handled.
A good example of taking flexibility too far is the SalesForce.com Web Services interface. It takes the idea of Type Extension to the absolute extreme. For those not familiar with Type Extension, see this tutorial. Type Extension can be very useful when you have types that are mostly similar, with just a few extra attributes added onto the extended types. For example, a good usage could be a personnel data model. Continue reading
In my last blog, I talked about UDDI (Universal Description, Discovery and Integration) including where it’s been and where it might be going. In this article I’m going to take a different look at UDDI and consider the question, how useful is it to find what you’re looking for? One aspect of UDDI that has been overlooked by OASIS (Organization for the Advancement of Structured Information Standards), the Web Services standards body, is how to find services faster and more efficiently.
UDDI allows service providers to publish data about themselves and their Web Services, and supports simple searching for services. The standard UDDI search uses a single search criterion, such as business location, business name, service type by name, business category or business identifier. This limits the efficacy of UDDI for general service discovery. An example is searching by business category; the search might return the service you want, but you might need to filter the results to find it. Continue reading
Many considerations must be assessed when deciding on a standard format for exchanging information electronically with trading partners. Two of the more widely used document standards are Electronic Data Interchange (EDI) and Extensible Markup Language (XML). Of course, when doing business with buyers and larger partners it is generally necessary to comply with the requirements of those trading partners. However, it is good practice, and demonstrates good business sense, to be proactive and develop an in-house (internal) data specification (and format) that will provide an option for smaller partners to comply with.
Questions must be answered before best decisions can be made for your needs. Continue reading