Some questions on what technology to use

[Lee Alexander]

I am new to Web Services and am trying to get over that feeling of being
slightly lost in a foreign place so to speak. I have a few questions:

What technology should I be looking at with regards to implementing a web
service under dot net? I know this is a pretty open ended question but what
I'm looking for is a technology that will see me in good stead for the
future whilst being rooted in the *near* future to present. I have had a
look at Web Services using remoting and also WSE 2. I'm not currently
looking at ASMX as one of my restrictions is that the web service should
potentially be independent from a web server like IIS. I get the impression
from postings that remoting is probably the wrong way to go as I might have
upgrade problems when Indigo comes out; yet it seems the simplest in terms
of attaching messages to methods and automatically generating WSDL etc..
Thoughts on this?

I have had a look at WSE 2.0 and it seems more difficult to generate a WSDL
file (if not impossible) since there isn't such a tight mapping between the
message handler and the message structure. Lets say I have a message called
Add that takes two parameters and returns the result. From what I have read
for WSE I would derive from SoapReciever and override the Receive message
manually drilling into the envelopes body using XPath when the message
arrived. Another alternative would be to use SoapService which gives me a
little extra help by routing the message to a declared method; but the
declared method would still be of the form:

SoapEnvelope MyMessageHandler( SoapEnvelope message )
{
// process message
}

So I would still have to get down and dirty with some XML.

So my question here is if I use either of these ways to handle the message
presumably there would be no way of *automatically* generating the WSDL; so
I would have to create the WSDL manually, is that correct or am I missing
something obvious here? If this is the case will there be (in the future) a
more closely coupled link between the message handler and the message format
like say:

[SoapMessage[urn:math:add]]
int Add( int x, int y )
{
return x + y;
}

This would remove the hassle of having to drill into the XML to get my
parameters etc.

My next stop will be looking at Indigo so how does this fit with where I'm
trying to go?

Any help/thoughts would be much appreciated...

Regards
Lee

 

[Softwaremaker]

Hi, please see comments below.

--
Thank you very much

Warmest Regards,
William T (Willie) - Softwaremaker
Architect | Evangelist | Consultant

Microsoft Regional Director
http://www.microsoft.com/rd

+++++++++++++++++++++++++++++++++

I am new to Web Services and am trying to get over that feeling of being
slightly lost in a foreign place so to speak. I have a few questions:

What technology should I be looking at with regards to implementing a web
service under dot net?

<Quote>If you implement a WS under .Net, you are using .Net as the
implementing technology </Quote>

I know this is a pretty open ended question but what

I'm looking for is a technology that will see me in good stead for the
future whilst being rooted in the *near* future to present. I have had a
look at Web Services using remoting and also WSE 2. I'm not currently
looking at ASMX as one of my restrictions is that the web service should
potentially be independent from a web server like IIS. I get the impression
from postings that remoting is probably the wrong way to go as I might have
upgrade problems when Indigo comes out; yet it seems the simplest in terms
of attaching messages to methods and automatically generating WSDL etc..
Thoughts on this?

<Quote>To fully maximize the power and speed of Remoting, its best to use
the Binary Formatter. If you choose to use the SOAP Formatter, be aware that

I have had a look at WSE 2.0 and it seems more difficult to generate a WSDL
file (if not impossible) since there isn't such a tight mapping between the
message handler and the message structure. Lets say I have a message called
Add that takes two parameters and returns the result. From what I have read
for WSE I would derive from SoapReciever and override the Receive message
manually drilling into the envelopes body using XPath when the message
arrived. Another alternative would be to use SoapService which gives me a
little extra help by routing the message to a declared method; but the
declared method would still be of the form:

SoapEnvelope MyMessageHandler( SoapEnvelope message )
{
// process message
}

So I would still have to get down and dirty with some XML.

<Quote>I am sorry I am kinda lost here. Are you looking for a tool to
automate the gerneration of the WSDL. There is no need to use WSE for this.
..NET comes with a tool called the WSDL.exe that generates the WSDL for you.
If you use VS.NET as the IDE, VS.NET will generate a WSDL wrapper aropund
the assembly you create. So there is really no need to get into the XML

So my question here is if I use either of these ways to handle the message
presumably there would be no way of *automatically* generating the WSDL; so
I would have to create the WSDL manually, is that correct or am I missing
something obvious here? If this is the case will there be (in the future) a
more closely coupled link between the message handler and the message format
like say:

[SoapMessage[urn:math:add]]
int Add( int x, int y )
{
return x + y;
}

This would remove the hassle of having to drill into the XML to get my
parameters etc.

<Quote>I am sorry I am kinda lost here. Are you looking for a tool to
automate the gerneration of the WSDL. There is no need to use WSE for this.
..NET comes with a tool called the WSDL.exe that generates the WSDL for you.
If you use VS.NET as the IDE, VS.NET will generate a WSDL wrapper aropund
the assembly you create. So there is really no need to get into the XML

 

[Lee Alexander]

automate the gerneration of the WSDL. There is no need to use WSE for this.
.NET comes with a tool called the WSDL.exe that generates the WSDL for

you.
What I mean is under WSE if I derive from SoapService or SoapReceiver and
process the messages from a handling member how will WSDL.exe or VS.NET know
that say the "add" message expects two parameters and returns the result
just by looking at MyService::MyMessageHandler below. I can't see how it
would be able to deduce this if the signature of the method is simply:

class MyService: SoapService
{
[SoapMessage[urn:math:add]]
SoapEnvelope MyMessageHandler( SoapEnvelope message )
{
// process message
}
}

I guess I must be missing something.. Also like I said in the original
message it would be nice to bind a message directly to a member method of a
class and the message parameters marshalled to the members relevent
parameter.

I've been reading the following article below as a basis for my
understanding of how you would go about creating a web service using wse 2.0

http://msdn.microsoft.com/msdnmag/issues/03/09/XMLFiles/default.aspx


Thanks for your help...


Regards
Lee

Hi, please see comments below.

--
Thank you very much

Warmest Regards,
William T (Willie) - Softwaremaker
Architect | Evangelist | Consultant

Microsoft Regional Director
http://www.microsoft.com/rd

+++++++++++++++++++++++++++++++++

I am new to Web Services and am trying to get over that feeling of being
slightly lost in a foreign place so to speak. I have a few questions:

What technology should I be looking at with regards to implementing a web
service under dot net?

<Quote>If you implement a WS under .Net, you are using .Net as the
implementing technology </Quote>

I know this is a pretty open ended question but what

I'm looking for is a technology that will see me in good stead for the
future whilst being rooted in the *near* future to present. I have had a
look at Web Services using remoting and also WSE 2. I'm not currently
looking at ASMX as one of my restrictions is that the web service should
potentially be independent from a web server like IIS. I get the impression
from postings that remoting is probably the wrong way to go as I might have
upgrade problems when Indigo comes out; yet it seems the simplest in terms
of attaching messages to methods and automatically generating WSDL etc..
Thoughts on this?

<Quote>To fully maximize the power and speed of Remoting, its best to use
the Binary Formatter. If you choose to use the SOAP Formatter, be aware that

I have had a look at WSE 2.0 and it seems more difficult to generate a WSDL
file (if not impossible) since there isn't such a tight mapping between the
message handler and the message structure. Lets say I have a message called
Add that takes two parameters and returns the result. From what I have read
for WSE I would derive from SoapReciever and override the Receive message
manually drilling into the envelopes body using XPath when the message
arrived. Another alternative would be to use SoapService which gives me a
little extra help by routing the message to a declared method; but the
declared method would still be of the form:

SoapEnvelope MyMessageHandler( SoapEnvelope message )
{
// process message
}

So I would still have to get down and dirty with some XML.

<Quote>I am sorry I am kinda lost here. Are you looking for a tool to
automate the gerneration of the WSDL. There is no need to use WSE for this.
.NET comes with a tool called the WSDL.exe that generates the WSDL for you.
If you use VS.NET as the IDE, VS.NET will generate a WSDL wrapper aropund
the assembly you create. So there is really no need to get into the XML

So my question here is if I use either of these ways to handle the message
presumably there would be no way of *automatically* generating the WSDL; so
I would have to create the WSDL manually, is that correct or am I missing
something obvious here? If this is the case will there be (in the

future)

a
more closely coupled link between the message handler and the message format
like say:

[SoapMessage[urn:math:add]]
int Add( int x, int y )
{
return x + y;
}

This would remove the hassle of having to drill into the XML to get my
parameters etc.

<Quote>I am sorry I am kinda lost here. Are you looking for a tool to
automate the gerneration of the WSDL. There is no need to use WSE for this.
.NET comes with a tool called the WSDL.exe that generates the WSDL for you.
If you use VS.NET as the IDE, VS.NET will generate a WSDL wrapper aropund
the assembly you create. So there is really no need to get into the XML

My next stop will be looking at Indigo so how does this fit with where I'm
trying to go?

Any help/thoughts would be much appreciated...

Regards
Lee

 

[Softwaremaker]

Hi,

What exactly are you using WSE for ? It seems like all you need is to
generate a WSDL around an assembly. WSE is for WS-Routing, WS-Security, DIME
and others.

..NET Assemblies are meta-data and are therefore self-describing. VS.NET can
easily create the WSDL to your web service methods.

http://www.roguewave.com/developer/tac/examples/leif/LEIFClient_dotNetService/html/7-2.html

hth

--
Thank you very much

Warmest Regards,
William T (Willie) - Softwaremaker
Architect | Evangelist | Consultant

Microsoft Regional Director
http://www.microsoft.com/rd

+++++++++++++++++++++++++++++++++

<Quote>I am sorry I am kinda lost here. Are you looking for a tool to
automate the gerneration of the WSDL. There is no need to use WSE for this.
.NET comes with a tool called the WSDL.exe that generates the WSDL for

you.
What I mean is under WSE if I derive from SoapService or SoapReceiver and
process the messages from a handling member how will WSDL.exe or VS.NET know
that say the "add" message expects two parameters and returns the result
just by looking at MyService::MyMessageHandler below. I can't see how it
would be able to deduce this if the signature of the method is simply:

class MyService: SoapService
{
[SoapMessage[urn:math:add]]
SoapEnvelope MyMessageHandler( SoapEnvelope message )
{
// process message
}
}

I guess I must be missing something.. Also like I said in the original
message it would be nice to bind a message directly to a member method of a
class and the message parameters marshalled to the members relevent
parameter.

I've been reading the following article below as a basis for my
understanding of how you would go about creating a web service using wse 2.0

http://msdn.microsoft.com/msdnmag/issues/03/09/XMLFiles/default.aspx


Thanks for your help...


Regards
Lee

Hi, please see comments below.

--
Thank you very much

Warmest Regards,
William T (Willie) - Softwaremaker
Architect | Evangelist | Consultant

Microsoft Regional Director
http://www.microsoft.com/rd

+++++++++++++++++++++++++++++++++



<Quote>If you implement a WS under .Net, you are using .Net as the
implementing technology </Quote>

I know this is a pretty open ended question but what

<Quote>To fully maximize the power and speed of Remoting, its best to use
the Binary Formatter. If you choose to use the SOAP Formatter, be aware that
between
the

me

a

little extra help by routing the message to a declared method; but the
declared method would still be of the form:

SoapEnvelope MyMessageHandler( SoapEnvelope message )
{
// process message
}

So I would still have to get down and dirty with some XML.

<Quote>I am sorry I am kinda lost here. Are you looking for a tool to
automate the gerneration of the WSDL. There is no need to use WSE for this.
.NET comes with a tool called the WSDL.exe that generates the WSDL for you.
If you use VS.NET as the IDE, VS.NET will generate a WSDL wrapper aropund
the assembly you create. So there is really no need to get into the XML

So my question here is if I use either of these ways to handle the message
presumably there would be no way of *automatically* generating the

WSDL;
so

I would have to create the WSDL manually, is that correct or am I missing
something obvious here? If this is the case will there be (in the

future)

a
more closely coupled link between the message handler and the message format
like say:

[SoapMessage[urn:math:add]]
int Add( int x, int y )
{
return x + y;
}

This would remove the hassle of having to drill into the XML to get my
parameters etc.

<Quote>I am sorry I am kinda lost here. Are you looking for a tool to
automate the gerneration of the WSDL. There is no need to use WSE for this.
.NET comes with a tool called the WSDL.exe that generates the WSDL for you.
If you use VS.NET as the IDE, VS.NET will generate a WSDL wrapper aropund
the assembly you create. So there is really no need to get into the XML

My next stop will be looking at Indigo so how does this fit with where I'm
trying to go?

Any help/thoughts would be much appreciated...

Regards
Lee

 

[Lee Alexander]

What exactly are you using WSE for ?
I want to store information in a central repository that is accessed and
updated by different client applications. The central store should work
without IIS (hence no ASMX) as some customers will not have it. WSE 2.0
andremoting seemed to be the best ways to go in this respect (possibly
Indigo) when it's released. The example (wsechat) shown in the link that I
referred to earlier didn't make use of IIS either but also lacked any WSDL
description.
http://www.roguewave.com/developer/tac/examples/leif/LEIFClient_dotNetService/html/7-2.html
This example uses asmx and IIS which I can't use.


Regards
Lee

Hi,

What exactly are you using WSE for ? It seems like all you need is to
generate a WSDL around an assembly. WSE is for WS-Routing, WS-Security, DIME
and others.

.NET Assemblies are meta-data and are therefore self-describing. VS.NET can
easily create the WSDL to your web service methods.

http://www.roguewave.com/developer/tac/examples/leif/LEIFClient_dotNetService/html/7-2.html

hth

--
Thank you very much

Warmest Regards,
William T (Willie) - Softwaremaker
Architect | Evangelist | Consultant

Microsoft Regional Director
http://www.microsoft.com/rd

+++++++++++++++++++++++++++++++++

<Quote>I am sorry I am kinda lost here. Are you looking for a tool to
automate the gerneration of the WSDL. There is no need to use WSE for this.
.NET comes with a tool called the WSDL.exe that generates the WSDL for

you.
What I mean is under WSE if I derive from SoapService or SoapReceiver and
process the messages from a handling member how will WSDL.exe or VS.NET know
that say the "add" message expects two parameters and returns the result
just by looking at MyService::MyMessageHandler below. I can't see how it
would be able to deduce this if the signature of the method is simply:

class MyService: SoapService
{
[SoapMessage[urn:math:add]]
SoapEnvelope MyMessageHandler( SoapEnvelope message )
{
// process message
}
}

I guess I must be missing something.. Also like I said in the original
message it would be nice to bind a message directly to a member method

of

a
class and the message parameters marshalled to the members relevent
parameter.

I've been reading the following article below as a basis for my
understanding of how you would go about creating a web service using wse 2.0

http://msdn.microsoft.com/msdnmag/issues/03/09/XMLFiles/default.aspx


Thanks for your help...


Regards
Lee



a
web

had

a

look at Web Services using remoting and also WSE 2. I'm not currently
looking at ASMX as one of my restrictions is that the web service should
potentially be independent from a web server like IIS. I get the
impression
from postings that remoting is probably the wrong way to go as I might
have
upgrade problems when Indigo comes out; yet it seems the simplest in terms
of attaching messages to methods and automatically generating WSDL etc..
Thoughts on this?

<Quote>To fully maximize the power and speed of Remoting, its best to use
the Binary Formatter. If you choose to use the SOAP Formatter, be

aware
that

.NET generates its own proprietary version of the WSDL.</Quote>


I have had a look at WSE 2.0 and it seems more difficult to generate a
WSDL
file (if not impossible) since there isn't such a tight mapping between
the
message handler and the message structure. Lets say I have a message
called
Add that takes two parameters and returns the result. From what I have
read
for WSE I would derive from SoapReciever and override the Receive message
manually drilling into the envelopes body using XPath when the message
arrived. Another alternative would be to use SoapService which gives

me

a
little extra help by routing the message to a declared method; but the
declared method would still be of the form:

SoapEnvelope MyMessageHandler( SoapEnvelope message )
{
// process message
}

So I would still have to get down and dirty with some XML.

<Quote>I am sorry I am kinda lost here. Are you looking for a tool to
automate the gerneration of the WSDL. There is no need to use WSE for this.
.NET comes with a tool called the WSDL.exe that generates the WSDL for you.
If you use VS.NET as the IDE, VS.NET will generate a WSDL wrapper aropund
the assembly you create. So there is really no need to get into the XML
inner plumbings of WSDL.</Quote>


So my question here is if I use either of these ways to handle the message
presumably there would be no way of *automatically* generating the WSDL;
so
I would have to create the WSDL manually, is that correct or am I missing
something obvious here? If this is the case will there be (in the future)
a
more closely coupled link between the message handler and the message
format
like say:

[SoapMessage[urn:math:add]]
int Add( int x, int y )
{
return x + y;
}

This would remove the hassle of having to drill into the XML to get my
parameters etc.

<Quote>I am sorry I am kinda lost here. Are you looking for a tool to
automate the gerneration of the WSDL. There is no need to use WSE for this.
.NET comes with a tool called the WSDL.exe that generates the WSDL for you.
If you use VS.NET as the IDE, VS.NET will generate a WSDL wrapper aropund
the assembly you create. So there is really no need to get into the XML
inner plumbings of WSDL.</Quote>


My next stop will be looking at Indigo so how does this fit with

where
I'm

trying to go?

Any help/thoughts would be much appreciated...

Regards
Lee

 

[Softwaremaker]

You can use REMOTING to build your own SOAP and WSDL and house it in a
custom container which you can implement listening services and your own
channels, sinks and ports.

However, REMOTING is very .NET proprietary and can only work between .NET
applications and the WSDL it generates is also non-standards based.

Again, I still see no reason why WSE is used at all. Are you implementing
something that is very WSE-specific ?

I am afraid I am in no position to give you any advice on Indigo.

Regards.

++++++++++++++++++++++++++++++++++

What exactly are you using WSE for ?

I want to store information in a central repository that is accessed and
updated by different client applications. The central store should work
without IIS (hence no ASMX) as some customers will not have it. WSE 2.0
andremoting seemed to be the best ways to go in this respect (possibly
Indigo) when it's released. The example (wsechat) shown in the link that I
referred to earlier didn't make use of IIS either but also lacked any WSDL
description.
http://www.roguewave.com/developer/tac/examples/leif/LEIFClient_dotNetService/html/7-2.html
This example uses asmx and IIS which I can't use.


Regards
Lee

Hi,

What exactly are you using WSE for ? It seems like all you need is to
generate a WSDL around an assembly. WSE is for WS-Routing, WS-Security, DIME
and others.

.NET Assemblies are meta-data and are therefore self-describing. VS.NET can
easily create the WSDL to your web service methods.

http://www.roguewave.com/developer/tac/examples/leif/LEIFClient_dotNetService/html/7-2.html

hth

--
Thank you very much

Warmest Regards,
William T (Willie) - Softwaremaker
Architect | Evangelist | Consultant

Microsoft Regional Director
http://www.microsoft.com/rd

+++++++++++++++++++++++++++++++++

<Quote>I am sorry I am kinda lost here. Are you looking for a tool to
automate the gerneration of the WSDL. There is no need to use WSE for
this.
.NET comes with a tool called the WSDL.exe that generates the WSDL for
you.
What I mean is under WSE if I derive from SoapService or SoapReceiver and
process the messages from a handling member how will WSDL.exe or

VS.NET
know

that say the "add" message expects two parameters and returns the result
just by looking at MyService::MyMessageHandler below. I can't see how it
would be able to deduce this if the signature of the method is simply:

class MyService: SoapService
{
[SoapMessage[urn:math:add]]
SoapEnvelope MyMessageHandler( SoapEnvelope message )
{
// process message
}
}

I guess I must be missing something.. Also like I said in the original
message it would be nice to bind a message directly to a member method

of

a
class and the message parameters marshalled to the members relevent
parameter.

I've been reading the following article below as a basis for my
understanding of how you would go about creating a web service using

wse
2.0

http://msdn.microsoft.com/msdnmag/issues/03/09/XMLFiles/default.aspx


Thanks for your help...


Regards
Lee



Hi, please see comments below.

--
Thank you very much

Warmest Regards,
William T (Willie) - Softwaremaker
Architect | Evangelist | Consultant

Microsoft Regional Director
http://www.microsoft.com/rd

+++++++++++++++++++++++++++++++++

I am new to Web Services and am trying to get over that feeling of being
slightly lost in a foreign place so to speak. I have a few questions:

What technology should I be looking at with regards to

implementing

a had to
use

generate

a

WSDL
file (if not impossible) since there isn't such a tight mapping between
the
message handler and the message structure. Lets say I have a message
called
Add that takes two parameters and returns the result. From what I have
read
for WSE I would derive from SoapReciever and override the Receive
message
manually drilling into the envelopes body using XPath when the message
arrived. Another alternative would be to use SoapService which

gives
me

a
little extra help by routing the message to a declared method; but the
declared method would still be of the form:

SoapEnvelope MyMessageHandler( SoapEnvelope message )
{
// process message
}

So I would still have to get down and dirty with some XML.

<Quote>I am sorry I am kinda lost here. Are you looking for a tool to
automate the gerneration of the WSDL. There is no need to use WSE for
this.
.NET comes with a tool called the WSDL.exe that generates the WSDL for
you.
If you use VS.NET as the IDE, VS.NET will generate a WSDL wrapper aropund
the assembly you create. So there is really no need to get into the XML
inner plumbings of WSDL.</Quote>


So my question here is if I use either of these ways to handle the
message
presumably there would be no way of *automatically* generating the WSDL;
so
I would have to create the WSDL manually, is that correct or am I
missing
something obvious here? If this is the case will there be (in the
future)
a
more closely coupled link between the message handler and the message
format
like say:

[SoapMessage[urn:math:add]]
int Add( int x, int y )
{
return x + y;
}

This would remove the hassle of having to drill into the XML to

get

my

 

[Stuart Celarier]

Lee, I don't understand what you're trying to accomplish.

I want to store information in a central repository that is accessed and

updated by different client applications. The central store should work
without IIS (hence no ASMX) as some customers will not have it.

A Web service needs to be hosted, in some way, to provide it access to a
network transport. Who is hosting the service, you or your customers? Who is
hosting the central repository, you or your customers?

If you own the central repository, then presumably you are also hosting the
service that exposes the repository. I'll assume that's the case for the
moment. Then you need to host the service in an HTTP server such as IIS. If
your customers are running client applications to access your service, then
they do not need to be running IIS. That is exactly the same as them not
needing to run IIS to browse the Web. What am I missing?

Speaking generally, the #1 recommendation for most situations is to create
ASMX Web services using WSE. That is going to create the best migration path
to Indigo, and receive the greatest development effort in terms of new
features going forward.

With respect to WSDL generation, it is a matter of best design practice to
design the contract (interface) of a service before implementing a service.
Having ASMX auto generate WSDL is handy, but it has the same conceptual
problem that we had letting wizards create interfaces in COM [1]. Christian
Weyer has worked in this space for Web services, creating a "Contract First"
VS.NET add-in [2]. Several other authors have written on this issue, notably
Yasser Shohoud.

Cheers,
Stuart Celarier, Fern Creek

[1] See Effective COM, Don Box, et al., 1999. "Item 1: Define your
interfaces before you define your classes (and do it in IDL)". NB: this *is*
Item 1.
[2] http://weblogs.asp.net/cweyer/archive/2003/11/05/35978.aspx

 

[Lee Alexander]

Again, I still see no reason why WSE is used at all. Are you implementing

something that is very WSE-specific ?

I haven't actually implemented anything yet. I am at a exploratory stage
trying to figure out what is the best approach for my problem /
requirements. After watching
<http://msdn.microsoft.com/longhorn/understanding/pillars/indigo/migratevide
o/> I think I have been barking up the wrong tree regarding WSE 2.0.
Basically we have a set of applications that need to share information, they
are client server based applications for the most part and each one is
autonomous in it's own right; however we want them to optionally share
common information between each other and other 3rd party applications. I
figured a good way going about this was to use a service orientated approach
having a web service handle this. One of the requirements is that I can't
rely on IIS being around as some customers won't have it and won't want it.
All the application are going to be on a LAN currently. I was originally
looking at dot net remoting and WSE 2.0. WSE 2.0 doesn't look like it's
right for this as you have to deal with low level stuff out of the box and
it doesn't offer a good upgrade path to indigo. The video I just watched
also said that if you use remoting then there is a clear compile time
upgrade (albeit with some caveats) path to Indigo so I would say that looks
like the technology to look at.

However, REMOTING is very .NET proprietary and can only work between .NET
applications and the WSDL it generates is also non-standards based.

A friend of mine said that you can coerce the WSDL to be more standard using
declaritive attributes. Plus if we can upgrade to indigo when it comes out
then presumably this non-standard behaviour would no longer be an issue.

Like I say i'm still new to this so forgive my *ignorance*. I feel a bit
like a bull in a china shop currently

Thanks for taking time to respond.

Regards
Lee

You can use REMOTING to build your own SOAP and WSDL and house it in a
custom container which you can implement listening services and your own
channels, sinks and ports.

However, REMOTING is very .NET proprietary and can only work between .NET
applications and the WSDL it generates is also non-standards based.

Again, I still see no reason why WSE is used at all. Are you implementing
something that is very WSE-specific ?

I am afraid I am in no position to give you any advice on Indigo.

Regards.

++++++++++++++++++++++++++++++++++

I want to store information in a central repository that is accessed and
updated by different client applications. The central store should work
without IIS (hence no ASMX) as some customers will not have it. WSE 2.0
andremoting seemed to be the best ways to go in this respect (possibly
Indigo) when it's released. The example (wsechat) shown in the link that I
referred to earlier didn't make use of IIS either but also lacked any WSDL
description.

http://www.roguewave.com/developer/tac/examples/leif/LEIFClient_dotNetService/html/7-2.html

This example uses asmx and IIS which I can't use.


Regards
Lee

WS-Security,
DIME VS.NET
can

http://www.roguewave.com/developer/tac/examples/leif/LEIFClient_dotNetService/html/7-2.html

SoapReceiver
and

how

it

would be able to deduce this if the signature of the method is simply:

class MyService: SoapService
{
[SoapMessage[urn:math:add]]
SoapEnvelope MyMessageHandler( SoapEnvelope message )
{
// process message
}
}

I guess I must be missing something.. Also like I said in the original
message it would be nice to bind a message directly to a member

method
of

a
class and the message parameters marshalled to the members relevent
parameter.

I've been reading the following article below as a basis for my
understanding of how you would go about creating a web service using wse
2.0

http://msdn.microsoft.com/msdnmag/issues/03/09/XMLFiles/default.aspx


Thanks for your help...


Regards
Lee



Hi, please see comments below.

--
Thank you very much

Warmest Regards,
William T (Willie) - Softwaremaker
Architect | Evangelist | Consultant

Microsoft Regional Director
http://www.microsoft.com/rd

+++++++++++++++++++++++++++++++++

I am new to Web Services and am trying to get over that feeling of
being
slightly lost in a foreign place so to speak. I have a few questions:

What technology should I be looking at with regards to

implementing

a
web
service under dot net?

<Quote>If you implement a WS under .Net, you are using .Net as the
implementing technology </Quote>

I know this is a pretty open ended question but what
I'm looking for is a technology that will see me in good stead

for
the

future whilst being rooted in the *near* future to present. I

have
had

a
look at Web Services using remoting and also WSE 2. I'm not currently
looking at ASMX as one of my restrictions is that the web service
should
potentially be independent from a web server like IIS. I get the
impression
from postings that remoting is probably the wrong way to go as I might
have
upgrade problems when Indigo comes out; yet it seems the

simplest

in

terms
of attaching messages to methods and automatically generating WSDL
etc..
Thoughts on this?

<Quote>To fully maximize the power and speed of Remoting, its best to
use
the Binary Formatter. If you choose to use the SOAP Formatter, be aware
that
.NET generates its own proprietary version of the WSDL.</Quote>


I have had a look at WSE 2.0 and it seems more difficult to

generate

a
WSDL
file (if not impossible) since there isn't such a tight mapping
between
the
message handler and the message structure. Lets say I have a message
called
Add that takes two parameters and returns the result. From what

I
have

read
for WSE I would derive from SoapReciever and override the Receive
message
manually drilling into the envelopes body using XPath when the message
arrived. Another alternative would be to use SoapService which gives
me
a
little extra help by routing the message to a declared method;

but
the

declared method would still be of the form:

SoapEnvelope MyMessageHandler( SoapEnvelope message )
{
// process message
}

So I would still have to get down and dirty with some XML.

<Quote>I am sorry I am kinda lost here. Are you looking for a tool to
automate the gerneration of the WSDL. There is no need to use WSE for
this.
.NET comes with a tool called the WSDL.exe that generates the WSDL for
you.
If you use VS.NET as the IDE, VS.NET will generate a WSDL wrapper
aropund
the assembly you create. So there is really no need to get into

the
XML

inner plumbings of WSDL.</Quote>


So my question here is if I use either of these ways to handle the
message
presumably there would be no way of *automatically* generating the
WSDL;
so
I would have to create the WSDL manually, is that correct or am I
missing
something obvious here? If this is the case will there be (in the
future)
a
more closely coupled link between the message handler and the message
format
like say:

[SoapMessage[urn:math:add]]
int Add( int x, int y )
{
return x + y;
}

This would remove the hassle of having to drill into the XML to

get

my
parameters etc.

<Quote>I am sorry I am kinda lost here. Are you looking for a tool to
automate the gerneration of the WSDL. There is no need to use WSE for
this.
.NET comes with a tool called the WSDL.exe that generates the WSDL for
you.
If you use VS.NET as the IDE, VS.NET will generate a WSDL wrapper
aropund
the assembly you create. So there is really no need to get into

the
XML

inner plumbings of WSDL.</Quote>


My next stop will be looking at Indigo so how does this fit with where
I'm
trying to go?

Any help/thoughts would be much appreciated...

Regards
Lee

 

[Lee Alexander]

Lee, I don't understand what you're trying to accomplish.
My recent response to softwaremaker might shed some light on what I mean...

Who is hosting the service, you or your customers?

It will be the customers LAN or in some cases just one machine. We have all
sorts of customer using our applications.

Who is hosting the central repository, you or your customers?

The customer.

What am I missing?

Only that this is primarily going to be a LAN based interaction and in some
cases single computer interprocess if that helps.

Speaking generally, the #1 recommendation for most situations is to create
ASMX Web services using WSE. That is going to create the best migration path
to Indigo, and receive the greatest development effort in terms of new
features going forward.

Unfortunately this is not an option as some of the customer will not be able
to use IIS. Some are just one man band types. Others are multi site many
user customers.

With respect to WSDL generation, it is a matter of best design practice to
design the contract (interface) of a service before implementing a service.
Having ASMX auto generate WSDL is handy, but it has the same conceptual
problem that we had letting wizards create interfaces in COM [1]. Christian
Weyer has worked in this space for Web services, creating a "Contract

First"
That sounds very reasonable. I guess there are tools that let you design it
visually and then spit out the WDSL file for you and also maybe some stub
code?

Thanks for your help

Regards
Lee

Lee, I don't understand what you're trying to accomplish.

I want to store information in a central repository that is accessed and

updated by different client applications. The central store should work
without IIS (hence no ASMX) as some customers will not have it.

A Web service needs to be hosted, in some way, to provide it access to a
network transport. Who is hosting the service, you or your customers? Who is
hosting the central repository, you or your customers?

If you own the central repository, then presumably you are also hosting the
service that exposes the repository. I'll assume that's the case for the
moment. Then you need to host the service in an HTTP server such as IIS. If
your customers are running client applications to access your service, then
they do not need to be running IIS. That is exactly the same as them not
needing to run IIS to browse the Web. What am I missing?

Speaking generally, the #1 recommendation for most situations is to create
ASMX Web services using WSE. That is going to create the best migration path
to Indigo, and receive the greatest development effort in terms of new
features going forward.

With respect to WSDL generation, it is a matter of best design practice to
design the contract (interface) of a service before implementing a service.
Having ASMX auto generate WSDL is handy, but it has the same conceptual
problem that we had letting wizards create interfaces in COM [1]. Christian
Weyer has worked in this space for Web services, creating a "Contract First"
VS.NET add-in [2]. Several other authors have written on this issue, notably
Yasser Shohoud.

Cheers,
Stuart Celarier, Fern Creek

[1] See Effective COM, Don Box, et al., 1999. "Item 1: Define your
interfaces before you define your classes (and do it in IDL)". NB: this *is*
Item 1.
[2] http://weblogs.asp.net/cweyer/archive/2003/11/05/35978.aspx

 

[Stuart Celarier]

Lee,

I think you are missing a very big point in trying to compare .NET Remoting
with ASMX Web Services. .NET Remoting is for writing tightly-coupled,
..NET-based, object-oriented systems. Web services are for writing
loosely-coupled, interoperable, service-oriented solutions. They have very
different properties and assumptions, and solve very different problems.
Microsoft, and many other industry players like IBM, BEA, etc., are moving
forward on creating service-oriented solutions around Web services because
they solve different problems than those solved by distributed object
technologies such as .NET Remoting, COM, CORBA and EJB. From what I can tell
about your problem, you would benefit from a Web services solution.

Basically we have a set of applications that need to share information, they
are client server based applications for the most part and each one is
autonomous in it's own right; however we want them to optionally share
common information between each other and other 3rd party applications. I
figured a good way going about this was to use a service orientated approach
having a web service handle this. One of the requirements is that I can't
rely on IIS being around as some customers won't have it and won't want

it.

If your customers are hosting Web services, as opposed to simply using Web
services (see my other post on this thread), then with Web services they
have many options for vendors, platforms and languages. They can use
whatever HTTP server (or other network transport mechanism), SOAP stack and
toolset that suits them. If you go the .NET Remoting route, your customers
have to use the .NET Framework. As an example of the tight coupling that
implies, for your customers to a remote object on your server, you will have
to give them a copy of the assembly that defines the that object's type
(i.e., class) for them to install in their GAC. You can see that has a lot
of implications about carefully coordinating development, deployment and
upgrades to your code, and to the code of your customers. E.g., when you fix
a bug on your end, you might break all of your clients' until they install
your code on their servers, even though the code is running on your server,
not theirs. Tight coupling translates directly into cost in money and time.
Web services avoids that by promoting loose coupling. The correct choice of
technology very much depends on the relationship you want to have (and have
to support) with your customers, just as much as the problem you are trying
to solve.

All the application are going to be on a LAN currently. I was originally
looking at dot net remoting and WSE 2.0. WSE 2.0 doesn't look like it's
right for this as you have to deal with low level stuff out of the box and
it doesn't offer a good upgrade path to indigo.

Microsoft has a very clear and consistent message on this. Creating Web
services using ASMX and WSE is the best way to prepare for Indigo. The
reason is two-fold: Indigo will be wire-compatible with the latest version
of WSE when Indigo ships; and all the new feature sets and new development
are focused on service-orientation. Yes, Indigo is the complete
communication architecture in Longhorn, encompassing .NET Remoting, MSMQ,
Enterprise Services, etc. But Indigo is all about services and
service-orientation. Take a look at the Indigo section of the Longhorn
Developer FAQ [1], and Don Box's article on Indigo in MSDN Magazine [2] for
more perspective.

The video I just watched
also said that if you use remoting then there is a clear compile time
upgrade (albeit with some caveats) path to Indigo so I would say that looks
like the technology to look at.

For interoperability, again, Indigo will be compatible with WSE-based Web
services. In other words, your investments in WSE are protected (caveat:
with whatever version of WSE is current when Indigo ships). On the other
hand, in order to migrate your WSE solutions to the Indigo platform, you
will have to modify your existing WSE-based code. That is because WSE is
extensions to base Web services bolted on top of ASMX, whereas Indigo will
have advanced Web services - secure, reliable, transacted - baked
(integrated) into the platform. This will result in a dramatic reduction of
code. E.g., with WSE you have to write code to utilize WS-Security
functionality; with Indigo security will be supported right out of the box.

A friend of mine said that you can coerce the WSDL to be more standard using
declaritive attributes. Plus if we can upgrade to indigo when it comes out
then presumably this non-standard behaviour would no longer be an issue.

For ASMX/WSE Web services, you can (read 'should') customize the WSDL that
is auto generated by ASMX, and that is done using CLR attributes. I don't
think you have nearly the same level of control trying to customize the
contract generated by .NET Remoting. And I am not sure you'd want to. You
are not going to get a generic Web services client to talk to a .NET
Remoting service that happens to be using the SOAP formatter. With Web
services, the types in the message are based on XML schema (XSD); with .NET
Remoting, the types in the message are CLR types. XSD type describes data,
while CLR type describes objects. Very different worlds. All of this will
absolutely continue to be the case in Indigo (contrary to your last
sentence, above).

Like I say i'm still new to this so forgive my *ignorance*. I feel a bit
like a bull in a china shop currently

No problem, it is a lot to take in all at once. I am sure others share your
questions.

Cheers,
Stuart Celarier, Fern Creek

[1] http://msdn.microsoft.com/longhorn/support/lhdevfaq/default.aspx#Indigo
[2] http://msdn.microsoft.com/msdnmag/issues/04/01/Indigo/default.aspx

 

[Stuart Celarier]

Who is hosting the service, you or your customers?

It will be the customers LAN or in some cases just one machine. We have all
sorts of customer using our applications. ....
The customer.

That goes some distance towards explaining the problem you're trying to
solve. Thanks. Forgive my inability to intuit the rest, I have a few more
questions.

You said there was a central repository (singular), but you said your
customers (multiple) host the repository. I'm confused. Are you saying each
customer has its own central repository? If so, who is it that will access
the various repositories? Is it each customer's business partners accesses
that customer's repository? Or is it all your other customers, forming a
community of customers? Or is it you, in some kind of coordinator or
clearinghouse role?

Unfortunately this is not an option as some of the customer will not be able
to use IIS. Some are just one man band types. Others are multi site many
user customers.

I see a number of options. Given the range of customers that you have, some
may be happy (okay, willing) to host Web services on their own HTTP server.
For example, if they are already hosting their own ASP.NET Web applications
on IIS, they already have the skills, hardware and infrastructure to do it.
For smaller customers, they could easily purchase hosting services available
in the marketplace, or you could even bundle that hosting in one of the
offerings in your product line. Kind of the Radio UserLand model [1]: want a
blog? We've got the software *and* the hosting solution in one package.
Another example of this model would be Groove [2]: single user and small
organizations let Groove host it, enterprises host the server software
themselves. Each solution makes provides the best value for the customer
segment.

Alternately, you could architect a solution so that you do all the hosting
of the Web services and your customers write connected applications that
utilize your service. No need for them to run IIS to make that work, if they
can make HTTP requests, who cares what language, platform or tool vendor
they are using? Translation: a bigger marketplace for your product. In this
case you don't ship code to the customer, you sell them a service. You
change from an independent software vendor to an independent *service*
vendor (or maybe some combination of both).

Without tying the problem specifically to IIS, you have hit on a essential
truth of Web services. With Web services you are no longer selling just a
product, you are selling a product and a service. You could host the
service, your customer could host the service, a third party could host the
service on your behalf or on your customer's behalf, but someone has to host
the service. As you approach Web services it is important to understand that
that fundamentally changes your business model: the ways in which you can
make money (I don't see too many people turning down revenue streams these
days) and the ways in which you interact with your customers. It is not just
a choice of technologies.

I don't want to create the impression that this is a mutually exclusive
decision between .NET Remoting and Web services. You can write your data
access and business logic, and then create both a remoting interface and a
service interface to expose those business capabilities. Depending on the
circumstances, a single customer might want to use both interfaces: .NET
Remoting for use in internal applications that actually want to be tightly
coupled with your product; and Web services for external clients that cannot
afford to break every time your product is revved. If you push out a .NET
Remoting solution to your customers, and they push that out, in turn, to
their customers, then there will be a very high cost for both your customers
and their customers when you do any maintenance. As I explained elsewhere,
if you recompile your assemblies (e.g., for a bug fix), your customers will
need to install them on their systems and require their customers to install
them on their systems in a sinlge monolithic deployment. If you go that
route, look at something like ClickOnce to help your customers manage that.
Otherwise TCO will likely become a deal breaker.

That sounds very reasonable. I guess there are tools that let you design it
visually and then spit out the WDSL file for you and also maybe some stub
code?

I've only seen a few demos, but Whitehorse [3, 4] in Whidbey might be the
solution you are looking for in that space. But it's not here yet. Currently
you'll find designer support for WSDL in a variety of products, such as XML
Spy [5].

Frankly, I don't think WSDL is all that hard, just a little baroque, but
that comes with the XML territory, not really WSDL per se. There are (IIRC)
six sections to the WSDL, and you can learn a lot of the WSDL syntax by
creating sample ASMX projects, running them and looking at the auto
generated WSDL (click on Service Description). The point that should be
stressed, however, is that the message content in WSDL is described using
XML schema (XSD), and without an understanding of the basics of XSD [6]
you're going to be at a major disadvantage. To my thinking, no amount of
graphic designer goodness can abstract away the differences between object
types in OO and data types in XSD. It is the difference between nominal
equivalence and structural equivalence, and it is a distinction that runs
deep (as I have learned the hard way).

I am curious about your other objective, which is a good path to Indigo. Are
you talking about your effort as an ISV to migrate your product to Indigo?
Or your customers' ability to continue to use your product when they migrate
to Indigo? Or something else entirely? What do challenges do you perceive
there?

Cheers,
Stuart Celarier, Fern Creek

[1] http://radio.userland.com/
[2] http://www.groove.net/
[3]
http://www.microsoft.com/downloads/...b9-81e1-4a99-913f-788c3fe3ef49&DisplayLang=en
[4]
http://msdn.microsoft.com/vstudio/p...library/en-us/dnvsent/html/vsent_soadover.asp
[5] http://www.xmlspy.com/features_wsdl.html
[6] http://www.w3.org/TR/xmlschema-0/

 

[Stuart Celarier]

Speaking of .NET Remoting and migrating to Indigo: Rich Turner, PM for
Indigo, just blogged about the future of remoting in Indigo [1]. For that
matter all five of Rich's postings on this nascent blog are worth checking
out.

Best with .NET Remoting under Indigo you will no longer need to share
your assemblies with the callers.

Cheers,
Stuart Celarier, Fern Creek

[1] http://weblogs.asp.net/richturner666/archive/2004/03/05/84771.aspx

 

[Stuart Celarier]

Something that I totally overlooked mentioning before: using WSE 2.0 [1],
then you can use Web services over TCP which completely obviates the need
for an HTTP server such as IIS. A good starting point is here [2].

Cheers,
Stuart Celarier, Fern Creek
Longhorn Developer FAQ: http://msdn.microsoft.com/Longhorn/Support/lhdevfaq

[1]
http://www.microsoft.com/downloads/...9a-c5f6-4c95-87b7-fc7ab49b3edd&displaylang=en

[2] http://msdn.microsoft.com/library/en-us/dnwse/html/programwse2.asp

 

[Lee Alexander]

Hi Stuart,

Thanks for taking the time to respond! I've been away for a few days so
sorry for not getting back you earlier. Answers inline:

You said there was a central repository (singular), but you said your
customers (multiple) host the repository. I'm confused. Are you saying each
customer has its own central repository?

Each customer will have their own repository. We have a number of different
customer profiles:

1. One man band customer who works on his own on a single computer (may
not have an internet connection).
2. Small firm using a pear to pear type network.
3. Larger firm has a dedicated servers running over a LAN.
4. Firm who has Mulitple sites running over a WAN (potential future
customer).

For customer profiles 3 and 4 they may want to communicate with the service.

We supply the software to the customers on a CD and in some cases will go to
the
customers site to setup the software, do training and also convert
information into the
new system from legacy systems.

For smaller customers, they could easily
purchase hosting services available in the marketplace,
or you could even bundle that hosting in one of the
offerings in your product line.

All of our customers (in this context) are accountants and they don't like
to spend *extra* money with the exception of the larger firms

Without tying the problem specifically to IIS, you have hit on a essential
truth of Web services. With Web services you are no longer selling just a
product, you are selling a product and a service.

It certianly opens up the possibility for us to host the service ourselves
but more immediate uses would be:
1. To keep the loose coupling between the applications.
2. Enabling the communication of shared information between the applications
(via the service).
3. Version independence allowing each application to be released separately
(reducing the burdon on the testing department).

You can write your data
access and business logic, and then create both a remoting interface and a
service interface to expose those business capabilities. Depending on the
circumstances, a single customer might want to use both interfaces: .NET
Remoting for use in internal applications that actually want to be tightly
coupled with your product; and Web services for external clients that cannot
afford to break every time your product is revved

This is a possibility, that way we could keep the door open on a number of
avenues.

if you recompile your assemblies (e.g., for a bug fix), your customers will
need to install them on their systems and require their customers to install
them on their systems in a sinlge monolithic deployment.

I thought by using the Soapsuds tool for creating the client assembly you
shield yourself from any internal changes as long as the signiture of the
service methods (marked by SoapMethod attribute) don't change. Is this not
the case? Version independence is an essential requirement for us.

I am curious about your other objective, which is a good path to Indigo. Are
you talking about your effort as an ISV to migrate your product to Indigo?

Yep, traditionally we have been geared to developing products using MFC /
COM etc. Then a couple years ago we decided to use the .NET framework for a
new product. With the success of that development
<http://www.digita.com/pro/home/accountspro/default.asp> we are migrating
all of our products to the framework either rewriting some bits or using IJW
to leverage traditional C++ whilst benefiting from .NET. SOA and
consequently indigo seem to be the way to go for getting our seperate
applications / components to talk to one another. This would also open up
the possibilty as you said to also offer the services on the internet that
otherwise might only have been client bound.

Regards
Lee

 

[Stuart Celarier]

I thought by using the Soapsuds tool for creating the client assembly you
shield yourself from any internal changes as long as the signiture of the
service methods (marked by SoapMethod attribute) don't change. Is this not
the case? Version independence is an essential requirement for us.

I am no expert on Soapsuds, but I've heard that use of SoapSuds may not
still considered a good practice, e.g., see [1]. The author, Ingo Rammer, is
also author of two .NET Remoting books and and FAQ that you may want to
investigate.

It is just not feasible to require that all versions hold the interface
constant. Signatures will change, methods will be added and removed. You
need to ask whether you want or need to provide backward or forward
compatibility in the face of such changes. Doug Purdy is giving a talk on
"Connected Applications: Versioning Hetergeneous Distributed Systems" at
TechEd 2004 [2]. TechEd would be a great place to get answers to your
questions, if you haven't thought about it. Doug also covers some versioning
issues in his "Loosely Coupled Web Services" video on MSDN TV [3].
Versioning a Web service has a lot to do with versioning XML, about which
there has been much discussion lately, Dare Obasanjo's blog [4] on the
subject is a good starting point.

Versioning is always a complicated story, often given short schrift until
it's too late, rarely correct, and often requiring advanced planning and
action. If you wait until after v1.0 to figure out your versioning story,
you've alread lost. And a tool (e.g., SoapSuds) doesn't mitigate all of that
complexity.

Can anyone shed light on the versioning support in Indigo? I haven't seen
much written, maybe it is undecided or in a state of flux? That or I am
looking in all the wrong places.

Cheers,
Stuart Celarier, Fern Creek
Longhorn Developer FAQ: http://msdn.microsoft.com/Longhorn/Support/lhdevfaq

[1] http://www.ingorammer.com/RemotingFAQ/SoapSudsOrInterfaces.html
[2] http://www.microsoft.com/seminar/teched2004/default.mspx
[3]
http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20030722WEBSVCSDP/manifest.xml
[4]
http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=4d18d061-8895-46e0-b5b5-7d51c7fb8898