OO style Webservices or not

[Allan Ebdrup]

I just had a discussion with one of my fellow programmers.
We have a class for doing some logging and sending an email, it has 5
different scenarioes of loggin that are common enough to share a class and
database tables.
In the future there might be new scenarioes that require their own custom
classes and database tables.

Now we want to expose some of our logging class's methods as webservices
(more a group of function calls called in one batch)

I want to use an OO-like approach to laying out the webservice where we have
the methods of this one logging class in one .asmx file and create other
..asmx files for the future logging classes. Then we group all the logging
..asmx files together in the same namespace (and directory)

He want's to bunch all the Add methods together and have a .AddClass1 method
and a .AddClass2 method and so on in the same .asmx file

What approach is the best? Does one not apply some OO principles to
webservices (I mean: they are declared as a class with webmethods) or does
on simply create function libraries with some (hopefully) meaningfull
grouping of functions.

I hope you have some insights to a best practice for the architecture of
webservices.

Kind Regards,
Allan Ebdrup

 

[Jay B. Harlow [MVP - Outlook]]

Allan,
I can see using either approach, depending on the real needs of the web
service & how interchangable & dynamic each "Scenario" usage is.

| I want to use an OO-like approach to laying out the webservice where we
have
| the methods of this one logging class in one .asmx file and create other
| .asmx files for the future logging classes. Then we group all the logging
| .asmx files together in the same namespace (and directory)
If you are "replacing" the scenario/strategy of how which logger to use I
can see this. This month I want to call the "EventLog" logging web service,
while next month I want to call "Database" logging web service.

This would require changing config on each client (possibly many clients) to
change which logger was used.


| What approach is the best? Does one not apply some OO principles to
| webservices (I mean: they are declared as a class with webmethods) or does
| on simply create function libraries with some (hopefully) meaningfull
| grouping of functions.
I commonly use the Facade Pattern when implementing a Web Service. The
internal implementation of the Web Service itself would be full OO, while
the Web Service's interface itself would be rather "flat". For example I
always want to call the logging web service, however this month the logging
web service logs to event logs, while next month it logs to a database...

This would require changing config on the server itself (only a single
server) to change which logger was used. Alternatively which "logger" to use
could be a parameter to the web service...

| He want's to bunch all the Add methods together and have a .AddClass1
method
| and a .AddClass2 method and so on in the same .asmx file
I'm not sure what "AddClass1" & "AddClass2" is suppose to do? They sound
like implementation details, I would try to abstract away specific
implementation details when I defined the facade...

Hope this helps
Jay


|I just had a discussion with one of my fellow programmers.
| We have a class for doing some logging and sending an email, it has 5
| different scenarioes of loggin that are common enough to share a class and
| database tables.
| In the future there might be new scenarioes that require their own custom
| classes and database tables.
|
| Now we want to expose some of our logging class's methods as webservices
| (more a group of function calls called in one batch)
|
| I want to use an OO-like approach to laying out the webservice where we
have
| the methods of this one logging class in one .asmx file and create other
| .asmx files for the future logging classes. Then we group all the logging
| .asmx files together in the same namespace (and directory)
|
| He want's to bunch all the Add methods together and have a .AddClass1
method
| and a .AddClass2 method and so on in the same .asmx file
|
| What approach is the best? Does one not apply some OO principles to
| webservices (I mean: they are declared as a class with webmethods) or does
| on simply create function libraries with some (hopefully) meaningfull
| grouping of functions.
|
| I hope you have some insights to a best practice for the architecture of
| webservices.
|
| Kind Regards,
| Allan Ebdrup
|
|

 

[Nicholas Paldino [.NET/C# MVP]]

Allan,

This is a tricky subject. I think what a good number of people don't
realize is that web services are not OO, and as a result, there is not a lot
of fidelity when trying to map one to the other. Web services are
inherently stateless, while OO is all about the ability to encapsulate state
in an object (or rather, that's a big cornerstone of it).

That being said, I think that your fellow programmer is wrong. Adding
methods with just another name on it will just make things confusing. What
it sounds like you want here is interfaces.

However, you can't really define interfaces on a web service. That
doesn't mean that you can't follow a contract (which is what interfaces are
all about). What you need to do is have each of your web services have the
same method declarations. Then, you place the different implementations of
these method declarations in different directories, so that they have
different URLs (it also makes maintenence of the code easier).

Then, on the client side, you declare your interface. You then generate
web references to each of the different implementations on the server,
creating separate web-proxies.

You can then extend from each of these (since you don't want to play
with IDE-generated code) to implement the interface.

Once you have that, you should have a number of classes that implement
the interface, which you can now use a factory pattern to create (returning
just a reference to the interface).

Hope this helps.

 

[Nick Malik [Microsoft]]

Web services are not OO.

See Scott Seely's excellent article on versioning (and therefore extending)
web services
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/html/service10152002.asp

This will help somewhat.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.

 

[Jay B. Harlow [MVP - Outlook]]

Nicholas,
| This is a tricky subject. I think what a good number of people don't
| realize is that web services are not OO, and as a result, there is not a
lot
| of fidelity when trying to map one to the other.
I agree they are not OO per se, however I disagree about the fidelity. If
each web service binds to the same WSDL, then there should (*should*) be
high fidelity between them.

| However, you can't really define interfaces on a web service. That
| doesn't mean that you can't follow a contract (which is what interfaces
are
| all about).
Actually I understand you can define "interfaces" on web services. You use
the WebServiceBindingAttribute to indicate which "interface" this web
service/web method is binding to. By "interface" I mean which WSDL document
that defines the web service binds to/implements.

The client simply replaces which URL it refers to. Each specific web service
can "implement" the exact same WSDL.

For an introduction see:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnservice/html/service02202002.asp

Unfortunately I don't have a good example with code...

| Then, on the client side, you declare your interface. You then
generate
| web references to each of the different implementations on the server,
| creating separate web-proxies.
Based on the above. The client only needs a single web-proxy, however it
would need to change what web address it was using. Either using a Dynamic
URL or WebClientProtocol.Url.

Jay

message | Allan,
|
| This is a tricky subject. I think what a good number of people don't
| realize is that web services are not OO, and as a result, there is not a
lot
| of fidelity when trying to map one to the other. Web services are
| inherently stateless, while OO is all about the ability to encapsulate
state
| in an object (or rather, that's a big cornerstone of it).
|
| That being said, I think that your fellow programmer is wrong. Adding
| methods with just another name on it will just make things confusing.
What
| it sounds like you want here is interfaces.
|
| However, you can't really define interfaces on a web service. That
| doesn't mean that you can't follow a contract (which is what interfaces
are
| all about). What you need to do is have each of your web services have
the
| same method declarations. Then, you place the different implementations
of
| these method declarations in different directories, so that they have
| different URLs (it also makes maintenence of the code easier).
|
| Then, on the client side, you declare your interface. You then
generate
| web references to each of the different implementations on the server,
| creating separate web-proxies.
|
| You can then extend from each of these (since you don't want to play
| with IDE-generated code) to implement the interface.
|
| Once you have that, you should have a number of classes that implement
| the interface, which you can now use a factory pattern to create
(returning
| just a reference to the interface).
|
| Hope this helps.
|
|
| --
| - Nicholas Paldino [.NET/C# MVP]
| - (e-mail address removed)
|
| | >I just had a discussion with one of my fellow programmers.
| > We have a class for doing some logging and sending an email, it has 5
| > different scenarioes of loggin that are common enough to share a class
and
| > database tables.
| > In the future there might be new scenarioes that require their own
custom
| > classes and database tables.
| >
| > Now we want to expose some of our logging class's methods as webservices
| > (more a group of function calls called in one batch)
| >
| > I want to use an OO-like approach to laying out the webservice where we
| > have the methods of this one logging class in one .asmx file and create
| > other .asmx files for the future logging classes. Then we group all the
| > logging .asmx files together in the same namespace (and directory)
| >
| > He want's to bunch all the Add methods together and have a .AddClass1
| > method and a .AddClass2 method and so on in the same .asmx file
| >
| > What approach is the best? Does one not apply some OO principles to
| > webservices (I mean: they are declared as a class with webmethods) or
does
| > on simply create function libraries with some (hopefully) meaningfull
| > grouping of functions.
| >
| > I hope you have some insights to a best practice for the architecture of
| > webservices.
| >
| > Kind Regards,
| > Allan Ebdrup
| >
|
|

 

[Nicholas Paldino [.NET/C# MVP]]

Jay,

I agree they are not OO per se, however I disagree about the fidelity. If
each web service binds to the same WSDL, then there should (*should*) be
high fidelity between them.

I meant between OO and Web Services. Web Services are stateless, OO is
not. Most people don't realize that you shouldn't be storing state in your
web service implementations across calls.

Actually I understand you can define "interfaces" on web services. You use
the WebServiceBindingAttribute to indicate which "interface" this web
service/web method is binding to. By "interface" I mean which WSDL
document
that defines the web service binds to/implements.

Yes, you are right, but I was referring to an interface in the .NET
sense, not the WSDL contract. However, this is a contract, which is really
what an interface is, and you can use to enforce a contract, so that
definitely should be used.

Based on the above. The client only needs a single web-proxy, however it
would need to change what web address it was using. Either using a Dynamic
URL or WebClientProtocol.Url.

Good point. I got too wrapped up in the whole interface thing, but one
proxy should be enough.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Jay

in
message | Allan,
|
| This is a tricky subject. I think what a good number of people don't
| realize is that web services are not OO, and as a result, there is not a
lot
| of fidelity when trying to map one to the other. Web services are
| inherently stateless, while OO is all about the ability to encapsulate
state
| in an object (or rather, that's a big cornerstone of it).
|
| That being said, I think that your fellow programmer is wrong.
Adding
| methods with just another name on it will just make things confusing.
What
| it sounds like you want here is interfaces.
|
| However, you can't really define interfaces on a web service. That
| doesn't mean that you can't follow a contract (which is what interfaces
are
| all about). What you need to do is have each of your web services have
the
| same method declarations. Then, you place the different implementations
of
| these method declarations in different directories, so that they have
| different URLs (it also makes maintenence of the code easier).
|
| Then, on the client side, you declare your interface. You then
generate
| web references to each of the different implementations on the server,
| creating separate web-proxies.
|
| You can then extend from each of these (since you don't want to play
| with IDE-generated code) to implement the interface.
|
| Once you have that, you should have a number of classes that
implement
| the interface, which you can now use a factory pattern to create
(returning
| just a reference to the interface).
|
| Hope this helps.
|
|
| --
| - Nicholas Paldino [.NET/C# MVP]
| - (e-mail address removed)
|
| | >I just had a discussion with one of my fellow programmers.
| > We have a class for doing some logging and sending an email, it has 5
| > different scenarioes of loggin that are common enough to share a class
and
| > database tables.
| > In the future there might be new scenarioes that require their own
custom
| > classes and database tables.
| >
| > Now we want to expose some of our logging class's methods as
webservices
| > (more a group of function calls called in one batch)
| >
| > I want to use an OO-like approach to laying out the webservice where
we
| > have the methods of this one logging class in one .asmx file and
create
| > other .asmx files for the future logging classes. Then we group all
the
| > logging .asmx files together in the same namespace (and directory)
| >
| > He want's to bunch all the Add methods together and have a .AddClass1
| > method and a .AddClass2 method and so on in the same .asmx file
| >
| > What approach is the best? Does one not apply some OO principles to
| > webservices (I mean: they are declared as a class with webmethods) or
does
| > on simply create function libraries with some (hopefully) meaningfull
| > grouping of functions.
| >
| > I hope you have some insights to a best practice for the architecture
of
| > webservices.
| >
| > Kind Regards,
| > Allan Ebdrup
| >
|
|

 

[Joerg Jooss]

I just had a discussion with one of my fellow programmers.
We have a class for doing some logging and sending an email, it has 5
different scenarioes of loggin that are common enough to share a
class and database tables. In the future there might be new
scenarioes that require their own custom classes and database tables.

Now we want to expose some of our logging class's methods as
webservices (more a group of function calls called in one batch)

As Nick pointed out, Web Services (or any kind of distributed computing
model) should not be approached in a classic OO fashion.

I also wonder why on earth anybody would want to turn logging into a
Web Service -- this is probably one of the all time worst ideas I can
think of =:-O

Cheers,

 

[Allan Ebdrup]

As Nick pointed out, Web Services (or any kind of distributed computing
model) should not be approached in a classic OO fashion.

Then how should it be approached? Some pointers to some articles or more
info would be greatly appreciated.

I also wonder why on earth anybody would want to turn logging into a
Web Service -- this is probably one of the all time worst ideas I can
think of =:-O

It's not so much logging as it is record keeping, it's a webservice that's
called several different places from a very large ASP3.0 application.

We use webservices to integrate our old ASP3.0 application with new dotNet
components when we can implement interfaces that make sense and are not too
chatty.

Kind Regards,
Allan Ebdrup

 

[Nick Malik [Microsoft]]

Then how should it be approached? Some pointers to some articles or more
info would be greatly appreciated.

Was the article I pointed out not enough?



--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--