SQL Server 2005 Notification Services Components Package Availability

Question

The SQL Server 2005 Notification Services component package made available in the February 2007 release of the Microsoft Feature Pack for SQL Server 2005 is being updated to include Notification Services components, such as Notification Services server and client components, but will not include Management Studio integration.  These updated components are designed to work with SQL Server 2005 and SQL Server 2008 databases.

 

The SQL Server 2005 Notification Services components package update will be released in two phases:

 

Phase 1: RC1

The SQL Server 2005 Notification Services component package RC1 is available from the Microsoft Download Center.

 

This release is a pre-release version and is available only for testing.  Product support is not available for this pre-release.

 

Phase 2: RTW

Release to Web (RTW) will be released as part of the Feature Pack update currently scheduled for release as part of SQL Server 2005 Service Pack 3 (SP3).  SQL Server 2005 SP3 is targeted for calendar year 2008.  The SQL Server 2005 Notification Services component package update will be subject to the SQL Server 2005 Product Support Lifecycle policies.

 

SQL Server 2005 SP3 Notification Services

Starting with SQL Server 2005 SP3, the updated Notification Services will support using either SQL Server 2005 or SQL Server 2008 to host Notification Services Instance and Application databases.

 

Changes introduced in the Updated Notification Services Components Package

We have not changed core functionality of Notification Services in the components package.  We made limited interoperability fixes to enable Notification Services command line tools and service components to work correctly when using a SQL Server 2008 Database Engine to host the Notification Services Instance and Application databases.

 

No feature additions were made. 

 

Phase 1: RC1 - Deploying SQL Server 2005 Notification Services Components Package

 

The RC1 package can be installed on the same computer as an existing SQL Server 2005 Notification Services deployment. The existing deployment will automatically use the new service components installed by the RC1 package.  Any Notification Services instances running on the computer should be stopped prior to installing the RC1package.

 

Before installing the RC1 Package, you will need to install a SQL Server 2005 Cumulative Update to enable Notification Services to connect to a SQL Server 2008 database server.

 

For the purposes of testing the RC1 package, the following prerequisites are needed:

 

1)      SQL Server 2005 Notification Services

2)      SQL Server 2005 SP2

3)      Cumulative update package 9 for SQL Server 2005 Service Pack 2, or later

 

If you do not have SQL Server 2005 installed and wish to test the RC1 Package, an option is to install the Evaluation Edition of SQL Server 2005 for the purposes of testing RC1.  Please note that the Evaluation Edition does have a limited license term (please see the Evaluation Edition license terms for details).

 

The Future of Notification Services

SQL Server 2005 is the last planned release of Notification Services. Microsoft believes “alerting” scenarios are valuable to our customers and we are looking at ways to include them in future product offerings.

Answer 1

I'm coming at this discussion a bit late as it is now December. It is my view that Microsoft should rethink its position on Notification Services, and should continue to support and evolve it until such time as it might be migrated to the future "alerting" solution Microsoft devises for at least the following 2 reasons:

(1) Notification Services addresses an enterprise application integration need complementary to Microsoft's web service strategy. This is a place Microsoft has not gone before, but needs to go. Why? EAI vendors won't modify their infrastructure to make them web service oriented. Microsoft already has. Further, it has commoditized such so that a full complement of architectural components has been assembled. Why would Microsoft make such an investment ... across the portfolio of server products ... and then back off such an investment? Microsoft has not been in the enterprise space before to the degree it has wished. It has intimated, at least, that it will be at the periphery with its variety of services and products. An integration broker is necessary for success at the periphery, and it provides a bridge to the enterprise back office that has the property of loose coupling. 

(2) Microsoft claims to be working to develop a server platform suitable to provision notification services ... with functionality that could be extended in an open source Microsoft community. Microsoft has stated elsewhere that it intends to provide a kind of application server foundation that would make it possible for non-Microsoft development teams to build out services on a Microsoft stack that can be hosted with the same set of services as, say, IIS, Biztalk, SQL Server, etc. It seems that Notification Services could easily be migrated to this server framework once such is ready for prime time. Functional expansion of such could be accomplished by an open source community if Microsoft chooses to not further extend it on its own dime ... maybe even on its own nickel.

I've read some of the reasons justifying Microsoft's rationale to discontinue its Notification Services product line. One was that not many people used it. Blogs have listed a number of companies that have used it. The number may not be to the scale Microsoft would like ... one could look at Biztalk and suggest that Workflow Foundation represents Microsoft's belief that Biztalk too should be deprecated. Maybe so. But the strategy Microsoft is taking with workflow does not drop support for a core architectural capability. Why not keep it? It probably costs you little ... and you have an open source community option that could get Microsoft further into an enterprise than it has previously been ... right into the middle ... leveraging its web service innovations in spades. One more thing ... people have to learn how to use Microsoft products in an enterprise context ... aside from specialized applications, what products have you put out that systematize infrastructure?

I've also heard that Microsoft is considering incorporation of Notification Services as part of Reporting Services. Please pardon me but that seems ack basswards ... events are not reports, but reports could be events if you view reports as correlations over critical business activities instead of some statically produced bit of information to be shoved off into someone's mailbox or file system or even web site. Reports are static. Events are part of a dynamic and learning enterprise platform. Isn't that what you're attempting to build infrastructure for?

Please reconsider your position. And please contact me at tommy  at zipa dot deedoodah dot com to discuss. I'm as opinionated as everyone else, and I think you have a good product here that you're throwing away. If you don't want it, I will take it ...

Sincerely,

Tom Winans

Answer 2

Yeah i would like to completely second the thoughts of Tom on notification aspect of Sql Server. It would surely break many a hearts (mine surely is), cos it really was a unique & robust technology. I think Microsoft should think on carrying it forward in Sql Server 2008 as well.

Regards

---

Apps Dev

Answer 3

That other elcarO database has been doing this for eon. In an anti MS shop, being the only pro MS , I get to shut up everytime the argument comes up. You open the connection, create your queue objects then pass a pointer to a func where you get a callback. No polling and you get the data when it's available. Of course you must maintain a connection. It's awsome. If they can do it, MS can do it even better. So I don't understand why this callback it's not
popular with SQL Server.  By the way it's does not cost extra. I know it's just a matter of time. It's coming right guys?