It is important to understand that as soon as you filter by wide industry support, there are only a few core standards in Web services - XML, SOAP, UDDI and WSDL. The only other standards that are currently widely adopted and supported are WS-Security and BPEL4WS. Most of the confusion is created by marginal specifications and protocols that rely on the standards to determine some form of additional functionality like security or transaction processing.
These are necessary though. It's not as simple as the standards that define a nut and bolt or the width of train track. In order to truly define any architecture that is complex yet retains services orientation, there are going to be a lot of moving pieces. The reality is that a business or a developer only has to adopt the ones that are relevant to what they are doing. No project will ever encompass all of the standards, and the reasons for using them will remain personal and objective.
If you were building a parking garage, you would never have to adopt all of the building code requirements for a high-rise. However, some would apply. And those would be ones that most closely resemble the role of XML and SOAP. Even UDDI is a personal choice.
I expect that not only will the existing standards and protocols continue to exist and be used in the future, but that we'll also see the emergence of even more marginal standards come into play. For example, standards for presentation of media (music and video), government specific standards, and vertically focused standards for manufacturing, logistics, etc. could all be overlaid on the base that exists today. This would allow software architects and engineers to easily consume and reuse each other's work and ensure that within defined business geographies there are clear working guidelines for business groups and partner chains.
If you understand the core standards, you are 90 percent done. If you understand how the core standards work together you are 95 percent done. The others simply come into play as needed. And if everyone follows the model we are using at Microsoft, then they should be readily available as classes or patterns and practices within the tools, platforms and support environments of your chosen vendor.
Dig Deeper on Topics Archive
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.