Can BizTalk Convert Ordinary EDI Apps Into Web Services?

If you were blinking during the keynote presentations earlier this month at TechEd in Orlando, you might have missed this - for some in the audience who weren't blinking any more than normally, it still appeared to go right over their heads: In one demonstration, Microsoft's technical group product manager Mike Woods demonstrating something his boss, Bob Muglia, referred to as "service-enabling an application."

It sounds like one of those false-existential things you find Microsoft claiming it can do all the time, a sort of service-empowerment that enables people wherever they are to extend their connectivity while simultaneously expanding productivity in efficient, participle-producing ways. Remove that thin veneer from the subject, and you would have seen a guy condensing three years' worth of IT department development time into about one minute, forty seconds of busy work.

The tool Woods used was BizTalk Server Orchestration Designer, a snap-in for Visual Studio. Using Microsoft's well-worn simulated corporation, Contoso, he dragged and dropped an Electronic Data Interchange (EDI) document into the tool's workspace. Since EDI documents have specific structures with hard and fast rules of interaction - that's the whole point of EDI - BizTalk can extrapolate business rules in a fashion more appropriate to workflow, which consists of processes that can be mapped out using marked-up flowcharts.

In Woods' demonstration, an EDI document can represent a customer's purchase request. But how do we present that document with a way to signal the system that the requested item is not in inventory, using modern Web services rather than proprietary connectivity?

Or in Microsoft-speak, "How do you service-enable a process?" Woods asked. He then introduced a wizard whose job is to develop a BizTalk Web service around the task isolated in the workflow chart. The Windows Communications Foundation (WCF) Service Publishing Wizard consumes about six panels, after which Microsoft's BizTalk Services formally enrolls this newly packaged Web service into Internet Information Services (IIS).

Or in English: The EDI document needed a way to react to an unforeseen condition. In Visual Studio, BizTalk already knew how to react to ordinary conditions, but this was an exception. So by modifying the existing workflow, the wizard could construct a Web service that generated a response to the exception and enrolled it into the existing order of business logic, all without direct programming.

"Service orientation, and the use of Web services, we think helps with reuse in a pretty material way, by raising the abstraction level one node higher," Microsoft's director of product management for its BizTalk Server Group, Steven Martin, told BetaNews in a recent interview. "It also gives you the ability, just like you saw in the demos, to graft non-service-oriented applications and expose them as services, so that they're more consumable."

Martin said there were three principal Microsoft technologies at play here: .NET Framework, Windows Communication Foundation, and Windows Workflow Foundation. While .NET executes the process, WCF establishes connectivity between businesses through what Microsoft refers to as "the cloud" - the communications medium through which all good messages pass, and about which businesses aren't supposed to have to know much. WF (note: not WWF, in deference to pandas and wrestlers) establishes the language with which EDI processes are translated into everyday workflow, and from that into Web services.

One such Web service takes the form of an ordinary conversation between business processes, Martin explained: "I'm going to ask you if you have something, and you're going to tell me yes or no. So what we want to do instead, I want to expose my application logic to you, as my partner, and show you where my inventory is, show you where I would like for it [to be], and then help me figure out how to get it, if you can participate, in getting it from point A to point B."

In other words, rather than one business placing a request for a product and waiting for it to show up in its docking bay, it can initiate a kind of rapport with the other business (the operative term here being "B-to-B") where both can determine the best route to meeting that request logistically.

"That type of interaction you can't do with an EDI document," Martin told BetaNews. "EDI will continue to play a very important role for years to come, but as we think about next generation supplier portals, Web portals, rich B-to-B connectivity, we're going to move from a transaction-oriented world to a much, much richer interactions with our valued partners. To do that, [we need] service orientation, and thinking about not just application-to-application connectivity, inside your organization, it's the application-to-application connectivity across the Web, so that my systems are really talking to your systems in a rich, non-transactional way."

There's another message in that paragraph that you might have missed if you just glanced over it; Microsoft has a persistent theme in the course of its everyday business. Essentially: "It's nice that you've chosen to do business the way you have. We recognize we can't evangelize you into changing your ways overnight. So we've opted to embrace the way you work today - hoping that this will give you the opportunity to migrate toward the way we'd like you to work tomorrow."

Next: Microsoft's motivation for "wrapping" processes...