Recommendations for Web Service Discovery?

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

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




"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]


"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


"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


"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
>>>
>>>
>>>
>
>

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

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

"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


"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
>>>
>>>
>>>
>
>