Posts
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 : 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. 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: Take a break! 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. 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. 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). 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". 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:
