Geeks With Blogs
Paul's Petrov Whiteboard [BizTalk, Enterprise Application Integration, Business Process Automation, SOA, .NET]

BizTalk 2006 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 is quick and easy way to expose business logic. It’s somewhat similar to the way of creating web services in .NET where you design component, decorate it with WebService and WebMethod attributes and the rest is done for you by the framework. Same is here - developer doesn't have to deal with actual message schemas and service definitions. The workflow is as simple as:

1)     Create orchestration and
2)     Publish orchestration as a web service

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 as Web Services is a logical choice when designing services top-down. It gives more flexibility in terms of defining messaging schema exactly the way you want it. In this case, workflow would be:

1)     Define messages in XML Schema
2)     Publish schemas (BizTalk generates wsdl) and generate service stubs from service definitions
3)     Implement service internals (orchestration)
4)     Bind orchestration once it’s ready to the published endpoint

Instead of relying on whatever BizTalk generates based on the orchestration you define how the service will look to service consumers. Clients can start coding against contract as soon as schema is published while you go about implementing service logic independently. Stubs generated out of definitions can be used to mock-up solution and bound to test harnesses helping in early integration testing. You can potentially create more interoperable service because of the control over the message schema. You won’t automatically gain anything in terms of performance but it’s possible to optimize messages.

I put “potentially” and “possibly” everywhere because in the current implementation it doesn’t come for free. BizTalk web publishing wizard doesn’t strictly follow contract-first development so you have to do some manual work to get all benefits out of this approach. I’ll expand more on this in the next posts to follow.

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

As we see, deciding which approach to take depends on many factors: scale of the solution, scope of the service, dependencies, time and resources constraints, etc. Generally, publishing schemas is a good way for designing services but it has an extra overhead.

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
Posted on Tuesday, March 21, 2006 2:39 PM BizTalk , EAI | Back to top


Comments on this post: Choosing Web Services Publishing Model in BizTalk 2006

# re: Choosing Web Services Publishing Model in BizTalk 2006
Requesting Gravatar...
VEry good article
Left by Tony Thomas on Nov 09, 2011 10:07 PM

Your comment:
 (will show your gravatar)


Copyright © Paul Petrov | Powered by: GeeksWithBlogs.net