Happy BizTalk to you – Part 1

Welcome To machine!

Today, I would like to introduce the series of Happy BizTalk to you; the idea behind these articles is to familiarize you with a set of design patterns in BizTalk orchestrations to simplify the programming process automatically. The plan is to get you some overview automatically, no additional effort required. When you're familiar with the design patterns of BizTalk, you can face a programming issue and — Bam! — A solution will come to you more quickly. Instead of banging your head against the wall in desperation, you'll say, "What I need here is the Splitter pattern Or the Aggregator pattern". Let's go

What are the Patterns?

People think in patterns. It is the way we naturally communicate ideas related ‎to complex subject areas such as music, science, medicine, chess, and ‎software design. Patterns are not new. We all use them intuitively as part of ‎the learning process without really thinking about it. And because our minds ‎naturally use patterns to perform complex tasks, you can find patterns nearly ‎everywhere.‎

For example : The Patterns in Sports

Consider what happens during a soccer game or an American football game.‎ if you look closer at patterns, you will find relationships between them. In ‎sports, for example, teams have certain plays for offense and certain plays for ‎defense; the patterns that describe two players' actions must fit into a larger ‎pattern that the team is following. In this sense, patterns can be described in ‎terms of hierarchies.‎

What are you talking about exactly?

You know that BizTalk implements the meaning of EAI (Enterprise Application Integration), but we need to define the following :

  • What is Enterprise Application?

    The Enterprise Application is software which provides business logic support functionality for a ‎organization, typically in commercial organizations, which aims to improve ‎the organization's productivity and efficiency.‎Enterprise applications are those which are accessed at the same time by ‎many users and are hosted on single servers. They mostly have multiple ‎user roles, security access and integration with other applications. They ‎help companies to maintain and access enterprise data like finance, ‎employee, sales, production, etc.‎

  • What is the Integration of Enterprise Application?

    Integration, Integration, integration….ummmm! , actually, Integration is an act of combining two or more things in such a way that ‎they work together. In this respect, integration is connected to enterprise ‎applications and information technology. Enterprise applications store a ‎huge amount of persistent data which are accessed simultaneously by ‎multiple users. ‎

    The definition of "integration" is very broad. To us it means connecting ‎computer systems, companies or people. However, in EAI there are six types of integration ‎projects:‎

    • ‎Information Portals
    • ‎Data Replication
    • ‎Shared Business Functions
    • ‎Service-Oriented Architectures
    • ‎Distributed Business Processes
    • ‎Business-to-Business Integration

Take a break!

  1. Information Portals : ‎

    For example, to verify the status of an order, a customer service representative may have to access the order management system on the mainframe plus log on to the system that manages orders placed over the Web. Information portals aggregate information from multiple sources into a single display to avoid having the user access multiple systems for information. Simple information portals divide the screen into multiple zones, each of which displays information from a different system.

  2. Data Replication : ‎

    Many business systems require access to the same data. For example, a ‎customer's address may be used in the customer care system (when the ‎customer calls to change it), the accounting system (to compute sales tax), the ‎shipping system (to label the shipment) and the billing system (to send an ‎invoice). Many of these systems are going to have their own data stores to ‎store customer related information. When a customer calls to change his or ‎her address all these systems need to change their copy of the customer's ‎address. This can be accomplished by implementing an integration strategy ‎based on data replication. There are many different ways to implement data ‎replication. For example, some database vendors build replication functions ‎into the database, we can export data into files and re-import them into the ‎other system, or we can use message-oriented middleware to transport data ‎records inside messages.‎

  3. Shared Business Functions: ‎

    In the same way that many business applications store redundant data, they also tend to implement redundant functionality. Multiple systems may need to check whether a social-security number is valid, whether the address matches the specified postal code or whether a particular item is in stock. It makes business sense to expose these functions as a shared business function that is implemented once and available as a service to other systems.

    A shared business function can address some of the same needs as data replication. For example, we could implement a business function called 'Get Customer Address' that could allow other systems to request the customer's address when it is needed rather than always storing a redundant copy. The decision between these two approaches is driven by a number of criteria, such as the amount of control we have over the systems (calling a shared function is usually more intrusive than loading data into the database) or the rate of change (an address may be needed frequently but change very infrequently).

  4. Service-Oriented Architecture : ‎

Shared business functions are often referred to as services. A service is a well-‎defined function that is universally available and responds to requests from ‎‎"service consumers". Once an enterprise assembles a collection of useful ‎services, managing the services becomes an important function. First of all, ‎applications need some form of service directory, a centralized list of all ‎available services. Second, each service needs to describe its interface in such ‎a way that an application can "negotiate" a communications contract with the ‎service. These two functions, service discovery and negotiation, are the key ‎elements that make up a service oriented architecture.‎

Service-oriented architectures (SOAs) blur the line between integration and ‎distributed applications. A new application can be developed using existing, ‎remote services that may be provided by other applications. Therefore, calling ‎a service may be considered integration between the two applications. On the ‎other hand a service-oriented architecture usually provides tools that make ‎calling an external service almost as simple as calling a local method ‎‎(performance considerations aside). Because all services are available in a ‎consistent manner, SOAs are sometimes referred to as "service bus ‎architectures".‎

  1. Business-to-Business Integration

    So far we have mainly considered the interaction between applications and business functions inside an enterprise. In many cases, business functions may be available from outside suppliers or business partners. For example, the shipping company may provide a service for customers to compute shipping cost or track shipments. Or a business may use an outside provider to compute sales tax rates. Likewise, integration frequently occurs between business partners. A customer may contact a retailer to inquire on the price and the availability of an item. In response, the retailer may ask the supplier for the status of an expected shipment that contains the out-of-stock item.

    Many of the above considerations apply equally to business-to-business integration. However, communicating across the Internet or some other network usually raises new issues related to transport protocols and security. Also, since many business partners may collaborate in an electronic "conversation" standardized data formats are critically important.

    What is of the biggest buzz words in enterprise architecture and integration? ‎ Loose Coupling

    Someone may ask; how could the Loose Coupling help us?

    Okay, let's assume we are building an on-line banking system that allows customers to ‎deposit money into their account from another bank. To perform this function, the ‎front-end Web application has to be integrated with the back-end financial system ‎that manages fund transfers. The easiest way to connect the two systems is ‎through the TCP/IP protocol. Every self-respecting operating system or ‎programming library created in the last 15 years is certain to include a TCP/IP stack. ‎TCP/IP is the ubiquitous communications protocol that transports data between ‎the millions of computers connected to the Internet and local networks. Why not ‎use the most ubiquitous of all network protocols to communicate between two ‎applications? Let's assume that the remote function that deposits money into a ‎person's account takes only the person's name and the Dollar amount as ‎arguments. The following few lines of code then suffice to call such a function over ‎TCP/IP.

    byte[] amount = BitConverter.GetBytes(258);

    But we didn't keep in mind in this example the following:

  • Platform Technology ‎ the internal representations of numbers and objects
  • Location all components have to be available at the same time
  • Data Format the list of parameters and their types must match
Because of the platform technology are not the same, the problem of Big-Endian and Little- Endian may be occurred
Have you figured the problem?
What about the location, Data format?
So, the TCP is not the right option in our example, in order to make the solution more loosely coupled we can try to remove ‎these dependencies one by one. We should use a standard data format ‎that is self-describing and platform independent, such as XML. Instead of ‎sending information directly to a specific machine we should send it to an ‎addressable "channel". A channel is a logical address that both sender and ‎receiver can agree on the same channel without being aware of each ‎other's identity. Using channels resolves the location- dependency, but still ‎requires all components to be available at the same time if the channel is ‎implemented using a connection-oriented protocol... In order to remove ‎this temporal dependency we can enhance the channel to queue up sent ‎requests until the network and the receiving system are ready. To support ‎queuing of requests inside the channel, we need wrap data into self-‎contained messages so that the channel knows how much data to buffer ‎and deliver at any one time. Lastly, the two systems still depend on a ‎common data format. We can remove this dependency by allowing for ‎data format transformations inside the channel. If the format of one ‎system changes we only have to change the transformer and not the other ‎participating systems. This is particularly useful if many applications send ‎data to the same channel.

Okay, I guess I had answered your question about the Loose Coupling. in the next article I will exaplin the Application Integration Options.
So Be there.

2 Response to "Happy BizTalk to you – Part 1"

  1. Anonymous Says:
    May 27, 2009 at 12:42 AM

    Hi! Your blog is simply super. you have create a differentiate. Thanks for the sharing this website. it is very useful professional knowledge. Great idea you know about company background.
    Increasing your web traffic and page views Add, add your website in www.itsolusenz.com

  2. U3 says:
    May 29, 2009 at 2:51 PM

    Thank you man for your words.