Dot Net Dunk

# re: BizTalk Code Behind

Thanks, when I first leraned about BizTalk 2004 back in April'03 (first introduction in Europe) this was my immediate feedback to the MS product guys. Here's what I wrote to them 18 Months ago (it's a bit lengthy, I hope you do not mind).

-----------------
[…]

The problem I see lies in the orchestration files. Currently they are a mixture of BPEL, XLANG/s, and C# fragments and if I understood correctly, they are translated (in the background) to C# to be compiled into assemblies. You told me (essentially) that you won't document or enhance XLANG/s since it's proprietary and that you can't get rid of it since it supports things BPEL doesn't. The consequence is that the orchestration file format is not only undocumented rather it's virtually impossible to understand and read it directly. Therefore the orchestration editor provided by Voyager is the _only_ means to access those files, not only for editing but also for every other purpose as well.
Why do I consider this as a big problem? Well, there's a lot if things one can do with text-oriented files, even if the actual representation is undocumented as long as it's understandable:
- Putting in comments and documentation (as with C# and code comments or XML comments)
- handle versioning via SCM-Tools or file comparison tools, e.g. do a compare between two versions in Visual SourceSafe and understand the differences
- use or create tools to generate those files (i.e. to generate orchestrations from UML activity diagrams)
I consider those issues as serious because that's how projects (should) work: Walking along the analysis-design-implementation-testing chain, probably iteratively and using standards as UML and ARIS for business process modelling and of course additional tools like SCM's. Without Voyager fitting into that scheme, without being able to roundtrip, to annotate, to document and to "talk" and integrate with standards and tools Voyager would cause a project manager's nightmare. Worse, it might even drive deciders to abandon Voyager.

Now, here's what I would like to see and what I think would solve those problems:
As I see it the relationship between BPEL and XLANG/s is more like the relationship between a web service description and it's implementation (i.e. WSDL and say C#). Maybe that's not quite adequate for XLANG/s but maybe it would even be better to abandon XLANG/s in favour of a set of .NET classes, interfaces and attributes (the ones, voyager generates in background, perhaps "beautified"). After all, there's no big difference between an XLANG/s "port" declaration and a property of a typ derived from a Port class and annotated with a PortAttribute. Instead of working on a proprietary file format the orchestration designer would have to work on a C# file probably using codedom. Matter of fact, this is exactly what the other visual designers in vs.net do, sometimes complemented with additional files. Instead of having to cope with an additional fully fledged code editor for c# fragments within the current orchestration editor, one could jump via double click to a method generated in something like a code behind class, just like if I double click an edit field in an ASP.NET page. Well, I think you get the idea.

You told us that Voyager has evolved towards a more developer oriented tool. What I just suggested seems to me being the logical conclusion of that evolution.
Apart from solving the issues mentioned above, there would be a whole bunch of additional benefits, e.g.:
- do quick fixes without devstudio
- leverage language and framework features (inheritance, in-source-documentation, ...)
- debugging support
- getting rid of an editor within an editor (the dialog used to put in code fragments)
- handling consistency within devstudio across different technologies

[…]
----------------------

# re: BizTalk Code Behind

Hi,

A posted on this a while back (Show me the code). I often print out a cleaned up version of the XLANG/s body mehod of an orchestration, if it's a complex one, and read through the code to double check that it's all in order, it gives you a much better indication of the orchestration at a low level than the diagram. I think it is possile to modify the code in a text editor, instead of the orchestration desigher, problem is, it may not load into the designer again...

The orchestration designer has an "Orchestration" button at the bottom, maybe there will be a "Code Behind" button in a future release, it would be great if they implemented this feature.

# re: BizTalk Code Behind

It's definitely something that would be useful; I think the early previews of WinOE (Windows Orchestration Engine) - now slated for Longhorn Server but shown at a PDC a couple of years ago - showed something like akin to a code behind model.

Opening .odx files as text files is something I'd suggest every BTS developer does - it's enlightening to see the actual code that goes to make up an orchestration.

# re: BizTalk Code Behind

Yes, I totally agree and something I've been on about as well. Instrumentation in my view would benefit greatly from this as rather than littering the orchestration with -TRACE- expressions or -DEBUG- expressions, I could implement my instrumentation in code behind and is therefore effectively invisible from the business analysts who really just want to see the business process - not the techie junk that has to exist in order for it work (properly) ;-)

# re: BizTalk Code Behind

Take a look at Windows Workflow Foundation and reread your own post ;-))))