Archive for January, 2007

Microsoft-Teradata Collaboration

Posted: January 22, 2007 in Uncategorized
After MS-SAP and MS-LINUX and MS-EssBase its now MS-Terradata colloboration read the details here:-
Often you are into a SQL interview and you ll see a common Question When to use a temp table vs when to use a table variable and different variations to this often floated around in many Sql Invw Faqs.The SQL Programmability and API developement team  put a indepth post on this issue , one you should peek into.Here is the link prior to this Jerry also had a indepth post with few good observation here

Initialy my thought was should i post this or not ,since a lot alreday happen and written on this but fianlly i found that i can post this may be this ll be useful for someone else.This is what i had used and saved as a script during my test of the service broker functionality.So here you go:-

steps to create a simple service broker what you need

  • –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



–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




–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


(MyTestMessageType SENT BY ANY)


–4.We have the messagetype and contract now let Create a send and receive queue


CREATE QUEUE MyTestReceiveQueue


–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


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



FROM SERVICE MyTestSendService

TO SERVICE ‘MyTestReceiveService’




–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’;

–8.send conversion using the handle

SEND ON CONVERSATION @conversation_handle

MESSAGE TYPE MyTestMessageType

(N’Test Message Send by Sender:Example Shreeman ‘)


— 9.Now receive from the queue

RECEIVE convert(nvarchar(max), message_body)

FROM MyTestReceiveQueue


–10.Drop all see the order and the case sensitiveness

–do also remember the quotes used in to Service in section 6

— and the farservice one

–finally the drop order would be

–drop service MyTestSendService

–drop service MyTestReceiveService

–drop contract MYTestContract

–drop queue MyTestSendQueue

–drop queue MyTestReceiveQueue

–drop message type MyTestMessageType


 Here are few articles which might give you further start:-

roger’s archotecting service broker:

In PART-I and PART-II of this series we saw what are the webservices challenges and how Asmx 2.0 try to address few of those however there are quite a few things left like  RESTful Services ,WS* stacks [including WS-Security & WSE,WS-AT and WS-RM [transaction],WS-Eventing ….] ,SOA ,Interop etc.; Although each of these topics itself are too vast to cover in a single blog post, I ll try to cover all these in this post [final one of the series] randomly before moving to WCF .The reason I had started this series is because it ll provide you a solid ground on what is available today and what WCF is providing [although WCF is not about Web Svc] and what functionality you might still be looking for some future stack.

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 and this msdn articleIntro 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*,7211,35361,00.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



Tagtooga’s List of REST APIs

 Rest ful Svc :

John Udell – Amazon’s pragmatic approach to metered infrastructure

The Loyal WS Opposition:-

Service Orientation, the Hype Cycle, and a RESTaurant : Mike Champion:

MS Ignoring developer demand for REST tools?


Understanding the Place of POX, SOAP and WS-* in Building XML Web Services  :


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