Friday, February 26, 2010

SQL Server 2005 Broker Service: MSMQ, WCF, Biztalk!

I got a chance to plumb with MSMQ way before I worked with SQL Server 2005. And recently, while reading a book and couple of articles, I played around with SQL Server Broker Service; and it was fun. And the question that jumped around my mind was how could we use Broker Service, if at all possible, with WCF; and then why would we ignore MSMQ over Broker Service.

Well, thought... I should have these thoughts documented somewhere.

First, the Service Broker is one of the powerful features that comes with Microsoft BI Product Suite. Initially, I "overlooked" service broker which gives the SQL Server power to build reliable/distributed apps - and by apps I mean, the service broker can turn SQL Server into a platform. Imagine database talking to each other, performing transactions, taking decisions, releasing notifications, all by themselves.

Microsoft says: Service Broker provides an asynchronous communication mechanism that allows servers to communicate by exchanging queued messages. Service Broker can be configured to prioritize certain messages so that they are sent and processed before other lower priority messages. Use the Service Broker Diagnostic Utility to investigate communication problems between participating Service Broker services. - MSDN


FIG1: Service Broker



FIG2: Network Level Communication Pattern


MSMQ vs Service Broker
Since service broker is built into SQL Server, I found out that service broker messaging has some significant advantages over MSMQ transactional messaging - and performance being one of them.

The maximum Service Broker message size is 2 GB; The maximum MSMQ message size is 4 MB - memory constraint.

Service Broker activates another queue reader process only when the current processes aren't keeping up with the load, while MSMQ triggers fire for every message that arrives - again process intensive.

Service Broker messages can be processed by any application that can establish a database connection to the SQL Server database. Applications that process MSMQ transactional messages must run on the same physical machine as the queue.

FIG 3: Dialog based communication

Service Broker can commit updates to the message queue, database data, and application state in a simple database transaction. MSMQ requires a two-phase commit to do the same thing.

While MSMQ may be beneficial when you would require both TCPIP binary protocol and HTTP SOAP protocol for communications. Like for instance raw processes over sockets as well as web services. Because service broker is binary TCP/IP only in SQL Server 2005. Or when you would want to communicate across different windows apps - independent of SQL Server database.

BizTalk vs Service Broker
Service Broker and BizTalk may not have a lot in common but service broker can reliably deliver a message to another SQL Server instance with exactly-once in-order(EOID) assurances.

Besides providing this functionality, BizTalk, in addition can manipulate the contents of messages, map message formats, manage message processing, manage workflows, manage states, send messages over multiple different transports. If your application doesn't use any of these features and just requires reliable delivery from one SQL Server instance to another, Service Broker is probably a better alternative.

WCF vs Service Broker
Windows Communication Foundation supports many messaging styles over a variety of standards-based protocols between Windows and any operating system that implements the standard protocols that WCF supports.Which includes, but not limited to, TCP/IP, UDP/IP protocols.

Here is how I got started. If you like reading, then this article has some food-for-thought about the technology and may help. Akram Hussein has actually provided an step-wise example.Look here for tutorials.

Sunday, February 21, 2010

.NET: UDDI, VSDISCO and DISCO Dancers!

DISCO(read: Discovery) is a technology that Microsoft introduced in .NET, that facilitates the capability of Web service clients to discover Web services and their associated WSDL(read: wizdil) files.

.DISCO and .VSDISCO files are separate from UDDI. While UDDI, which is rapidly evolving as a standard, goes beyond DISCO by defining how to interact with a full-fledged Web Service information repository, DISCO files are still in use.


The .DISCO and .VSDISCO files provide alternative ways to discover Web services that preclude the use of UDDI. And if UDDI is in use then .DISCO and .VSDISCO files do not.

When a web service publishes a static discovery (.DISCO) file, it enables the programmatic discovery of that web service. A .DISCO file defines what files to search; whereas a dynamic discovery (.VSDISCO) file simply identifies which directories to skip.

This results in the discovery of the services that exists at that level and below the virtual directory that contains the document. A .VSDISCO file is intended to be requested by the browsers/clients over the web. If you do not want unintended-clients to be able to discover services that are not implemented for them, then do not place .VSDISCO files in the webservices directory.

Sample DISCO file implementation

Using .VSDISCO files benefits developers in several ways. These files contain only a small amount of data and provide up-to-date information about a server's available Web services. However, .VSDISCO files generate more overhead (i.e., require more processing) than .DISCO files do, because a search must be performed every time a .VSDISCO file is accessed.

A typical WSDL implementation

Well, eventually it seems like there is no purpose to DISCO/VSDISCO files since UDDI is not actually used. Probably initially it did sound like a good idea but is not "that" usable; because actually or usually a client learn that a web service exists is because someone tells the URL of the WSDL file.

It may probably help in future when everything is going to be service oriented. Every functionality over the web; when Grid Computing would be a smalltalk in IT industry.

An in-depth article by Aaron Skonnard is worth the time. And also, he tells about the reason why did .VSDISCO documents stop working with the final release of the Microsoft .NET Framework. This tutorial is an excerpt directly from Dietel.

Seldom we find a need to dig inside a technology and know it inside out. HttpHandlers is a similar interesting topic and I plan to write about in future; lets see when it comes out.

Stay tuned (0:

Friday, February 12, 2010

JavaScript: A Quick 'Back-Button'

JavaScript: A Quick 'Back-Button'

Some time back I wanted to a quick Javascript based 'Back Button' functionality. So I used following:

Back

Though above did come handy as a solution, but it was full of surprises as well. The "con" that comes along is something that your application may not desire/intend.

For instance, in cases where you, lets say, are designing a page that performs an online bank account transaction; and along with other forms' elements you also have a "Submit" button, that gets disabled after you click it; precisely to avoid duplicate transaction.
You click on the submit button and the application throws you on to a next page that has this "<< Go Back" link. Now your spine may get a shiver or two to know that after coming back to the orignal "online-transaction" page, your "Submit" button is disabled. Now WTF?

It is because, usually, when a Form gets validated, we tend to disable the Submit button to avoid multiple hits; Specially in cases of online/form based transactions.

So what can we do about it?

1. Use Back Button where validation is not being performed. Or there is no Form/elements.

2. Use AJAX for on-the-fly validation, and show validation messages on the same page.

3. Use Server.Transfer(Url) to go back.

4. Or probably handle the UnLoad event which will enable the button back to original state using JavaScript.

Happy Go-Back buttoning! (0:

Friday, February 5, 2010

"5 Dysfunctions of a Team" and our Society

Though several times attempts were made(by my sweet mom) to dispose off the contents of my small book rack, along with the rack! - reason being the space that it takes is too much.

While I was cleaning up and rearranging, I came across this Patrick Lencioni's The Five Dysfunctions of a Team.

The book is a gift from by previous Boss, who truly is a great mentor, back in 2007.

At some point you may feel that this text is moving towards a tangent, but in actual thats intentional; I would be "mapping" how the ideas of Patrick maps to the society that we live in, in specific, and the world in general.

The crux of the book is that, the key to any relationship, be it personal or professional, is Trust.

'Trust', as Patrick in his bestseller fable puts it, 'is related to communication'.

Meaning? the more you communicate, the more you talk, the more you share, the more you meet, therefore 'generally' you tend to trust more; and that 'trust' part is inherent to communication.

The five dysfunctions of a team are:

  • Absence of trust
  • Fear of conflict
  • Lack of commitment
  • Avoidance of accountability
  • Inattention to Results.

He believes that trust is an essential part of (an emotionally, psychologically, and spiritually healthy) life -- and it is truly a blessing to be able to feel comfortable/confident in a relationship.

Trust is the core; trust is when one would tell you something good/bad about you without having the 'fear of conflict'. Professionally, if someones coming to you and telling you a fault in your project plan then that person is 'trying' to show the trust. Your reaction would set the bounds of encouragement/discouragement of the trust. If you would react badly, probably next time she is not going to discuss your faults with you; but if you are going to discuss about the fault, listen and resolve - then that would lead to greater trust, gelled relationship.

Now obvisouly when Patricks talks about it professionally - for a professional team of individuals, he means that attitude is important, a building block as a part of relationship. Observation and performance is coherent. Meaning if a person has as an attitude of performing well, he/she would perform anywhere. Make him a mochi(cobbler) he would become a great mochi, make him a doctor, he would become a good doctor; well... I hope you get the idea.

In his book he depicts a team of higly qualified professionals having tough time with each other and to deliver the output. There are several members of the team and how a Chief Technologist always keeps on typing on his laptop in every meeting. How a communication consultant was hired by the top management and the way she drags them to talk to each other and brought them to a point that they were able to even yell over each other without doubting the trust. By yelling I mean, even by questioning the authority of the decision. Imagine one department head questioning the decision of another department. Usually this doesnt happen in companies; it only happens there where trust prevails. And eventually how a decision was made a fired out of them.

Its a great one-sit read.

The pyramid that Patrick always refers to(I was able to find an exact image that is on the book) following figure.

But using what Patrick said, in terms of a Society; what is required, is to assure existence of an active cooperative process that makes people appreciate the contributions of others to the general society. And to support the potential for such cooperation.

The problem that I see with our society is that we lack trust upon each other; reason being seldom we communicate.

Imagine Scenario 1: Your Suzuki FX, which is on the front lane, is 5 seconds late when the green light pops on the traffic signal? The guy right behind you would see you like he's going to swallow you along with your FX, unfried and with-bones! Some would even dare to yell like anything calling names and all other crap burning their hearts and releasing negative energy back into the society.

Imagine Scenario 2:
Some how while stopping your Suzuki FX on the front lane, you were able to say 'assalam o alaikum' or 'hello-how are you' and wave your hand or nod your head with a little smile; and you get a similar response in return.

Now, you will notice that reaction would change; and even if you take 27 seconds to move your vehical past the green signal, the guy right behind you wont say a word(atleast he won't' say anything - don't trust me, try it yourself). He is just going to wait. Why?

Because he just had a talk with you. So, whats with the talk? A natural behavior, after we talk to someone the actions inclines toward politeness. I believe that just comes as a basic human instinct; and this talk(communication) is what Patrick refers to, that turns on light the of 'trust' in society. And obviously we can always use "Assalam O Alaikum" as a tool to break the ice.

There is this last section of the book called "The Model"; and I would like to type some of it for you, because it worth listening:
"As difficult as it is to build a cohesive team, it is not a complicated. Infact, keeping it simple is critical...

...1. They trust one another
2. They engage in unfiltered conflict around ideas.
3. They commit to decisions and plans of action.
4. They hold one another accountable for delivering those plans.
5. They focus on achievement of collective results.
If this sounds simple, its because it is simple, atleast in theory. In practice, however, it is extreemly difficult because it requires levels of discipline and persistence that few teams can muster."

At the end of the book there is team assessment technique that the writer has shared; with a table and a set of questions to help teams.

As-Salamu Alaykum! (0:

Related Posts

Popular Posts