Tuesday, March 22, 2011

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


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


  • 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


  • 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


  • 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


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

No comments:

Post a Comment