"As I understand best practices for Web services today from the Microsoft point of view, the usual
best way to approach this is NOT to use Service Broker but rather to use the Windows Communication
Foundation."

I guess I just fail to see how SB gets thrown into the mix where web services are discussed. SB
doesn't have anything to do with web services. Or perhaps one should say it has as little with web
services as MQ does.

As for the other aspects, I'm not the right persona to answer. Perhaps somebody else jumps in here,
but you are probably better off going to some Windows programming group for that...

Thanks, Tibor.

As I understand best practices for Web services today from the Microsoft point of view, the usual
best way to approach this is NOT to use Service Broker but rather to use the Windows Communication
Foundation. That is how I read this:

http://msdn.microsoft.com/en-us/library/ms996406.aspx

which says:

"....In this paper, I outlined the motivations for adopting a Service-Oriented approach to designing
and building distributed systems. I discussed how and where to most appropriately use the current
Microsoft suite of distributed technologies to implement these systems. My summarized guidance is as
follows:
 a.. Build services using ASP.NET.
   a.. Enhance your services with WSE if you must support WS-*.
 b.. Keep components inside your services.
   a.. Use Enterprise Services where appropriate.
   b.. Use .NET Remoting where appropriate.
 c.. Use MSMQ for queued messaging.
 d.. Use BizTalk if you need to orchestrate loosely coupled business processes and/or to integrate
several disparate systems and technologies.
 e.. Use SQL Server Notification Services if you need to build a data-oriented, asynchronous,
queued application.
By following this guidance you'll be well aligned with Microsoft strategy. This will enable you to
adopt and adapt the current Microsoft technologies and take advantage of the powerful distributed
systems technologies we will be delivering in the future to help you build, deploy and operate your
distributed services more easily than ever before..."

So, it is unlikely that I should go with Service Broker and more likely that I should use .asmx
services, yes?

Also, as I understand WCF, formerly "Indigo" and formerly "WinFX"... that it actually is just the
name for the suite of tools found in Visual Studio 2008:

http://msdn.microsoft.com/en-us/library/aa480188.aspx

"...Unification of Microsoft's Distributed Computing Technologies
The initial releases of the .NET Framework included several different technologies for creating
distributed applications. The figure below lists each one, along with the primary reason why a
developer would typically use that technology. To build basic interoperable Web services, for
example, the best choice was ASP.NET Web services, more commonly referred to as ASMX. To connect two
.NET Framework-based applications, .NET Remoting was sometimes the right approach. If an application
required distributed transactions and other more advanced services, its creator was likely to use
Enterprise Services, the .NET Framework's successor to COM+. To exploit the latest Web services
specifications, such as WS-Addressing and WS-Security, a developer could build applications that
used Web Services Enhancements (WSE), Microsoft's initial implementation of these emerging
specifications. And to create queued, message-based applications, a Windows-based developer would
use Microsoft Message Queuing (MSMQ).

       ASMX .NET Remoting Enterprise Services WSE MSMQ Indigo
     Interoperable Web Services     X             X
     .NET - .NET Communication       X           X
     Distributed Transactions, etc.         X         X
     Support for WS-* Specifications           X       X
     Queued Messaging             X     X

All of these options had value, yet the diversity was certainly confusing to developers. Why have so
many choices? A better solution would be to have one technology that addresses all of these
problems. With the arrival of Indigo, that technology has appeared. Rather than forcing developers
to choose one of several possibilities, Indigo lets them create distributed applications that
address all of the problems solved by the technologies it subsumes. While Microsoft will still
support these earlier technologies, most new applications that would previously have used any of
them will instead be built on Indigo..."

So am I correct that I should in most cases be using ASMX?

Thanks,

Bill Ross

 "Tibor Karaszi" <tibor_please.no.email_karaszi@hotmail.nomail.com> wrote in message
news:5DC84490-8A08-45B7-96B1-3E068DBA55AD@microsoft.com...
 IMO, SB and HTTP Endpoint are totally different things.

 HTTP Endpoint allow you to expose a stored procedure or function as a web service method. It is as
 simple as that. All needed is a CREATE ENDPOINT command (and security in place) and you are done.

 Service broker allow you to post and read messages from queues. It include functionality to
 guarantee delivery, read in order etc. And SB also allow you to communicate messages between two
 databases and even instances. In the later case, you need to define SB endpoints so that SQL
Server
 on one instance has some way to reach into the other instance to deliver the message.

 HTTP Endpoints are deprecated in 2008, so you don't want to go that route...

 --
 Tibor Karaszi, SQL Server MVP
 http://www.karaszi.com/sqlserver/default.asp
 http://sqlblog.com/blogs/tibor_karaszi

 "Bill Ross" <billross@bibleshockers.com> wrote in message
 news:369E1296-AAD3-4E9C-978B-CC1897342527@microsoft.com...
 MS constantly impresses me with their ingenuity... but I am often overwhelmed. Especially when it
 comes to SQL Server and the myriad of data access choices and acronyms. The Help system is a
jumble
 of choices.

 For example, what is the relationship between HTTP Endpoints and Sql Service Broker? Or, to put it
 another way, would I ever NOT use Service Broker if I want to do Soap access to the data?

 My current project would allow me to choose whatever database I would like as well as any access
 method (though it will be web based, and I have opted for SQL Server). I don't exactly NEED to
 approach this as a Web Service, but I love the idea of getting most of the data issues managed at
 the database level and having dumber clients consume them.

 I'm assuming Crystal Reports can consume Service Broker web services?

 Ok, so what I am envisioning is this:

 * Sql Server, via stored procedures and Service Broker functions, etc, serves up the data, with
the
 business rules enforced, to the clients via SOAP;
 * Initially most of my clients will be asp.net/c# web pages and Crystal Reports that reside on the
 same server, but I can conveniently consume the same services with ad hoc consumption by Office,
 etc;

 As I understand Service Broker, I can tap into the CLR by "Using System" and "Using System.Web"
etc?

 Thanks,

 --
 Bill Ross
 http://billrosspolitics.blogspot.com
 http://bibleshockers.blogspot.com