| Groups | Blog | Home |
dotnet web services enhancements : Recommendations for Web Service Discovery?
WCF. These services are intended to be deployed within the Intranet of a very, very large orginization. I need to have a discovery process by which applications can discover these services. What I really would like to avoid is static URL's scattered throughout configuration files, and I'm willing to write a fair bit of code to achieve this goal. I had anticipated using UDDI, but the UDDI Story with WCF (and WSE 3.0) seems to be... lacking. There is an old UDDI SDK (circa 2002) that Microsoft put together and hasn't been brought forward to .Net 2.0, or .Net 3.0. WCF (and WSE 3.0) includes no native support for UDDI or Service Discovery that I can find. There is a nice new UDDI 3.0 spec that has been approved by OASIS, but the deafining silence surrounding support for this standard seems to indicate it's not exactly seeing industry wide support. The UDDI sample that comes with WCF has no documentation associated with it, and the auto-generated UDDI classes appear to be 2.0, rather than 3.0. The WCF documention has but a single entry for UDDI, and that's a simple definition of the acronym. What's the recommended practice these days for Service Discovery? I have pretty much carte blanche to implement the soution, but I just don't know what to recommend. Should we be extending Active Directory schema and making LDAP queries for service locations? Abusing DNS SRV records? Using the old UDDI 2.0 infrastructure and hoping it continues to work? Storing URL's in a database? -- Chris Mullins MCSD.Net, MCPD Enterprise http://www.coversant.net/blogs/cmullins
I can add that it ( UDDI sample ) don't work at all on my XP even with
W2003K Admin pack on it, but due to MSFT that's the way , the other one is SSDP but that's not what you want IMHO Arkady [quoted text, click to view] "Chris Mullins" <cmullins@yahoo.com> wrote in message news:OQ4QDhv8GHA.2316@TK2MSFTNGP04.phx.gbl... > I'm in the process of building a number of (Web) Services using .NET 3.0 > and WCF. These services are intended to be deployed within the Intranet of > a very, very large orginization. > > I need to have a discovery process by which applications can discover > these services. What I really would like to avoid is static URL's > scattered throughout configuration files, and I'm willing to write a fair > bit of code to achieve this goal. > > I had anticipated using UDDI, but the UDDI Story with WCF (and WSE 3.0) > seems to be... lacking. There is an old UDDI SDK (circa 2002) that > Microsoft put together and hasn't been brought forward to .Net 2.0, or > .Net 3.0. WCF (and WSE 3.0) includes no native support for UDDI or Service > Discovery that I can find. > > There is a nice new UDDI 3.0 spec that has been approved by OASIS, but the > deafining silence surrounding support for this standard seems to indicate > it's not exactly seeing industry wide support. > > The UDDI sample that comes with WCF has no documentation associated with > it, and the auto-generated UDDI classes appear to be 2.0, rather than 3.0. > The WCF documention has but a single entry for UDDI, and that's a simple > definition of the acronym. > > What's the recommended practice these days for Service Discovery? I have > pretty much carte blanche to implement the soution, but I just don't know > what to recommend. Should we be extending Active Directory schema and > making LDAP queries for service locations? Abusing DNS SRV records? Using > the old UDDI 2.0 infrastructure and hoping it continues to work? Storing > URL's in a database? > > -- > Chris Mullins MCSD.Net, MCPD Enterprise > http://www.coversant.net/blogs/cmullins > >
Hi,
I too have a similar problem.. I have a 3rd party web service running in a Web Server within our network. The web service sends "Hello" message when joins the network and also sends "Bye" message when leaves the network. I want to write a client code to receive the "Hello" message as well as the "Bye" message sent by the web service. Can you please suggest me a sample code, so that I can discover (dynamically discover) the web service using the multicast discovery protocol (using WS-Discovery). Development Environment : VS 2005, .NET 2.0 and WSE 3.0 Thanks in Advance John [MCSD] [quoted text, click to view] "Chris Mullins" wrote:
> I'm in the process of building a number of (Web) Services using .NET 3.0 and > WCF. These services are intended to be deployed within the Intranet of a > very, very large orginization. > > I need to have a discovery process by which applications can discover these > services. What I really would like to avoid is static URL's scattered > throughout configuration files, and I'm willing to write a fair bit of code > to achieve this goal. > > I had anticipated using UDDI, but the UDDI Story with WCF (and WSE 3.0) > seems to be... lacking. There is an old UDDI SDK (circa 2002) that Microsoft > put together and hasn't been brought forward to .Net 2.0, or .Net 3.0. WCF > (and WSE 3.0) includes no native support for UDDI or Service Discovery that > I can find. > > There is a nice new UDDI 3.0 spec that has been approved by OASIS, but the > deafining silence surrounding support for this standard seems to indicate > it's not exactly seeing industry wide support. > > The UDDI sample that comes with WCF has no documentation associated with it, > and the auto-generated UDDI classes appear to be 2.0, rather than 3.0. The > WCF documention has but a single entry for UDDI, and that's a simple > definition of the acronym. > > What's the recommended practice these days for Service Discovery? I have > pretty much carte blanche to implement the soution, but I just don't know > what to recommend. Should we be extending Active Directory schema and making > LDAP queries for service locations? Abusing DNS SRV records? Using the old > UDDI 2.0 infrastructure and hoping it continues to work? Storing URL's in a > database? > > -- > Chris Mullins MCSD.Net, MCPD Enterprise > http://www.coversant.net/blogs/cmullins > >
The problem you're describing isn't really a discovery problem, but more of
a Presence problem. Even if UDDI worked well and was seamlessly integrated into the .Net 3.0 stack, the scenario you're describing isn't really what it's designed to solve. A better architectural solution may be to expose your service using a Presence based protocol such as XMPP (Extensible Message and Presence Protocol) . This way when the service comes online, it announces presence and the XMPP Server will route messages to the service. When the service goes offline, the XMPP server would mark the service as offline and stop sending messages to it. I have to admit, I'm a bit partial to solving the Presence problem using XMPP - I'm the lead architect on the SoapBox Server, which is (in my opinion) the best XMPP server on the market. -- Chris Mullins, MCSD.NET, MCPD:Enterprise http://www.coversant.net/blogs/cmullins [quoted text, click to view] "John Paul. A" <JohnPaulA@discussions.microsoft.com> wrote in message news:F31F5E93-210F-49AF-9219-EB31C774A5EF@microsoft.com... > Hi, > I too have a similar problem.. > I have a 3rd party web service running in a Web Server within our network. > The web service sends "Hello" message when joins the network and also > sends > "Bye" message when leaves the network. > I want to write a client code to receive the "Hello" message as well as > the > "Bye" message sent by the web service. > Can you please suggest me a sample code, so that I can discover > (dynamically > discover) the web service using the multicast discovery protocol (using > WS-Discovery). > > Development Environment : VS 2005, .NET 2.0 and WSE 3.0 > > Thanks in Advance > > John > [MCSD] > > > "Chris Mullins" wrote: > >> I'm in the process of building a number of (Web) Services using .NET 3.0 >> and >> WCF. These services are intended to be deployed within the Intranet of a >> very, very large orginization. >> >> I need to have a discovery process by which applications can discover >> these >> services. What I really would like to avoid is static URL's scattered >> throughout configuration files, and I'm willing to write a fair bit of >> code >> to achieve this goal. >> >> I had anticipated using UDDI, but the UDDI Story with WCF (and WSE 3.0) >> seems to be... lacking. There is an old UDDI SDK (circa 2002) that >> Microsoft >> put together and hasn't been brought forward to .Net 2.0, or .Net 3.0. >> WCF >> (and WSE 3.0) includes no native support for UDDI or Service Discovery >> that >> I can find. >> >> There is a nice new UDDI 3.0 spec that has been approved by OASIS, but >> the >> deafining silence surrounding support for this standard seems to indicate >> it's not exactly seeing industry wide support. >> >> The UDDI sample that comes with WCF has no documentation associated with >> it, >> and the auto-generated UDDI classes appear to be 2.0, rather than 3.0. >> The >> WCF documention has but a single entry for UDDI, and that's a simple >> definition of the acronym. >> >> What's the recommended practice these days for Service Discovery? I have >> pretty much carte blanche to implement the soution, but I just don't know >> what to recommend. Should we be extending Active Directory schema and >> making >> LDAP queries for service locations? Abusing DNS SRV records? Using the >> old >> UDDI 2.0 infrastructure and hoping it continues to work? Storing URL's in >> a >> database? >> >> -- >> Chris Mullins MCSD.Net, MCPD Enterprise >> http://www.coversant.net/blogs/cmullins >> >> >>
A service would annouce it's presence on a presence network much in the same
way a person would. Think of you using MSN - when you log in, all of your friends suddenly know you're online. In effect, you just announced presence. The IETF has approved protocol for Messaging and Presence is XMPP - This is, in essence, a presence-aware XML routing protocol. For most applications, people use this for Instant Messaging and call it Jabber. There are a huge number of other applications for this protocol, and many of them invovle b2b and machine-to-machine use cases. Using this approach, your service would announce it's presence to the XMPP network, and other services or applications on the network can then know it's online and start consuming the services. There is also a very rich metadata excahnge infrastructure, security, and all sorts of other goodies. -- Chris Mullins, MCSD.NET, MCPD:Enterprise http://www.coversant.net/blogs/cmullins [quoted text, click to view] "Arkady Frenkel" <arkadyf@hotmailxdotx.com> wrote in message > Hi, Chris! > Just a question : what do you mean ( and how ) "it ( service ) announces > presence". > If you mean multicast, that SSDP of UPnP with all pros/cons of UDP. If you > mean send notification to known service ( server ) , in such case service > have to have client in addition for that ( if you mean WCF services ) , > which mean that WCF tenets 1 ( Boundaries are Explicit ) and 2 ( > Autonomous Evolution > ) are violated. > BTW that what I did for our system but I'm not calm with such decision... > > TIA > Arkady > > > "Chris Mullins" <cmullins@yahoo.com> wrote in message > news:ucm3iOj9GHA.4552@TK2MSFTNGP05.phx.gbl... >> The problem you're describing isn't really a discovery problem, but more >> of a Presence problem. >> >> Even if UDDI worked well and was seamlessly integrated into the .Net 3.0 >> stack, the scenario you're describing isn't really what it's designed to >> solve. >> >> A better architectural solution may be to expose your service using a >> Presence based protocol such as XMPP (Extensible Message and Presence >> Protocol) . This way when the service comes online, it announces presence >> and the XMPP Server will route messages to the service. When the service >> goes offline, the XMPP server would mark the service as offline and stop >> sending messages to it. >> >> I have to admit, I'm a bit partial to solving the Presence problem using >> XMPP - I'm the lead architect on the SoapBox Server, which is (in my >> opinion) the best XMPP server on the market. >> >> -- >> Chris Mullins, MCSD.NET, MCPD:Enterprise >> http://www.coversant.net/blogs/cmullins >> >> >> "John Paul. A" <JohnPaulA@discussions.microsoft.com> wrote in message >> news:F31F5E93-210F-49AF-9219-EB31C774A5EF@microsoft.com... >>> Hi, >>> I too have a similar problem.. >>> I have a 3rd party web service running in a Web Server within our >>> network. >>> The web service sends "Hello" message when joins the network and also >>> sends >>> "Bye" message when leaves the network. >>> I want to write a client code to receive the "Hello" message as well as >>> the >>> "Bye" message sent by the web service. >>> Can you please suggest me a sample code, so that I can discover >>> (dynamically >>> discover) the web service using the multicast discovery protocol (using >>> WS-Discovery). >>> >>> Development Environment : VS 2005, .NET 2.0 and WSE 3.0 >>> >>> Thanks in Advance >>> >>> John >>> [MCSD] >>> >>> >>> "Chris Mullins" wrote: >>> >>>> I'm in the process of building a number of (Web) Services using .NET >>>> 3.0 and >>>> WCF. These services are intended to be deployed within the Intranet of >>>> a >>>> very, very large orginization. >>>> >>>> I need to have a discovery process by which applications can discover >>>> these >>>> services. What I really would like to avoid is static URL's scattered >>>> throughout configuration files, and I'm willing to write a fair bit of >>>> code >>>> to achieve this goal. >>>> >>>> I had anticipated using UDDI, but the UDDI Story with WCF (and WSE 3.0) >>>> seems to be... lacking. There is an old UDDI SDK (circa 2002) that >>>> Microsoft >>>> put together and hasn't been brought forward to .Net 2.0, or .Net 3.0. >>>> WCF >>>> (and WSE 3.0) includes no native support for UDDI or Service Discovery >>>> that >>>> I can find. >>>> >>>> There is a nice new UDDI 3.0 spec that has been approved by OASIS, but >>>> the >>>> deafining silence surrounding support for this standard seems to >>>> indicate >>>> it's not exactly seeing industry wide support. >>>> >>>> The UDDI sample that comes with WCF has no documentation associated >>>> with it, >>>> and the auto-generated UDDI classes appear to be 2.0, rather than 3.0. >>>> The >>>> WCF documention has but a single entry for UDDI, and that's a simple >>>> definition of the acronym. >>>> >>>> What's the recommended practice these days for Service Discovery? I >>>> have >>>> pretty much carte blanche to implement the soution, but I just don't >>>> know >>>> what to recommend. Should we be extending Active Directory schema and >>>> making >>>> LDAP queries for service locations? Abusing DNS SRV records? Using the >>>> old >>>> UDDI 2.0 infrastructure and hoping it continues to work? Storing URL's >>>> in a >>>> database? >>>> >>>> -- >>>> Chris Mullins MCSD.Net, MCPD Enterprise >>>> http://www.coversant.net/blogs/cmullins >>>> >>>> >>>> >> >> > >
Hi, Chris!
Just a question : what do you mean ( and how ) "it ( service ) announces presence". If you mean multicast, that SSDP of UPnP with all pros/cons of UDP. If you mean send notification to known service ( server ) , in such case service have to have client in addition for that ( if you mean WCF services ) , which mean that WCF tenets 1 ( Boundaries are Explicit ) and 2 ( Autonomous Evolution ) are violated. BTW that what I did for our system but I'm not calm with such decision... TIA Arkady [quoted text, click to view] "Chris Mullins" <cmullins@yahoo.com> wrote in message news:ucm3iOj9GHA.4552@TK2MSFTNGP05.phx.gbl... > The problem you're describing isn't really a discovery problem, but more > of a Presence problem. > > Even if UDDI worked well and was seamlessly integrated into the .Net 3.0 > stack, the scenario you're describing isn't really what it's designed to > solve. > > A better architectural solution may be to expose your service using a > Presence based protocol such as XMPP (Extensible Message and Presence > Protocol) . This way when the service comes online, it announces presence > and the XMPP Server will route messages to the service. When the service > goes offline, the XMPP server would mark the service as offline and stop > sending messages to it. > > I have to admit, I'm a bit partial to solving the Presence problem using > XMPP - I'm the lead architect on the SoapBox Server, which is (in my > opinion) the best XMPP server on the market. > > -- > Chris Mullins, MCSD.NET, MCPD:Enterprise > http://www.coversant.net/blogs/cmullins > > > "John Paul. A" <JohnPaulA@discussions.microsoft.com> wrote in message > news:F31F5E93-210F-49AF-9219-EB31C774A5EF@microsoft.com... >> Hi, >> I too have a similar problem.. >> I have a 3rd party web service running in a Web Server within our >> network. >> The web service sends "Hello" message when joins the network and also >> sends >> "Bye" message when leaves the network. >> I want to write a client code to receive the "Hello" message as well as >> the >> "Bye" message sent by the web service. >> Can you please suggest me a sample code, so that I can discover >> (dynamically >> discover) the web service using the multicast discovery protocol (using >> WS-Discovery). >> >> Development Environment : VS 2005, .NET 2.0 and WSE 3.0 >> >> Thanks in Advance >> >> John >> [MCSD] >> >> >> "Chris Mullins" wrote: >> >>> I'm in the process of building a number of (Web) Services using .NET 3.0 >>> and >>> WCF. These services are intended to be deployed within the Intranet of a >>> very, very large orginization. >>> >>> I need to have a discovery process by which applications can discover >>> these >>> services. What I really would like to avoid is static URL's scattered >>> throughout configuration files, and I'm willing to write a fair bit of >>> code >>> to achieve this goal. >>> >>> I had anticipated using UDDI, but the UDDI Story with WCF (and WSE 3.0) >>> seems to be... lacking. There is an old UDDI SDK (circa 2002) that >>> Microsoft >>> put together and hasn't been brought forward to .Net 2.0, or .Net 3.0. >>> WCF >>> (and WSE 3.0) includes no native support for UDDI or Service Discovery >>> that >>> I can find. >>> >>> There is a nice new UDDI 3.0 spec that has been approved by OASIS, but >>> the >>> deafining silence surrounding support for this standard seems to >>> indicate >>> it's not exactly seeing industry wide support. >>> >>> The UDDI sample that comes with WCF has no documentation associated with >>> it, >>> and the auto-generated UDDI classes appear to be 2.0, rather than 3.0. >>> The >>> WCF documention has but a single entry for UDDI, and that's a simple >>> definition of the acronym. >>> >>> What's the recommended practice these days for Service Discovery? I have >>> pretty much carte blanche to implement the soution, but I just don't >>> know >>> what to recommend. Should we be extending Active Directory schema and >>> making >>> LDAP queries for service locations? Abusing DNS SRV records? Using the >>> old >>> UDDI 2.0 infrastructure and hoping it continues to work? Storing URL's >>> in a >>> database? >>> >>> -- >>> Chris Mullins MCSD.Net, MCPD Enterprise >>> http://www.coversant.net/blogs/cmullins >>> >>> >>> > >
MSN messenger is P2P model with central server as broker between peers (
which have both client and server as being P2P ) so may need broker after connection only for hole punching.I n that case there is no problem of WCF/web service being service only and separating client and service with strict boundary. Arkady [quoted text, click to view] "Chris Mullins" <cmullins@yahoo.com> wrote in message news:eg45uLs9GHA.1188@TK2MSFTNGP05.phx.gbl... >A service would annouce it's presence on a presence network much in the >same way a person would. > > Think of you using MSN - when you log in, all of your friends suddenly > know you're online. In effect, you just announced presence. > > The IETF has approved protocol for Messaging and Presence is XMPP - This > is, in essence, a presence-aware XML routing protocol. For most > applications, people use this for Instant Messaging and call it Jabber. > > There are a huge number of other applications for this protocol, and many > of them invovle b2b and machine-to-machine use cases. Using this approach, > your service would announce it's presence to the XMPP network, and other > services or applications on the network can then know it's online and > start consuming the services. There is also a very rich metadata excahnge > infrastructure, security, and all sorts of other goodies. > > -- > Chris Mullins, MCSD.NET, MCPD:Enterprise > http://www.coversant.net/blogs/cmullins > > > "Arkady Frenkel" <arkadyf@hotmailxdotx.com> wrote in message >> Hi, Chris! >> Just a question : what do you mean ( and how ) "it ( service ) announces >> presence". >> If you mean multicast, that SSDP of UPnP with all pros/cons of UDP. If >> you mean send notification to known service ( server ) , in such case >> service have to have client in addition for that ( if you mean WCF >> services ) , which mean that WCF tenets 1 ( Boundaries are Explicit ) >> and 2 ( Autonomous Evolution >> ) are violated. >> BTW that what I did for our system but I'm not calm with such decision... >> >> TIA >> Arkady >> >> >> "Chris Mullins" <cmullins@yahoo.com> wrote in message >> news:ucm3iOj9GHA.4552@TK2MSFTNGP05.phx.gbl... >>> The problem you're describing isn't really a discovery problem, but more >>> of a Presence problem. >>> >>> Even if UDDI worked well and was seamlessly integrated into the .Net 3.0 >>> stack, the scenario you're describing isn't really what it's designed to >>> solve. >>> >>> A better architectural solution may be to expose your service using a >>> Presence based protocol such as XMPP (Extensible Message and Presence >>> Protocol) . This way when the service comes online, it announces >>> presence and the XMPP Server will route messages to the service. When >>> the service goes offline, the XMPP server would mark the service as >>> offline and stop sending messages to it. >>> >>> I have to admit, I'm a bit partial to solving the Presence problem using >>> XMPP - I'm the lead architect on the SoapBox Server, which is (in my >>> opinion) the best XMPP server on the market. >>> >>> -- >>> Chris Mullins, MCSD.NET, MCPD:Enterprise >>> http://www.coversant.net/blogs/cmullins >>> >>> >>> "John Paul. A" <JohnPaulA@discussions.microsoft.com> wrote in message >>> news:F31F5E93-210F-49AF-9219-EB31C774A5EF@microsoft.com... >>>> Hi, >>>> I too have a similar problem.. >>>> I have a 3rd party web service running in a Web Server within our >>>> network. >>>> The web service sends "Hello" message when joins the network and also >>>> sends >>>> "Bye" message when leaves the network. >>>> I want to write a client code to receive the "Hello" message as well as >>>> the >>>> "Bye" message sent by the web service. >>>> Can you please suggest me a sample code, so that I can discover >>>> (dynamically >>>> discover) the web service using the multicast discovery protocol (using >>>> WS-Discovery). >>>> >>>> Development Environment : VS 2005, .NET 2.0 and WSE 3.0 >>>> >>>> Thanks in Advance >>>> >>>> John >>>> [MCSD] >>>> >>>> >>>> "Chris Mullins" wrote: >>>> >>>>> I'm in the process of building a number of (Web) Services using .NET >>>>> 3.0 and >>>>> WCF. These services are intended to be deployed within the Intranet of >>>>> a >>>>> very, very large orginization. >>>>> >>>>> I need to have a discovery process by which applications can discover >>>>> these >>>>> services. What I really would like to avoid is static URL's scattered >>>>> throughout configuration files, and I'm willing to write a fair bit of >>>>> code >>>>> to achieve this goal. >>>>> >>>>> I had anticipated using UDDI, but the UDDI Story with WCF (and WSE >>>>> 3.0) >>>>> seems to be... lacking. There is an old UDDI SDK (circa 2002) that >>>>> Microsoft >>>>> put together and hasn't been brought forward to .Net 2.0, or .Net 3.0. >>>>> WCF >>>>> (and WSE 3.0) includes no native support for UDDI or Service Discovery >>>>> that >>>>> I can find. >>>>> >>>>> There is a nice new UDDI 3.0 spec that has been approved by OASIS, but >>>>> the >>>>> deafining silence surrounding support for this standard seems to >>>>> indicate >>>>> it's not exactly seeing industry wide support. >>>>> >>>>> The UDDI sample that comes with WCF has no documentation associated >>>>> with it, >>>>> and the auto-generated UDDI classes appear to be 2.0, rather than 3.0. >>>>> The >>>>> WCF documention has but a single entry for UDDI, and that's a simple >>>>> definition of the acronym. >>>>> >>>>> What's the recommended practice these days for Service Discovery? I >>>>> have >>>>> pretty much carte blanche to implement the soution, but I just don't >>>>> know >>>>> what to recommend. Should we be extending Active Directory schema and >>>>> making >>>>> LDAP queries for service locations? Abusing DNS SRV records? Using the >>>>> old >>>>> UDDI 2.0 infrastructure and hoping it continues to work? Storing URL's >>>>> in a >>>>> database? >>>>> >>>>> -- >>>>> Chris Mullins MCSD.Net, MCPD Enterprise >>>>> http://www.coversant.net/blogs/cmullins >>>>> >>>>> >>>>> >>> >>> >> >> > >
You could try using WS-Discovery. It supports both active (probing for
services) and passive (waiting for services to announce presence) discovery. Vista has an implementation using the WSDAPI. You can also use Function Discovery to discover and publish services (via Publication Services). -- Dave Roth [MS] Program Manager Web Services on Devices ================ This posting is provided "AS IS" with no warranties, and confers no rights. The use of any included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm [quoted text, click to view] "Chris Mullins" <cmullins@yahoo.com> wrote in message
news:ucm3iOj9GHA.4552@TK2MSFTNGP05.phx.gbl... > The problem you're describing isn't really a discovery problem, but more > of a Presence problem. > > Even if UDDI worked well and was seamlessly integrated into the .Net 3.0 > stack, the scenario you're describing isn't really what it's designed to > solve. > > A better architectural solution may be to expose your service using a > Presence based protocol such as XMPP (Extensible Message and Presence > Protocol) . This way when the service comes online, it announces presence > and the XMPP Server will route messages to the service. When the service > goes offline, the XMPP server would mark the service as offline and stop > sending messages to it. > > I have to admit, I'm a bit partial to solving the Presence problem using > XMPP - I'm the lead architect on the SoapBox Server, which is (in my > opinion) the best XMPP server on the market. > > -- > Chris Mullins, MCSD.NET, MCPD:Enterprise > http://www.coversant.net/blogs/cmullins > > > "John Paul. A" <JohnPaulA@discussions.microsoft.com> wrote in message > news:F31F5E93-210F-49AF-9219-EB31C774A5EF@microsoft.com... >> Hi, >> I too have a similar problem.. >> I have a 3rd party web service running in a Web Server within our >> network. >> The web service sends "Hello" message when joins the network and also >> sends >> "Bye" message when leaves the network. >> I want to write a client code to receive the "Hello" message as well as >> the >> "Bye" message sent by the web service. >> Can you please suggest me a sample code, so that I can discover >> (dynamically >> discover) the web service using the multicast discovery protocol (using >> WS-Discovery). >> >> Development Environment : VS 2005, .NET 2.0 and WSE 3.0 >> >> Thanks in Advance >> >> John >> [MCSD] >> >> >> "Chris Mullins" wrote: >> >>> I'm in the process of building a number of (Web) Services using .NET 3.0 >>> and >>> WCF. These services are intended to be deployed within the Intranet of a >>> very, very large orginization. >>> >>> I need to have a discovery process by which applications can discover >>> these >>> services. What I really would like to avoid is static URL's scattered >>> throughout configuration files, and I'm willing to write a fair bit of >>> code >>> to achieve this goal. >>> >>> I had anticipated using UDDI, but the UDDI Story with WCF (and WSE 3.0) >>> seems to be... lacking. There is an old UDDI SDK (circa 2002) that >>> Microsoft >>> put together and hasn't been brought forward to .Net 2.0, or .Net 3.0. >>> WCF >>> (and WSE 3.0) includes no native support for UDDI or Service Discovery >>> that >>> I can find. >>> >>> There is a nice new UDDI 3.0 spec that has been approved by OASIS, but >>> the >>> deafining silence surrounding support for this standard seems to >>> indicate >>> it's not exactly seeing industry wide support. >>> >>> The UDDI sample that comes with WCF has no documentation associated with >>> it, >>> and the auto-generated UDDI classes appear to be 2.0, rather than 3.0. >>> The >>> WCF documention has but a single entry for UDDI, and that's a simple >>> definition of the acronym. >>> >>> What's the recommended practice these days for Service Discovery? I have >>> pretty much carte blanche to implement the soution, but I just don't >>> know >>> what to recommend. Should we be extending Active Directory schema and >>> making >>> LDAP queries for service locations? Abusing DNS SRV records? Using the >>> old >>> UDDI 2.0 infrastructure and hoping it continues to work? Storing URL's >>> in a >>> database? >>> >>> -- >>> Chris Mullins MCSD.Net, MCPD Enterprise >>> http://www.coversant.net/blogs/cmullins >>> >>> >>> > >
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
November 2007
December 2007
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |