login      my ps      about      contact  



home instructor-led training on-demand screencasts blogs


The Tripping Point » The siren song of Biztalk

The siren song of Biztalk

Biztalk seems increasingly attractive to me. I believe XML is an incredibly powerful tool for building loosely-coupled dynamic systems (like MSDN2). Biztalk embraces XML messaging directly and so appears to be a very welcoming place, at least for people like me. Of course Indigo also offers XML messaging, but it is hidden behind RPC-style invocations and object marshaling layers. When I talk to members of the Indigo team about this, they're always quick to point out that the system is layered such that I could strip away the object layer and deal with XML messages if I want to (but who would want to?). Somehow, I always leave those discussions feeling like an angle-bracket loving freak. Yes, I can get to what I want if I'm willing to do a bunch of extra work. In short I'm using Indigo in a supported, but non-standard way. Welcome on board, your seat is at the back. In contrast, with Biztalk, my approach to the world appears to be front and center. I won't just be tolerated, I'll be welcomed by people who share my world view. Samples will focus on XML messaging, not hiding XML behind methods and objects because it's too ugly to look at (do you take some sort of pleasure in it?). There will be tools for creating schemas and transforms, and for slicing and dicing data the way I want to. The only real downside I see is that Biztalk is too heavy for many (smaller?) applications that can still benefit from XML messaging. To solve that problem, I'll probably rip the head of the Indigo stack and replace it with one that really does what I want, including a transform pipeline and version-aware dispatching model. It's a tribute to Indigo that it's flexible enough to do that. In fact, the Indigo guys have added the main things I've asked for to make living my perferred lifestyle possible. But I'd like to live in a place where my lifestyle is not just enabled but actively embraced. And I wonder if Biztalk is it.

Posted Jun 10 2005, 08:01 AM by tim-ewald

Comments

Randy Holloway Unfiltered wrote Is BizTalk right for you?
on 06-10-2005 6:01 PM
Tim Ewald: "Biztalk embraces XML messaging directly and so appears to be a very welcoming place, at least for people like me." BizTalk does a good job of enabling web services while coexisting with other older XML-based messaging applications....
Simon wrote re: The siren song of Biztalk
on 06-11-2005 7:55 AM
But, IMHO, the next (n+?) version of BizTalk will (should) rely on Indigo for its transport. I see Indigo as the API, or the Runtime for WS-*, and BizTalk as the service or the server built on top of this API. Just like in the database space where BizTalk rely on SQL Server for storage and persistence, why couldn't it rely on Indigo in the transport space?

Simon.
David Ing wrote re: The siren song of Biztalk
on 06-12-2005 12:53 PM
Hi Tim,

http://www.from9till2.com/PermaLink.aspx?guid=7b3fb590-2d76-4496-867a-b4ceac210fc9

I'd bet good money you don't subscribe, so here's my thoughts on BT and the choices we have.

- David
Scott Seely wrote re: The siren song of Biztalk
on 06-13-2005 12:32 PM
Tim-- I'm surprised you don't fall back to the argument that DataSet/RecordSet loving folks have been able to just get at the results that are returned as a result of a SQL query and have been able to build big fancy systems on this principal for years (decades?). In the same way, you want to build big, fancy systems that look at the XML and do smart things.

Your not an angle-bracket loving freak.

I think a more interesting discussion is along the lines of how to build robust systems that do take any old XML. The biggest issue in the past with DataSets is that many folks tend to write code that expects the records to come back in a certain order with particular names and sizes.
Dion Hinchcliffe wrote Angle Brackets vs. RPC-like Handcuffs
on 06-14-2005 9:27 AM
Tim,
I'm with Scott Seely. Building services with loose coupling that take "any old XML" is high value. And *hard*, given the patterns and tools we have today.

I'm been exploring the boundaries of native XML service interaction, loose-coupling, and contract-checking instead of code generation on my blog, with some intriguing results so far if you're interested.

And I agree, you're not a angle-bracket loving freak. :-)
Steve Swartz wrote re: The siren song of Biztalk
on 06-22-2005 5:58 AM
One of the things I like about Indigo is that processing XML documents and objects is equally high-level. Methods dealing with documents and objects can be mixed on the same contract, so you can have:

[ServiceContract] interface IFoo
{
[OperationContract(IsOneWay=true)] void DoObj (int x);
[OperationContract(IsOneWay=true)] void DoXML (Message m);
}

The cool thing about this is that the Indigo feature set (security, reliability, transactions, queuing, instancing, etc...) works exactly the same with both sorts of methods. DoXML() is not a lower layer than DoObj(); it's a different way of passing data at the (top) ServiceModel layer.

I think we (as an industry) have a lot of experience with early [DoObj()] and late [DoXML()] binding. I agree with what I take to be the thrust of your larger argument: the cost of early binding increases as reach and therefore the cost of coupling increases. Indigo is intended to be used by a variety of people in a range of situations, so it offers both early and late binding. I hope we can learn to present those options in a less partisan way. I'm sorry we haven't so far.
Faisal Waris wrote The siren song of Biztalk
on 06-27-2005 1:04 PM
I am glad that the industry is moving towards message-oriented mindset however only a little creativity is required to use the current WS toolsets in a message-oriented way.

At AIAG (NA auto industry vertical) we ran into the problem that our OAGIS-based schemas were so complex that none of the WS toolsets being used could handle the XML-to-code binding.

The solution was to use 'loosely-typed' WSDL to get the message data as XML (DOM) which could then be processed via the platform-specific native XML apis.

Here is an example of a schema from the 'loosely-typed' WSDL:

<xsd:complexType name="BOD">
<xsd:sequence>
<xsd:any namespace="##any" minOccurs="0" maxOccurs="unbounded" />
</xsd:sequence>
<xsd:anyAttribute />
</xsd:complexType>

<xsd:element name="SyncShipmentSchedule" type="aiag:BOD" />


To rigoursly define the interface contract, we also included the strongly typed WSDL in our package.

The bottom line is that WSDL is just a contract what you do to implement that contract is up to you as long as the contract is satisfied.

So to do message-oriented Web Services take an existing WSDL, create a loosely-typed version of it and feed it to your favorite WS tool.

Faisal

Errors and Omissions Excluded wrote Tim's Urge To Explore Biztalk More...
on 08-14-2005 9:19 AM

Add a Comment

(required)  
(optional)
(required)  
Remember Me?


home instructor-led training online training blogs

781.749.9238 (East Coast) | 310.251.9901 (West Coast) | Pluralsight, LLC , 185 Lincoln St., Suite 305, Hingham, MA 02043-1741

Copyright © 2008 Pluralsight LLC. All rights reserved.

designed by nukeation