By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,705 Members | 2,013 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,705 IT Pros & Developers. It's quick & easy.

Recommendations for Web Service Discovery?

P: n/a
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
Oct 18 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
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" <cm******@yahoo.comwrote in message
news:OQ**************@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


Oct 19 '06 #2

P: n/a
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
Oct 22 '06 #3

P: n/a
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" <Jo*******@discussions.microsoft.comwrote in message
news:F3**********************************@microsof t.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

Oct 22 '06 #4

P: n/a
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" <cm******@yahoo.comwrote in message
news:uc**************@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" <Jo*******@discussions.microsoft.comwrote in message
news:F3**********************************@microsof t.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


Oct 23 '06 #5

P: n/a
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" <ar*****@hotmailxdotx.comwrote 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" <cm******@yahoo.comwrote in message
news:uc**************@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" <Jo*******@discussions.microsoft.comwrote in message
news:F3**********************************@microso ft.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



Oct 23 '06 #6

P: n/a
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" <cm******@yahoo.comwrote in message
news:eg**************@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" <ar*****@hotmailxdotx.comwrote 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" <cm******@yahoo.comwrote in message
news:uc**************@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" <Jo*******@discussions.microsoft.comwrote in message
news:F3**********************************@micros oft.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
>
>
>




Oct 24 '06 #7

P: n/a
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" <cm******@yahoo.comwrote in message
news:uc**************@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" <Jo*******@discussions.microsoft.comwrote in message
news:F3**********************************@microsof t.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

Dec 7 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.