Tuesday, May 30, 2006

Understanding Microsoft Integration Technologies

Further to my previous post, here is a good link from Biztalk team on MSMQ, SQL Service Broker and ofcourse on Biztalk Server 2006:

Microsoft Integration Technologies

Monday, May 22, 2006

Difference between MSMQ, Biztalk Server and SQL Server 2005 broker service

Hmm. If you are as puzzled as I am on the relevance of each of them together or separate then following information is for you. I personally found it very useful so I am copy pasting the information here:

http://blogs.msdn.com/rogerwolterblog/archive/2006/02/28/540803.aspx http://blogs.msdn.com/rogerwolterblog/archive/2006/02/28/540803.aspx

Where does Service Broker Fit?

One of the most frequently asked questions I get when talking about Service Broker is how does it fit with the other messaging products that Microsoft has. Specifically, I hear a lot about MSMQ, WCF (Indigo) and BizTalk. In this post, I will try to clarify the scenarios where Service Broker is the right solution and the scenarios where one of the other products is a better fit. Keep in mind that this is my interpretation of the product positioning and other people my have slightly different outlooks.

What is Service Broker?
Before I dive into where Service Broker fits, it may help if I summarize some of the core features of Service Broker. With Service Broker, SQL Server 2005 becomes a platform for building loosely-coupled, asynchronous database applications. Most large database applications have one or more tables which are used as queues. While using a table as a queue is a very useful way to improve performance and scalability, it’s very difficult to get right. Service Broker addresses this issue by implementing queues as first-class database objects. The queue handling code built into the database kernel handles the locking, ordering, and multithreading issues associated with most home-grown database queues. In order to support scaling out asynchronous database applications, Service Broker includes reliable, transactional messaging between SQL Server instances. Because Service Broker messaging is built into the database, it offers message integrity, performance, and reliability that most transactional messaging systems can’t match. Service Broker dialogs provide ordering and delivery guarantees that no other messaging system offers. To ensure that there will always be an application running to process received messages, Service Broker includes an activation facility that keeps the right number of stored procedures running to handle the messages arriving on a queue. Activation automatically detects and compensates for changes in the incoming message rate so the queue doesn’t grow faster than necessary and resources are not wasted when the queue is empty.

Finally, Service Broker is not JUST a messaging system. While the messaging features are very useful, a large number of Service Broker applications don’t require messaging at all. The ability to do asynchronous, queued database actions is very useful, even if your database application isn’t distributed.

Service Broker and MSMQ
MSMQ is a mature, general purpose reliable messaging system that is part of Windows. MSMQ can communicate over TCP/IP or HTTP and supports three types of reliable messaging – non-persistent, persistent and transactional. Service Broker supports transactional messaging between instances of SQL Server 2005 over TCP/IP. Since Service Broker is built into the database, it does transactional messaging significantly faster and more efficiently than MSMQ. MSMQ is a message transport and not a database so if application messages themselves are important business objects that must have high data integrity including backup and failover, Service Broker is also a better choice. If your application can survive an occasional lost message, must communicate over HTTP, or can’t live with a SQL Server database at both ends of the communications link, then MSMQ is a better choice. One of the grey areas is client to server reliable messaging. While SQL Express makes Service Broker available for client applications, you will have to decide whether the extra overhead of having a database running on the client is justified by the extra data integrity provided by Service Broker. In some cases, the client needs a database anyway and so the Service Broker is a viable choice. Point of Sale terminals are a good example of a client where a SQL Express database talking Service Broker to a server database makes sense.

WCF (Indigo) and Service Broker
WCF is the only product in this comparison that does unreliable messaging so if Unreliable messaging meets your needs then the choice is obvious. WCF has at least two reliable messaging options. The first is based on MSMQ so the same considerations apply. The second is a non-persistent message transport that uses ws-rm as a transport This is the only choice if you need to interoperate with another ws-rm based product but doesn’t offer the degree of reliability that the persistent implementation offer. One of the items on the list for a future release of Service Broker is a WCF channel for Service Broker. This would combine the reliability and data integrity of Service Broker messaging with the programming model of WCF. There is no committed schedule for this yet but when it happens, it will be a boost for both Service Broker and WCF.

BizTalk and Service Broker
On the Surface, this looks like the toughest call because both BizTalk and Service Broker communicate between SQL Server instances. If all you need to do is deliver a bunch of bits from one SQL Server instance to another over a TCP/IP connection then Service Broker is probably the best choice because it it smaller and more efficient at delivering messages. If on the other hand, you need the features of BizTalk – message transformation, orchestration, a variety of transport options, data dependant routing of messages, etc. then you must either choose BizTalk or be prepared to write and support the code to do these things yourself.BizTalk does Information Integration, Workflow, and heterogeneous messaging which Service Broker knows nothing about.

In general, Service Broker does high-performance, extremely reliable, asynchronous operations that span distributed SQL Server database instances. If this describes your application requirements then you should very seriously consider Service Broker. If your application doesn’t have these requirements, you should still look at Service Broker but you should also consider the other alternatives.

Well I hope now you are clear than before if not more confused. I think if you are still confused about them then it is not your cup of tea ;)

Installing mighty Biztalk Server 2006

Well, I am here! Back after a long time. Some commitments at work place were taking their toll over my personal interests. From a long time I was trying to install Biztalk Server 2004 on my personal machine. First I was trying to install it on my Windows Server 2003 machine. It seems I was really running out of luck as I never managed to crack what's the issue. I always used to get "Failed to configure SSO Service error. Could not start Single Sign On Service" type of error message. I was not able to figure out what is the real issue here. Even if I go to service manager and start this service manually, damn Biztalk Server 2004 to shut it again and cry that it could not start it.

Just some days back I was reading the ease of configuring Biztalk Server 2006 (forget about Biztalk Server 2004, its a old gun now). I thought of giving it a try. Yes, configuration is kind of easy. Instead of hundreds of wizards now you have only one window to configure all the things. My installation went just fine as it used to go with older brother. When time came to configure real "stuff", it again got stuck at starting and configuring Single Sign On service. This behaviour was happening on my Windows Server 2003 desktop Windows XP SP 2 laptop. This time I googled web like a crazy person and I got the solution of this very old problem. Microsoft KB 841893 deals with it. I have copy pasted the solution right here. Well MS says either of the solution should work, however to be on a safer side I did both the steps. I tried again configuring the Biztalk Server 2006 and voila it all worked.

Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

To allow client requests to the RPC Endpoint Mapper to succeed, you must require client calls to the RPC Endpoint Mapper to be authenticated. You can enforce authenticated client calls to the RPC Endpoint Mapper by running the Group Policy Object Editor or by creating a registry entry. Use one of the following methods to require client calls to the RPC Endpoint Mapper to be authenticated.

Use the Group Policy Object Editor to enforce the use of authenticated client calls to the RPC Endpoint Mapper
1. Click Start, click Run, type gpedit.msc, and then click OK.
2. In the Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand System, click Remote Procedure Call, and then click RPC Endpoint Mapper Client Authentication.
3. Change the value for RPC Endpoint Mapper Client Authentication to Enabled.

Use Registry Editor to enforce the use of authenticated client calls to the RPC Endpoint Mapper
1. Click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following registry key:
3. Look for a subkey that is named RPC. If this key exists, click the RPC subkey, and then go to step 6. If this key does not exist, go to step 4.
4. On the Edit menu, point to New, and then click Key.
5. While the new key is selected, type RPC, and then press ENTER.
6. On the Edit menu, point to New, and then click DWORD Value.
7. Type EnableAuthEpResolution, and then press ENTER.
8. On the Edit menu, click Modify.
9. In the Value data box, type the number 1. Click OK.

Note If you want to disable this functionality, set the EnableAuthEpResolution registry entry to 0 (zero).
10. Quit Registry Editor.
After you create this registry value, you must restart your computer for the registry value to take effect. After this registry change is implemented, client calls to the RPC Endpoint Mapper will be made with authentication. This behavior allows the ENTSSO service to start.

Now I am running on a well configured instance of Single Sign on service and Biztalk Server 2006. Eventually Biztalk Server 2004 remains unconquered for me. :)