Orchestration VS Schemas as a Web Service (BizTalk Web Services Publishing Model)

BizTalk Web Services publishing wizard offers two options: Publish orchestrations and Publish schemas as a web services. What is the difference and when should we prefer one to another? Below are some practical considerations that may help one to decide.

Publishing Orchestrations

Pros:

• Short development cycle, well suited for agile iterative development
• Easy to use and understand by developers
• No special XML Schema, WSDL skills needed

Cons:

• Limited control over the message schema, no flexibility to optimize it
• Poor collaboration model - can't share service contract among parties until it's stable
• Weak interoperability control
• Encourages bottom-up design approach, as the result is a high chance of tight coupling services and overall poor solution design that doesn’t scale and is not truly “service oriented”

Publishing Schemas

Pros:

• Encourages top-down contract-first approach that enables designing true service oriented solutions
• Emphasis on message helps designing better messages aligned with business processes
• Gives control over the message schema
• Opens opportunity to share service contract among participants in collaborative development
• Potential to create more interoperable services
• Possibility of optimizing service performance
• Isolated services development and easy iteration over stabilized schema

Cons:

• Requires skilled developers who know XML Schema, understand WSDLs and appropriate tools
• Longer initial design phase, difficult to conduct iterations before schema is stabilized because of manual work involved
• Poor implementation of WSDL generation, manual tweaking of service description required
• Limited toolset to support development process

Summary:

Publishing schemas as web services is the choice to consider when:

• Designing top-down contract-first global scoped services (for example, consumed from outside of the enterprise boundaries, i.e. B2B)
• When designed service should follow existing or given service contract, for instance some standard industry schema
• No or little control over service consumers, change management is difficult or impossible
• Large complex solutions with high number of dependencies
• Collaborative development involves multiple parties sharing the same service contract
• Interoperability is a major concern
• Project timeline allows time for thorough messaging schema design
• Developers available with XML Schema and WSDL skills

Publishing orchestrations is a way to go when:

• Implementing simple solutions with small number of dependencies when we have control over both consumer and service endpoints
• Rapid prototyping, proof-of-concepts, service stubs
• Developing local scoped services, when collaboration is not an issue
• Don’t care much about interoperability
• No skilled XML Schema, WSDL developers available