To a BizTalk developer, you design applications based on message flow. A message goes in one port, and comes out another. What happens in between is completely black box. Simple.
BTS 2004 is the most service-oriented product that MS ships, at least according to the four tenets.
The beauty of BTS is that the architecture is based on SO, but grounded in reality. It acknowledges that SAP, Peoplesoft, etc., exist and cannot be ignored through it's flexible adapter architecture. So BTS offers an SO future while connecting you with past investments.
BTS has no illusions about the whole message vs. object debate, which drives some of us to the
edge of madness. ;-) With BizTalk, it's about messages. Period.
In fact, the only place object-based APIs come into play is when you export an orchestration as an ASMX Web service. Then you get an object-graph injected in the middle when you really don't need it. I've recently exchanged some emails with
James Saull, who is doing a lot of work with BTS 2004 lately. He noticed that all ASMX does in this case is add an extra layer of wierdness that doesn't add any value whatsoever, before things get handed off to the orchestration. So he's been building an .ashx-based WS integration layer that removes the need for objects altogether. In
this post, he explains why contract-first is such a good fit in the BizTalk integration world. Here's an interesting excerpt:
A large scale integration project often means you will encounter an environment where vast and multitudinous schema have been published (government, insurance, petrochemicals, pharma etc.). The BizTalk solution takes the form of a system sending and receiving messages composed of "types" from these schema. For example the insurance industry has two standards Origo and Accord. Both contain vast schemas detailing all the industry types and even message flows. Therefore the design of an SOA system will include message design and then the WSDL. The WSDL will define services based on these pre-defined types from these schema (such as a "policy" or a "customer" etc.). Once the WSDL has been built all the different parties involved can begin developing simultaneously against the contract in .Net or Java or KSH scripts and PERL if you like.
If you tried to do this the other way around you'd be in a world of pain. Trying to build your services in C# or Java and then auto-exporting your WSDL in the hope that the C# types will magically map to the industry defined schema types and service definitions. This would just be tilting against the windmill!
In the BizTalk world, we already have a Service Oriented mindset. We communicate in terms of schema-defined documents; we offer up services not APIs. We want to be interoperable with as many people as possible. I don't care whether you're using Java, .NET or ARM assembler - if you can send me a soap message, I'll talk to you. The trouble is that the .NET world approaches web services from a very object-y view point.
It's so refreshing to communicate with developers working with BTS, because they seem to be coming at the problem from a completely different perspective, and the right one I might add. ;-)
I think I may need to spend more time with BTS... I may feel more at home there.
Posted
Nov 11 2004, 06:54 PM
by
Aaron Skonnard