• --message
• --contract
• --queue
• --service
• --route

--1.First you need to Alter Database to enable ServiceBroker if it is not yet enabled

--Test is my DBname

ALTER DATABASE Test SET ENABLE_BROKER

Go

--2. Create a message type. In addition you can supply the schema to validate the Messagetype

--the other schema validation options are EMPTY,WELL_FORMED_XML

CREATE MESSAGE TYPE MyTestMessageType

Validation=NONE

Go

--3.Now lets create a contract on the above message type

--you can specify the ownername and initiaitor,target or any for the sentby

--we ll use ANY means message can be send by both initiator and target

CREATE CONTRACT MYTestContract

(MyTestMessageType SENT BY ANY)

CREATE QUEUE MyTestSendQueue

CREATE QUEUE MyTestReceiveQueue

Go

--5.Now we need the Service which we ll use to send and receive messages

--you can create service with one,multiple or no contract

--what we need here is the Queue and the contract

CREATE SERVICE MyTestSendService

ON QUEUE MyTestSendQueue (MYTestContract)

CREATE SERVICE MyTestReceiveService

ON QUEUE MyTestReceiveQueue (MYTestContract)

--6. Now lets begin the dialog from one service to another

-- we need the from and to services and the contract

--optionally we can specify the lifetime , encryption and conversion group

DECLARE @dialog_handle UNIQUEIDENTIFIER

BEGIN DIALOG CONVERSATION @dialog_handle

FROM SERVICE MyTestSendService

TO SERVICE 'MyTestReceiveService'

ON CONTRACT MYTestContract

WITH ENCRYPTION=OFF

--OK WE have setup Now Let Start Sending and Receiving messages

--7.what we need here is first get the conversion handle from tr

-- The first step is to get the conversation handle from the sys.conversion_endpoints

DECLARE @conversation_handle uniqueidentifier

SELECT @conversation_handle = conversation_handle

FROM sys.conversation_endpoints

WHERE far_service = 'MyTestReceiveService';

SEND ON CONVERSATION @conversation_handle

MESSAGE TYPE MyTestMessageType

(N'Test Message Send by Sender:Example Shreeman ')

RECEIVE convert(nvarchar(max), message_body)

FROM MyTestReceiveQueue

However when we discuss about Enterprise webservices[or services itself] there are many more things you might confront with to build a successful Service Implementation like :-the Service layers, Development processes, Testing process ,Deployment, Message Patterns, subscription models, Monitoring,Security,Schema or contract,Provisioning,Discovery,Policies,Auditing,Compression,Transactions,Realibility,Protocols,Collaboration,Interopability ,Metadata Exchanges and so on the list goes on..

You might think why the hell I need to consider all these? Does this much of complexities needed to be incorporated into the services? Certainly not for all scenarios but most of the times you need many of these and all these are requirement driven like security,scalability,performance,realibility and loose coupling etc.; and to provide those aspects to your services you need to fall onto to the ones I ve listed above[there are many more].

Interestingly the list I have provided above becomes more and more complex and more confusing if you start poking around the web to see more and more stuff like the REST Approach[REST guys should read the opposite way of the SOAP and WS* approach] vs SOAP and WS* ,SOA and CodeFirst vs. ContractFirst and I would ask developers to not to delve themselves into this mud at first GO and better Go for feature wise support and if at all possible let this part pass to the architecture team .Let me further tell you that the same is the story in other arena too like Web 2.0,GRID computing and ESB are a great example of this trend. However in the WebService world the major players were Microsoft, IBM, Sun, Google, and Yahoo etc and there are many players in the other arena I ve mentioned above. I ll quickly like to mention here that there are also a significant presence of many Opensource, Research Org and minor players in this Fight.

Now that we saw what all are going around the Service World I ll try to quickly grab few of the important aspects to wrap this article up so that we can have a better view why all these fuss are there and what are those all about.

So, the reason why all these came into the picture is due to the fact that how you provide different features for your enterprise services [let me better say web services] which ll have support for Security, Realiability, Scalability, Event, Transaction and so on   and major vendors [Microsoft, IBM and many others…] came together to form the WS* stack which supports the stack for allowing your Service to provide features for the above. Following the same trends could also have solved the WS interop scenario too but different vendors has different implementation and a true WS-Interop again becomes a design articraft. Further to that the twist come from REST and the heaviness of the WS* stack questioned [I ll discuss the REST vs WS* later and the new twist to this with the WEB 2.0 trend is XML vs JSON which I ll dig in some future post].Now the question was how to expose the WS* standard and functionalities in the services and again major player had provided framework and extension to make this happen and Microsoft with WSE provides support for WS-Security,WS-Policy,WS-Addressing as well as WS-RealiableMessaging and IBM and SUN were also had provided their own way of implementing the WS* stack.

Ok its look fine and I got my Services capable of handling Security, Eventing-addressing and RealibaleMessaging what else? Actually there were a lot more and more and more WS*specs came out to help addressing those like WS-Metadataexchange,WS-AtomicTransaction ,WS-BPEL and so on [see the WS link above for detail list].

Microsoft with WCF and SUN/IBM with SCA has added capabilities to build services which support more WS* stack. However let me point you out here that WCF is not all about the WS* but it does have many enhanced features and I ll cover those shortly. So far I didn’t touched or written on the Interop, SOA and other useful add-ons to Services like the compression and MessagePatterns, Collaboration …so on because it is not possible to complete the entire stuff in this post and I am keeping few spaces for the REST vs WS story .However while Posting the WCF series I ll try to cover these aspects .For now this ll be enough to mention that with the new framework all these have been enhanced, incorporated and still many works is going on for further improvements .

Another Buzz you must ve dealt with or at least heard about was SOA but SOA doesn’t necessarily Web Services but its more about the Architectural Style to built services which provide more business values, Scalability and reusability etc.; Actually the WS* stack and SOA are quite related from the point of view that SOA tells u about certain servicebehaviors and their impact and usefulness and many of the WS* were generated to provide those features.

Example:-WS-Policy, WS-Metadataexchange etc;

From MS point of view SOA is svc which incorporate different tenats like “boundary are explicit”,”Share Schema or contracts not classes”,”Services are autonomous”,” Service compatibility is based upon policy”.So the question might come can I build a SOA enabled Svc today with ASMX and the answer is of course you can and going fwd all the major FRX will provide more support to built the SOA patterns into your services.No more SOA here as this ll again lead to a long post. 

So , before leaving the WS* here I would like to mention that an Enterprise Distributed Service needed much functionalities and the ASMX alone was not the final stop but was an intermediate stop and there were many challenge required to be addressed with and which lead the major players to create  new Distributed Message Oriented Frameworks. In future post we ll see how these have been addressed in WCF and what all challenges we still needed to dealt with. I ll update the post to provide more details on these later...

 REST vs WS* for the LAST Time:-

I ll now reinvent the Wheel around the REST [vs] the WS* or POX vs SOAP approach and there already a lot of posts around this and basically it’s an architectural style you need to decide which one you should opt for? Although the REST kick started with Fielding's Work it’s got a new dimension and popularity with yahoo, Amamzon and Google’s WebSvc API implementations which follow this Architectural approach which suggest a URI or resource driven approach with plain XML against the already available http commands [GET, HEAD, PUT and DELETE] which eliminates the need of the SOAP and the thick WS* layers .You can see the approach here is a ResourcesOrieneted Arch [all the services have a specific URI and you are issuing your command against that URI[resources] and since its minus SOAP its lightweight and with the new PNPR its look like a more compelling arch but hangs on before jumping entirely to REST approach.Although it’s a good approach and the ResourceDriven approach might be a compelling one[I m not comparing SOA ve the ROA(Resource Oriented arch) there are still few functionalities lacking in the REST approach ,the primitive one is being a suitable framework and the support for security, reliability ,Metadata exchanges and so on but the question here is do I need these? if not isn’t REST a better approach .Yes it is but there are very little guidance and information available and for incorporating the different addons you need to reinvent the wheel a lot [ I am no discouraging anyone here and if your svc does not need the complexities of various WS* stack you can go for POX and in past you can see quite a few  POX with Http implementations] and you can’t make guarantee that with all these incorporated your svc still remains the thinner .However the REST approach is now supported by WCF and I hope SCA also ve support for this[didn’t verify this though] and you can built a framework with Hybrid approach .There are still a lot discussion and work going on and with the new WEB 2.0 and B2B and P2P technologies more changes in architectural approach are likely to come.

 Here are the resources you ll find useful on this hot debate.

 To understand the WS* or WS-Specifications  from www.w3.org and this msdn article “Intro to WebSvc  Arch and its Specification ” provide a detail read and also provides the links to primitive websvc specs

 REST vs SOAP / POX vs SOAP /REST vs WS*

http://cafe.elharo.com/web/rest-vs-soap-a-parable/

http://www.trachtenberg.com/blog/2006/11/06/rest-vs-httppox-vs-soap/

http://www.forrester.com/Research/Document/Excerpt/0,7211,35361,00.html

http://www.prescod.net/rest/security.html

http://www.oreilly.com/catalog/pwebserperl/chapter/ch11.pdf

http://blogs.iona.com/vinoski/archives/000149.html

http://www.1060.org/blogxter/entry?publicid=9FFBC835E3D9904A288982A638A8F45B

http://www.xml.com/pub/a/2004/12/01/restful-web.html

REST and Web Services: The ZapThink Take ZapFlash

Paul Prescod: on REST - Second Generation of Web Services

Don Box: SOAP vs. REST

Dion Hinchliffe: Creating Open Services That Last (And Anyone Can Use)

Danny Ayers - Is REST too complicated?

REST APIs, examples, documentation and bits

eBay’s REST API

Amazon REST API

Tagtooga's List of REST APIs

 Rest ful Svc : http://home.ccil.org/~cowan/restws.pdf

John Udell - Amazon's pragmatic approach to metered infrastructure

The Loyal WS Opposition:- http://www.tbray.org/ongoing/When/200x/2004/09/18/WS-Oppo

Service Orientation, the Hype Cycle, and a RESTaurant : Mike Champion: http://blogs.msdn.com/mikechampion/archive/2005/03/23/400961.aspx

MS Ignoring developer demand for REST tools? http://blogs.msdn.com/xmlteam/archive/2005/02/15/372982.aspx

Understanding the Place of POX, SOAP and WS-* in Building XML Web Services  : http://blogs.msdn.com/dareobasanjo/archive/2005/02/15/373067.aspx

http://webservices.sys-con.com/read/79282_2.htm 

http://www.prescod.net/rest/rest_vs_soap_overview/

Read http://www.ics.uci.edu/~rohit/ARRESTED-ICSE.pdf

http://portal.acm.org/citation.cfm?id=999447

RYAN [the way he has presented is really a good one to watch out for "How I Explained REST to My Wife“and The Highs and Lows of REST for more on REST.

Tim O'Reilly - A Week in the Valley: GData

Optimistic concurrency (versioning)

sqlREST and 15 minutes Guide to sqlREST

Don Box: HTTP, XML, REST and $100 -

Popular REST tagged articles in Del.icio.us