WSCF.blue is a Visual Studio .NET 2008 add-in that provides the following features:

· A WSDL Wizard that allows the developer to step through the creation of a WSDL from one or more XSDs.

· A Data Contract Generator (similar to XSD.exe, XSDObjectGen.exe and SvcUtil.exe) that generates the .NET equivalent classes of the XSD types.

· A Service/Endpoint Stub (support for self-hosted and web-hosted) Generator and

· A Client Proxy Generator.

· A Generate Data Contract Code feature that supports the selection of multiple XSD/WSDL source files.

· A Paste XML as Schema option that generates a schema for a block of XML in the clipboard.

· Support for C# and VB.NET code generation.

· You can choose if operation methods on your service class will throw a NotImplementedException, call an implementation method in a partial class, or will be defined as abstract methods.

· Force the SOAP actions (Action and ReplyAction) applied to each operation contract follow the standard WCF format

· Errors found while processing the WSDL are reported in a WSCF.blue pane in the Visual Studio Output window.

Please verify that the receive location exists, and that the isolated adapter runs under an account that has access to the BizTalk databases.

This error occurs because the web service is running on the application pool which security account user is not a member of the BizTalk Isolated Host Users group. in order to solve this error, you need to add the user that runs the web-service into the BizTalk Isolated Host Users group. Or change the application pool to the pool which user is already a member of the BizTalk Isolated Host Users Group. :)

I've received this error while deploying a MSI application; although, I've found a solution of this error, which is:

"when you run a 32-bit program on a 64-bit Windows Server 2003-based computer"

Welcome to machine again.

In this section we will discuss some of EAI patterns, and how these could be implemented in BizTalk.

• Aggregator:
  

  Aggregator is the pattern of receiving information from multiple sources and consolidating it into a single message
  

• Splitter:
  

  How can we process a message if it contains multiple elements, each of which may have to be processed in a different way?
  

  Use a Splitter to break out the composite message into a series of individual messages, each containing data related to one item
  

  In BizTalk, there is a concept known as Envelope splitting. This is a useful feature in BizTalk for splitting messages.
  

  The Splitter pattern takes a single message and splits it into multiple messages
  

• Parallel Convoy:
  

  A parallel convoy enables multiple single messages to join together to achieve a required result. The set of related messages can arrive in any order, but BizTalk Server must receive all of them before starting the process.
  

• Sequential Convoy:
  

  The Sequential Convoy pattern enables multiple single items to ‎join together to achieve something that an individual item cannot ‎accomplish by itself. A sequential convoy is a set of related items ‎that have a predefined order. Although the items do not have to ‎be exactly the same, BizTalk Server must receive the items in a ‎sequential order.‎
  

In order to understand better what business requirements require convoy messaging, consider the three business scenarios outlined in the following section.

Scenario 1: Hospital Admits a New Patient

Business Overview: A hospital admits a new patient. The hospital requires several pieces of information from the new patient including insurance information, past medical history, and contact information. Several different people collect this information including an insurance specialist, a nurse, and a receptionist. Several different systems process this information. The order in which collection and submission of this information occurs is not guaranteed. This is because some information collectors may be busy with other patients, the medical records department may be behind in their schedule, or the insurance system may be not functioning correctly. Assembling this information for the patient in an organized manner must occur throughout the time the patient spends at the hospital. This guarantees that the patient receives accurate care and correct billing.

Technical Overview: This process involves receiving several different pieces of information about a new patient in any order. All the pieces of information are required before the business process continues and admits the patient. This reduces the number of non-payments by guaranteeing the admission of only those patients with all the requirements. This also creates a race condition in which any one of the various messages can be the first to arrive and start the business process for the new patient. Because this is a new patient, no patient number is available for correlation or reference. Accomplishing correlation in this case occurs by using date of birth, social security number, or a combination of other demographics. Any one of the three messages may be required to start a new orchestration; this creates a race condition inside the message box.

Scenario 2: Standardized Test Taking and Grading

Business Overview: A student is getting ready to take a standardized test. As part of the testing process, the student registers for the test. After registered the student checks in at the testing center on the correct date and takes the test. Upon check out, checking the student's identity occurs again and the student leaves the testing center. Finally, the student's test arrives at the grading center. Only after the completions of all these steps in order, can the student's test be graded and a score recorded.

Technical Overview: Completion of this business process requires receipt of several different types of messages. In this case, there is a predefined order to follow in which to process these messages. After receipt of the four single messages, sending a single notice occurs to allow the student's test to be graded.

Convoy ‎ means multiple single items must be related together in order to achieve something that the individual item cannot accomplish by itself

Convoy processing can be additionally broken out into two separate categories as shown in the following list:

• Sequential convoy - Sequential convoys are a set of related items that have a predefined order. The items do not have to be exactly the same. Grouping together requires that all they have to have is a purpose to group.
  
• A real world example of a sequential convoy is a group of friends headed to a party traveling in separate vehicles. The overall goal is for all of them to reach to the party but in this case, only the first person has the directions. It is up to the lead vehicle to make sure they drive to the correct location and that all the other vehicles following are not lost. In order to make sure they all stay together, the leader instructs each following vehicle to put a blue flag on the vehicle's antenna. There are many other vehicles on the road going home, to work, or to another party but only the vehicles going to this party in this group have the blue flag.
  
• Parallel convoy - Items that are in any order, but must all be present before something occurs, Parallel convoys are a set of related items that can be in any order. BizTalk Server 2004 must receive all the items before achieving the final goal. Shown here is this basic pattern. Another way of thinking of parallel convoys is like a door with many locks. The locks can be unlocked in any order. Only when the last key is turned will the door open. The key ring may have many different keys on it, but only one set matches this combination of locks.
  

• Message Broker:
  

  Message Broker is the pattern of determining the destination of a message and still maintaining control over the message flow the goal of our generic message broker will be to dispatch any type of message to its destination decided at runtime. So, by avoiding type dependency and early routing binding (basically, hard-coding) we would get single very flexible orchestration which can easily handle requirement changes - one of the top goals of good application design.
  

  
  

  
  

  So, the question is how to implement these patterns in BizTalk?
  

  The answer is very simple, check this link J
  http://www.codeplex.com/PatternWizard
  

  And enjoy BizTalking
  

Always design a thing by considering it in its next larger context — a chair in a room, a room in a house, a house in an environment, an environment in a city plan.

Introduction:

In the last post http://mohammad-yousri.blogspot.com/2009/06/happy-biztalk-to-you-part-2.html

I asked a very innocent question: Which integration approaches best address which of these criteria?

And I talked about the different approaches; do you remember the last approach? It was the Messaging, thus, we need to explain the different types of message channels. Are you ready? Go.

Let's check the following conversation between three messages; they met each other in the channel.

Message #1: Hello

Message #2: Hey, where are you going?

Message #1: I am going to System A, you?

Message #2: Don't know, I am waiting the admin to decide.

Message #3 3 3 3 3 3 3 3 3 3 3 3's…. :

Here We Go Again, Here We Go Again. the original is still there. the original is still there

Message #2: Wow, where are these 3's going?

Message #1: They are copy of 3's, and they are going to the subscribers.

• Point-to-Point Connection
  

  A point-to-point connection ensures that only one receiver receives a particular message. For this to work, the sending system must know the location of the receiving node. The sending system often must translate the message into a format that the receiving system understands.
  

  When you use point-to-point connections, each system determines the address of all the other nodes that it needs to communicate with. When target addresses or protocol details change, all the systems that communicate with the target server must be updated. As the size of your integration network grows and as the frequency of change increases, the operational cost associated with this approach becomes significant.
  

  The strength of the Point-to-Point Connection pattern is how simple it is to implement. The weakness of the Point-to-Point Connection pattern is the duplication of transformation and routing code between systems, and the high configuration cost of endpoint address changes. To minimize these weaknesses, you can add another layer of indirection between endpoints that contains a broker. (Message #1)
  

• Message Broker
  

  A message broker is a physical component that handles the communication between applications. Instead of communicating with each other, applications communicate only with the message broker. An application sends a message to the message broker, providing the logical name of the receivers. The message broker looks up applications registered under the logical name and then passes the message to them. Communication between applications involves only the sender, the message broker, and the designated receivers. The message broker does not send the message to any other applications. Use a central Message Broker that can receive messages from multiple destinations, determine the correct destination and route the message to the correct channel. (Message #2)
  

• Publish/Subscribe
  

  At a high level, the Publish/Subscribe [Buschmann96] pattern helps keep cooperating systems synchronized by one-way propagation of messages because one publisher sends a message to any number of intended subscribers.
  

  A Publish-Subscribe Channel works like this: It has one input channel that splits into multiple output channels, one for each subscriber. When an event is published into the channel, the Publish-Subscribe Channel delivers a copy of the message to each of the output channels. (Message #3)
  
  

Today I am going to explain the application integration options, by the way there's more than one approach for integrating applications, each approach ‎addresses some of the integration criteria better than others. The various ‎approaches can be summed up in four main integration styles: ‎

Wait !!!!!!!!! What are the integration criteria?

What makes for good application integration? If integration needs ‎were always the same, there would only be one integration style. Yet ‎like any complex technological effort, application integration involves a ‎range of considerations and consequences that should be taken into ‎account for any integration opportunity. So, find below the integration criteria:

• Application coupling — Even integrated applications should minimize their dependencies on each other so that each can evolve without causing problems for the others. Tightly coupled applications make numerous assumptions about how the other applications work; when the applications change and break those assumptions, the integration breaks. The interface for integrating applications should be specific enough to implement useful functionality, but general enough to allow that implementation to change as needed.
  

  
  

• Integration simplicity — when integrating an application into an enterprise, developers should strive to minimize changing the application and minimize the amount of integration code needed.
  

  Yet changes and new code will usually be necessary to provide good integration functionality, and the approaches with the least impact on the application may not provide the best integration into the enterprise.
  

  
  

• Integration technology — Different integration techniques require varying amounts of specialized software and hardware. These special tools can be expensive, can lead to vendor lock-in, and increase the burden on developers to understand how to use the tools to integrate applications.
  

  
  

• Data format — integrated applications must agree on the format of the data they exchange, or must have an intermediate traslator to unify applications that insist on different data formats. A related issue is data format evolution and extensibility—how the format can change over time and how that will affect the applications.
  

  
  

• Data timeliness — Integration should minimize the length of time between when one application decides to share some data and other applications have that data. Data should be exchanged frequently in small chunks, rather than waiting to exchange a large set of unrelated items.
  

  Applications should be informed as soon as shared data is ready for consumption. Latency in data sharing has to be factored into the integration design; the longer sharing can take, the more opportunity for shared data to become stale, and the more complex integration becomes.
  

  
  

• Data or functionality — integrated applications may not want to simply share data, they may wish to share functionality such that each application can invoke the functionality in the others.
  

  Invoking functionality remotely can be difficult to achieve, and even though it may seem the same as invoking local functionality, it works quite differently, with significant consequences for how well the integration works.
  

  
  

As you can see, there are several different criteria that must be considered when choosing and designing an integration approach. The question then becomes:

Which integration approaches best address which of these criteria? ‎

• File Transfer — Have each application produce files of shared data for others to consume, and consume files that others have produced. In the File Transfer pattern, one application produces a file and transfers it so that other applications can consume it. Because files are a universal unit of storage for all enterprise operating systems, this method is often simple to implement.
  

  The applications must agree on file naming conventions and the directories they appear in. The writer of a file must implement a strategy to keep the filenames unique. The applications must agree on which one will delete old files, and that application will have to know when a file is old and no longer needed. The applications will need to implement a locking mechanism or follow a timing convention to ensure that one application is not trying to read the file while another is still writing it. If all of the applications do not have access to the same disk, then some application must take responsibility for transferring the file from one disk to another.
  

  
  

  While this approach seems simplistic, it does have some advantages. Using files affords good physical decoupling between the different processes. If the target system is not immediately available to receive the file, it can be stored until the system becomes ready. Also, files are essentially platform and language independent as long as they use a common character set.
  

  However, batch file transfers also present a number of challenges. Data changes in one system may not be available in the other system until the next day. This may be confusing to users, and cause data integrity problems if the (outdated) data is updated in the other system. Additionally, batch exchanges tend to extract all available information from one system and replicate it to the other system. If only few changes were made, this approach will cause large amounts of unnecessary data transmission.
  

• Shared Database — Have the applications store the data they wish ‎to share in a common database.‎
  

  In an attempt to eliminate data synchronization issues and the ‎replication of huge amounts of data, some enterprises went to ‎create a shared database resource that would be shared by all ‎systems. Having the data in a single place would eliminate the ‎need for duplication of data. Synchronization issues and ‎contention can be addressed by the locking and protection ‎mechanisms provided by most database systems. The key ‎drawback of this solution lies in the difficulty of defining a data ‎model that fits all applications. Many applications are built or ‎purchased with proprietary data models and many attempts to ‎morph all these models into a single, universal data model turned ‎out to be a never ending task. Also, accessing a single database ‎may cause a serious performance bottleneck. In addition, this ‎solution still simply exchanges data items, rather than managing ‎business functions across systems.‎
  

• Remote Procedure Invocation — Have each application expose ‎some of its procedures so that they can be invoked remotely, and ‎have applications invoke those to run behavior and exchange data.‎ Remote Procedure Call (RPC) mechanisms isolate the application ‎from the raw data exchange mechanisms through an additional ‎layer. This layer manages the marshalling of complex data types ‎into byte streams as required by the transport layer. As a result, ‎RPC mechanisms allow an application to transparently invoke a ‎function implemented in another application. The marshalling ‎mechanisms rely on stubs generated from the interface ‎specification in a language-neutral Interface Definition Language ‎‎ (IDL).‎
  

  While RPC-based systems made dealing with the integration much ‎simpler, these systems still share the drawbacks of unreliable, ‎synchronous communication with the raw data exchange ‎methods. RPC-based systems also imply brittle point-to-point ‎connections between senders and, receivers that become difficult ‎to maintain as the number of participants increases. Furthermore, ‎most vendor-provided RPC implementations are not interoperable ‎with other products.‎
  

• Messaging — Have each application connect to a common ‎messaging system and exchange data and invoke behavior using ‎messages.‎
  

  Messaging systems try to overcome the drawbacks of the previous ‎solutions by providing reliable, asynchronous data transfer. An ‎application can publish data to the integration layer and can be ‎assured that the data will be delivered to the recipient(s). The ‎originating system is not required to wait for an acknowledgement ‎and can continue the primary process flow. Messaging systems ‎also incorporate addressing schemes that avoid the difficult to ‎maintain point-to-point connections that are typical in RPC ‎systems. At this time, it appears that messaging systems provide ‎the best basis for an integration solution. However, there are still ‎some challenges to be overcome. Messaging systems are still ‎comparatively new and the body of knowledge around architecting ‎these systems is still evolving. Asynchronous systems require a ‎different approach to systems architecture and design than ‎synchronous systems do. Furthermore, the asynchronous nature ‎of the interaction can make testing and debugging more difficult as ‎well.‎
  

Ummmm….Messaging, seems that we are talking about BizTalk.
J

Conclusion:

Today, we talk about the integration criteria which make your integration application good, according to these criteria; you have to choose the best approach that matches the criteria is.

In the next article, I will explain the different between messaging channels, so, be there.

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

Some of the key enhancements to BizTalk 2009 is support for the latest Microsoft offerings (including Windows 2008, Visual Studios 2008 SP1, .Net 3.5 SP1, SQL 2008, and TFS), support for RFID Mobile, and new LOB Adapters (including a new SQL Adapter).

A new release of the Enterprise Service Bus Guidance is available on CodePlex (http://www.codeplex.com/esb).

Wow.. seem that we are going to enojoy biztalking :D

BizTalk Server Team Blog post this guidance, If you are looking into implementing a BAM solution using the BizTalk Server infrastructure I strongly recommend reading this paper and testing the sample code provided with it. The online version is available on MSDN, however for the full Word version and sample code you may want to download it.

At least 632 Palestinians, including women and children, have been killed in an Israeli aerial bombardment on Hamas security installations.
Emergency services said that at least 2845 people had been wounded.
we call on imams, speakers, journalists, poets, writers, and literary authors to enrich the religious, cultural, and media pulpits with resistance literature and to send out a message of hope that the more ferocious events get, the more hope we lay on Allah who promised to exterminate the tyrants and grant victory to the believers and Who made it a duty on Him in His grandeur saying in the Qur'an: {وَكَانَ حَقّاً عَلَيْنَا نَصْرُ الْمُؤْمِنِينَ} Transliteration: Wa Kāna Ĥaqqāan `Alaynā Naşru Al-Mu'uminīna[and it was due (to them) upon Us to help the believers.] [Ar-Rum 30:47].
:: This Is a Message for Humankind ::
:: Did you know ? ::
:: The situation of the Muslims in Palestine ::
:: What can we do about the slaughter of Muslims in Palestine and around the world? ::
:: For more news ::