Hierarchical naming convention for messaging artifacts

Abstract: the use of a hierarchical naming convention allow to group messaging artifacts in a tree-like structure. note on conventionsI’ve seen many different naming conventions for BizTalk, and I must admit that I haven’t found any suitable for me, especially on messaging ports. Some conventions rely on functional rules, some on technical rules. They add…


Integration with messaging: Command messages and Document messages

Abstract: although the concept of document message and command message is quite simple, it’s usual to see document messages used for everything. At the highest level, integration is about communicating different applications. This communication can be performed to exchange data or functionality.If you are doing the integration via messaging, you’ll use messages to communicate applications….


Team development with BizTalk: new white paper

a must read for everyone working with BizTalk. It includes team development, best practices, approaches for versioning, etc. read at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/bts_2004wp/html/ffda72df-5aec-4a1b-b97a-ac98635e81dc.asp


Schema design: do include support for Errors and Warnings

Abstract: Schema designs usually contain some boolean Error-or-Success code to handle the result of the process. In an EAI scenario, schemas should contain at least support for a new result type: Warning. EAI communicates different applications. In a one-to-one integration, the result can be just categorized Success or Failure. But if we have more than…


Programming inside orchestrations: Where should I put the code?

Abstract: A common question from my customers: ‘how much code should be in the orchestration, and how much code should be leveraged into .NET components?’ In the BPEL standard, a business workflow is used only to coordinate the execution of components (web services). With XLANG, you can add .NET code, so the workflow have not…


Orchestrations as Business Processes, not Technical Processes (Part 2, Development)

Abstract:  Once I read a book that said: “A complex system that works is invariably found to have evolved from a simple system that works”. That’s right for orchestrations, especially because they mix business and technical elements. Let’s see an approach to start simple and evolve to complex. A good approach that works fine for me is…


Orchestrations as Business Processes, not Technical Processes (Part 1, Design)

Abstract: In a Business Process Management oriented project, orchestrations are business processes, not technical processes. A common mistake (mistake from the BPM point of view) is to use orchestration designer as ‘visual coding’. If you take the orchestration as a technical process, you are probably adding shapes and actions to deal with technical problems. At…


Introducing the blog (and myself)

Welcome to my brand new blog! this is my first post, so I’ll try to set the expectations and introduce myself first. What you can expect from here:I’ll post about BizTalk and integration stuff, such ideas related to BPM, EAI, SOA, etc., and probably about some other technologies (.NET, Yukon, SOAP/WSE, messaging, etc), as I…