| Groups | Blog | Home |
sql server notification services : NS API Question
is to have interfaces exposed as web services from SQL 2005 directly that allow for the management of NS subscriptions. This would allow the existing ASP.Net 1.1 code to call the service without having to install all the NS client pieces on the web server. This question may be more appropriate for SQL 2005, but thought I would
Yes, you can wrap the NS APIs in Web Services. I have not seen an
implementation of this, but I've heard the idea talked about a lot and don't see any reason why it should not be technically feasible. -shyam -- Learn more about SQL-NS: http://www.amazon.com/exec/obidos/tg/detail/-/0672326647/ --------------------------------------------- This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm. --------------------------------------------- [quoted text, click to view] "andyjax" <andyjax@newsgroup.nospam> wrote in message news:E30CCF5F-D1DE-4F27-98B2-9D6621FBF86C@microsoft.com... > Is it possible to have an assembly in SQL 2005 to expose the NS API? The > idea > is to have interfaces exposed as web services from SQL 2005 directly that > allow for the management of NS subscriptions. This would allow the > existing > ASP.Net 1.1 code to call the service without having to install all the NS > client pieces on the web server. > > This question may be more appropriate for SQL 2005, but thought I would > through it out there.
My thought was how to get the API's to be called from an assembly in SQL
2005. If you try to set a reference to the NS API, then it won't let you. You have to completely build the class yourself in a DB project, or reference another DB project that has assemblies you want use. We will end up needing to install IIS on the SQL box, yuck - but will do for our dev environment only, or just want to install NS client components until ..Net 2.0 is released later this year. I will post in a SQL 2005 to see if there is just a limitation for the June CTP we are running using BETA 2 VS. Thanks Shyam, I am amazed at home must information you put in your NS book. Like anything you read it does not make sense completely until you are ready to implement a section, then it is just a matter of remembering where the information is in your book. Again, great job! Anyone getting started with NS needs to have this book in their library. [quoted text, click to view] "Shyam Pather [MSFT]" wrote:
> Yes, you can wrap the NS APIs in Web Services. I have not seen an > implementation of this, but I've heard the idea talked about a lot and don't > see any reason why it should not be technically feasible. > > -shyam > > -- > Learn more about SQL-NS: > http://www.amazon.com/exec/obidos/tg/detail/-/0672326647/ > --------------------------------------------- > This posting is provided "AS IS" with no warranties, and confers no rights. > Use of included script samples are subject to the terms specified at > http://www.microsoft.com/info/cpyright.htm. > --------------------------------------------- > "andyjax" <andyjax@newsgroup.nospam> wrote in message > news:E30CCF5F-D1DE-4F27-98B2-9D6621FBF86C@microsoft.com... > > Is it possible to have an assembly in SQL 2005 to expose the NS API? The > > idea > > is to have interfaces exposed as web services from SQL 2005 directly that > > allow for the management of NS subscriptions. This would allow the > > existing > > ASP.Net 1.1 code to call the service without having to install all the NS > > client pieces on the web server. > > > > This question may be more appropriate for SQL 2005, but thought I would > > through it out there. > >
[quoted text, click to view]
>From our experience and what Shyam is saying you certainly dont need IIS on the SQL box. If you create a webservice round the API elementsthat you want and install that on your webserver, you can then call than from the SQL 2005 assembly via a SOAP call without any need for the NS or IIS elements to be present on the SQL box. This is how the Reporting Services SOAP interface works and is very effective. We have implented a similar strategy for SQL2000 and that works very well with no need for the SQL box to have even heard of NS. Kate MBCS Alert Technologies http://www.alert-technologies.co.uk Get your notification services implementation going in minutes not weeks ......
Yes I am familar with how web services work, but just to keep the web
servers clean the idea was to have the .Net 1.1 apps call to the SQL box for the API's that were wrapped as a web service. Since I have not been able to get SQL to register and assembly that I can expose as a UDF, which then could be exposed as an endpoint, we for now are resorting to installing IIS that will be the webservice. I really don't want to have to register the assembly in the GAC, but that seems like another way to get things done. We are trying to get our prototype up and going before the .Net 2.0 is release as gold code. We have a limited number of develop boxes, so we don't want to install beta software everywhere that may cause a complete rebuild when gold code is available. Once the gold code is available, then the web servers will have the NS API installed and they will make the calls that way. Our system will be physically separated, so the idea was to just have a WS on the NS box which is remote. Otherwise the API is making a remote call over firewalls etc, so we would probably be better served to use WS. This is all more than you really were looking for, but just thought I would lay it on the line. I guess we should pose some of this discussion to our TAP channels. [quoted text, click to view] "kate" <k@alert-tech.co.uk> wrote in message news:1123759816.702528.301810@g47g2000cwa.googlegroups.com... > >From our experience and what Shyam is saying you certainly dont need > IIS on the SQL box. If you create a webservice round the API elements > that you want and install that on your webserver, you can then call > than from the SQL 2005 assembly via a SOAP call without any need for > the NS or IIS elements to be present on the SQL box. This is how the > Reporting Services SOAP interface works and is very effective. > > We have implented a similar strategy for SQL2000 and that works very > well with no need for the SQL box to have even heard of NS. > > Kate MBCS > > Alert Technologies > http://www.alert-technologies.co.uk > Get your notification services implementation going in minutes not > weeks ...... >
This is just to let you know that I've relatively recently implemented
a reasonably complete Web Service wrapper around the NS Subscription API, resolving some gotchas along the way of course. Feel free to email me at "mark dot weiss at moodys dot com" if you feel I may be helpful in any way. [quoted text, click to view] Andy wrote:
> Yes I am familar with how web services work, but just to keep the web > servers clean the idea was to have the .Net 1.1 apps call to the SQL box for > the API's that were wrapped as a web service. Since I have not been able to > get SQL to register and assembly that I can expose as a UDF, which then > could be exposed as an endpoint, we for now are resorting to installing IIS > that will be the webservice. I really don't want to have to register the > assembly in the GAC, but that seems like another way to get things done. > > We are trying to get our prototype up and going before the .Net 2.0 is > release as gold code. We have a limited number of develop boxes, so we don't > want to install beta software everywhere that may cause a complete rebuild > when gold code is available. Once the gold code is available, then the web > servers will have the NS API installed and they will make the calls that > way. Our system will be physically separated, so the idea was to just have a > WS on the NS box which is remote. Otherwise the API is making a remote call > over firewalls etc, so we would probably be better served to use WS. > > This is all more than you really were looking for, but just thought I would > lay it on the line. I guess we should pose some of this discussion to our > TAP channels. > > > > "kate" <k@alert-tech.co.uk> wrote in message > news:1123759816.702528.301810@g47g2000cwa.googlegroups.com... > > >From our experience and what Shyam is saying you certainly dont need > > IIS on the SQL box. If you create a webservice round the API elements > > that you want and install that on your webserver, you can then call > > than from the SQL 2005 assembly via a SOAP call without any need for > > the NS or IIS elements to be present on the SQL box. This is how the > > Reporting Services SOAP interface works and is very effective. > > > > We have implented a similar strategy for SQL2000 and that works very > > well with no need for the SQL box to have even heard of NS. > > > > Kate MBCS > > > > Alert Technologies > > http://www.alert-technologies.co.uk > > Get your notification services implementation going in minutes not > > weeks ...... > >
Thanks for the background. Sounds like you have a plan. I think
everyone is having hassle with these last months before .Net 2 and yukon hit us. Kate MBCS Alert Technologies http://www.alert-technologies.co.uk Get your notification services implementation going in minutes not weeks ......
Here is what someone posted back from the SQL 2005 newsgroup,
microsoft.private.sqlserver2005.relationalserver.clr: SQL Server only allows referencing a list of supported framework assemblies like system.dll, system.data.dll etc. (complete information in SQL Server Books Online). These are the assemblies you can add reference to by default in your Visual Studio SQL Server projects. You would see them in SQL Server tab when you click add reference. Apart from these, all other assemblies that you wish to reference in your VS SQL Server project must be registered in the database you have specified for your project. You can do this using the CREATE ASSEMBLY statement from SQL Server Management Studio. Once you register an assembly in the database, it would show up in the SQL Server tab in add references. Thanks, -Vineet Rao. Microsoft SQL Server [quoted text, click to view] "Andy" <andyjax@newsgroup.nospam> wrote in message news:OXnhrinnFHA.3256@tk2msftngp13.phx.gbl... > Yes I am familar with how web services work, but just to keep the web > servers clean the idea was to have the .Net 1.1 apps call to the SQL box > for the API's that were wrapped as a web service. Since I have not been > able to get SQL to register and assembly that I can expose as a UDF, which > then could be exposed as an endpoint, we for now are resorting to > installing IIS that will be the webservice. I really don't want to have to > register the assembly in the GAC, but that seems like another way to get > things done. > > We are trying to get our prototype up and going before the .Net 2.0 is > release as gold code. We have a limited number of develop boxes, so we > don't want to install beta software everywhere that may cause a complete > rebuild when gold code is available. Once the gold code is available, then > the web servers will have the NS API installed and they will make the > calls that way. Our system will be physically separated, so the idea was > to just have a WS on the NS box which is remote. Otherwise the API is > making a remote call over firewalls etc, so we would probably be better > served to use WS. > > This is all more than you really were looking for, but just thought I > would lay it on the line. I guess we should pose some of this discussion > to our TAP channels. > > > > "kate" <k@alert-tech.co.uk> wrote in message > news:1123759816.702528.301810@g47g2000cwa.googlegroups.com... >> >From our experience and what Shyam is saying you certainly dont need >> IIS on the SQL box. If you create a webservice round the API elements >> that you want and install that on your webserver, you can then call >> than from the SQL 2005 assembly via a SOAP call without any need for >> the NS or IIS elements to be present on the SQL box. This is how the >> Reporting Services SOAP interface works and is very effective. >> >> We have implented a similar strategy for SQL2000 and that works very >> well with no need for the SQL box to have even heard of NS. >> >> Kate MBCS >> >> Alert Technologies >> http://www.alert-technologies.co.uk >> Get your notification services implementation going in minutes not >> weeks ...... >> > >
the create assembly thing in sqlserver 2005 requires that the assy and
all its deps, be loaded into the internal sql binaries library. i dont know if you can externally reference the gac for this. the bigger this list gets the more modules have to be reloaded when changes occur and new versions are issued. my feeling is that the code that runs inside sql should be lean and mean. it might be better to create a tiny stub sql clr assembly which drops the request to a queue which is processed in an external service outside sql. that way all the deps can be shared from the gac. i am still getting up to speed with 2005 so there may be plenty of things that i havent considered here. Kate MBCS Alert Technologies http://www.alert-technologies.co.uk Get your notification services implementation going in minutes not weeks ......
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
| home · blog · groups | Questions? Comments? Contact the dn |