About Features
This section is home to feature articles by regular and guest authors. Topics and opinions vary - some articles include discussions!
| Understanding BizTalk's Declarative Programming Model |
| Features - Feature Articles |
| Written by Erik Westermann |
| Friday, 20 February 2009 15:21 |
|
When most people hear "BizTalk" they usually think about orchestrations. Although orchestrations are great, they are not the primary means of creating a BizTalk solution. In fact, no single BizTalk technology is a primary means -- all BizTalk technologies work together in a loosely coupled way. Orchestrations are the most visible feature in BizTalk Server - they seem to simplify development to the point where people start to say things like "So it is easy", "Just drag and drop..simple", "So this is what we pay you for?" (well...not really...I made up the last comment). BizTalk is different. In contrast to applications you write using code, you may have seen and heard that BizTalk developers write very little, if any, code. The BizTalk programming uses a declarative model. The declarative programming model expresses a solution's logic without getting into the details of how to execute the logic. The key benefit of declarative programming in BizTalk is that it separates the developer from the underlying system. Developers don't have to be (too) concerned about threading model, operating environment, security, and other operational aspects - developers that use a declarative programming model focus more on the solution's logic rather than on how the underlying system handles the logic. You are actually already familiar with declarative programming. An example of declarative programming many can relate to is adding a button control to a form or page in a Windows Forms or ASP.NET application. When you add a button to a form or page, you focus on aspects like the button's position and text that appears on the button. The code you write to add a button to a Windows Form (or Visual Studio generates for you) probably looks similar to this: button1 = new System.Windows.Forms.Button(); Notice that the code simply describes the button. The automatically generated code does not work with window handles and drawing contexts leaving the runtime to handle the details of actually drawing the button and sending click events to your event handlers. BizTalk developers work in the same way. A BizTalk developer describes a message using an XML schema, and declares the location at which the application receives instances of the schema. The developer then describes the processing that takes place when the message arrives: the developer could transform the message, change its attributes, execute rules, and even create new types all using a declarative model. At runtime, the BizTalk environment handles the details of receiving messages, routing them to interested applications, and converting the developers' declarations into actions. All of this happens in a type-safe environment that makes it easier to create a technically correct solution (correct in terms of handling types and acting on them - BizTalk cannot, of course, confirm that the actions you take are correct). BizTalk developers can also write code within the BizTalk environment using XLang/s, a language that is modeled after the C# programming language. Writing code in XLang/s often involves actions like message assignment, creating instances of objects, and invoking class member functions. You can use more advanced functionality using statements like call, while, and if; however, this is not strictly necessary since the orchestration designer's purpose is to make it easier to express these statements using orchestration shapes like Call Orchestration, Loop, and Decision. While the declarative programming model seems to simplify solution development, people like business analysts, architects, designers, and developers are still necessary since you still need to know how to solve the business problem. |
Newsflash
Linxter describes itself as an easy to use cloud messaging platform that works on .NET and Java platforms. Linxter enables communication, via messages, between internet connected systems over its Internet Service Bus. On reviewing this application in January 2011, I found Linkster is not as easy to use, its documentation basic, and its quick start applications are neither: they’re not quick, nor do they start. |