More than 1 web service?

[Andy B]

I have several tasks that my web applications need to do. They are managing
membership, News, Events, Legal forms for admin, Legal forms for customers,
audio and maybe a few other things here and there. A lot of these things
will be used in more than 1 web application. I am trying to centeralize
everything into as much reusable code as possible. What I need to know is:
Do I take these different tasks and break them down into different web
services? Or use different classes in the web service for each task? How
exactly does hhis work? Can WCF web services use datasets and other kinds of
data manipulation/storage related objects? and can you use the default
asp.net or your own defined membership provider in a web.config file to
manage membership in a web service?

I am new to WCF web services and don't really know anything about them
except that they are a place where you can centeralize all of your code for
use in more than 1 application. Where would I start out with this? I was
told I should use WCF web services over the other types. Why is this?

 

[Michael Nemtsev [MVP]]

Hello Andy,


AB> I have several tasks that my web applications need to do. They are
AB> managing membership, News, Events, Legal forms for admin, Legal
AB> forms for customers, audio and maybe a few other things here and
AB> there. A lot of these things will be used in more than 1 web
AB> application. I am trying to centeralize everything into as much
AB> reusable code as possible. What I need to know is: Do I take these
AB> different tasks and break them down into different web services?

it depends how and where these task are used - single machine or different,
who is using them, do they have the same rights

AB> use different classes in the web service for each task? How exactly
AB> does hhis work?

You should consider this by "why I want to split them" ?! for the sake of
what?!

AB> Can WCF web services use datasets and other kinds of
AB> data manipulation/storage related objects? and can you use the
AB> default asp.net or your own defined membership provider in a
AB> web.config file to manage membership in a web service?

yep



---
WBR,
Michael Nemtsev [Microsoft MVP] :: blog: http://spaces.live.com/laflour

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

 

[Andy B]

AB> I have several tasks that my web applications need to do. They are

AB> managing membership, News, Events, Legal forms for admin, Legal
AB> forms for customers, audio and maybe a few other things here and
AB> there. A lot of these things will be used in more than 1 web
AB> application. I am trying to centeralize everything into as much
AB> reusable code as possible. What I need to know is: Do I take these
AB> different tasks and break them down into different web services?
it depends how and where these task are used - single machine or different,

The same web server with different web applications. There is a little
possibility that a client windows application will be built to be used from
a remote computer.

who is using them,

The website admin For the administration of legal forms for admin, News,
events, audio and partially the legal forms for customers. The customers
will use it for the legal forms for customers. The rest of it like
membership/profile providers would be used by the internal web application
system to provide access to these different parts.

do they have the same rights

Can you explain what you mean more by having the same rights? If you mean
having the same access rights to the different sections of the web
applications and if they have control over the data stores being used, I
would imagine that each WCF service in the WCF service project would be
restricted to its own data store and the access to things would be limmited
to what they individually would need in order to get their jobs done. For an
example, the Audio service would not need to know what is going on with the
services for legal forms. Using the Audio service example, It would need
access to a database with membership provider, its own database to store
audio related information and it would need to have access to the app_data
folder of the project that makes use of the audio service. This means that
the Audio service most likely would need access to the Membership service to
determine if the admin was loged in or not. This is nowhere an extensive
layout, but is a good example of one of the service requirements. Actually,
most of the services I would need would probably need access to multiple
locations on the solution like the audio example.

AB> use different classes in the web service for each task? How exactly
AB> does hhis work?
You should consider this by "why I want to split them" ?!

Just trying to be more organized with the code. Why would you want methods
for an Audio service located in a membership service? Well, ok not the best
example, will try this again. Why would you want to mix methods for the
Audio service with the methods from the News or events services? They are
totally unrelated for one, and it makes it easier for me to know what
service/section of the service to jump to if they are divided into multiple
services.

for the sake of what?!

What do you mean by this? See abovwe. Unless there are too many
risks/performance problems with dividing the services up into each task
type...Let me know if there are any?

AB> Can WCF web services use datasets and other kinds of
AB> data manipulation/storage related objects? and can you use the
AB> default asp.net or your own defined membership provider in a
AB> web.config file to manage membership in a web service?

yep

I had a huntch you could but figured I would ask first.




---
WBR,
Michael Nemtsev [Microsoft MVP] :: blog: http://spaces.live.com/laflour

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

 

[Michael Nemtsev [MVP]]

Hello Andy,


AB> The same web server with different web applications. There is a
AB> little possibility that a client windows application will be built
AB> to be used from a remote computer.
AB> AB> The website admin For the administration of legal forms for admin,
AB> News, events, audio and partially the legal forms for customers. The
AB> customers will use it for the legal forms for customers. The rest of
AB> it like membership/profile providers would be used by the internal
AB> web application system to provide access to these different parts.

well, so it's role-based system
AB> project would be restricted to its own data store and the access to
AB> things would be limmited to
AB> For an example, the Audio service
AB> would not need to know what is going on with the services for legal
AB> forms. Using the Audio service example, It would need access to a
AB> database with membership provider, its own database to store audio
AB> related information and it would need to have access to the
AB> app_data folder of the project that makes use of the audio service.

It sounds that it's better to create different webservers, because it simplifies
you the setting security for each of them
AB> Just trying to be more organized with the code. Why would you want
AB> methods for an Audio service located in a membership service? Well,
AB> ok not the best example, will try this again. Why would you want to
AB> mix methods for the Audio service with the methods from the News or
AB> events services? They are totally unrelated for one, and it makes it
AB> easier for me to know what service/section of the service to jump to
AB> if they are divided into multiple services.

exactly. split them logically and extract common stuff to the separate assembly
shared amont them

AB> What do you mean by this? See abovwe. Unless there are too many
AB> risks/performance problems with dividing the services up into each
AB> task type...Let me know if there are any?

if you are not going to end up with the 100 webservices I wouldn't consider
performace issues there

---
WBR,
Michael Nemtsev [Microsoft MVP] :: blog: http://spaces.live.com/laflour

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

 

[Andy B]

So, the basic conclusion is that it would be best probably to create a WCF
service project and create different services in that project for each task
that the web applications need to complete... Just making sure I get the
final line before starting...

Hello Andy,


AB> The same web server with different web applications. There is a
AB> little possibility that a client windows application will be built
AB> to be used from a remote computer.
AB>AB> The website admin For the administration of legal forms for admin,
AB> News, events, audio and partially the legal forms for customers. The
AB> customers will use it for the legal forms for customers. The rest of
AB> it like membership/profile providers would be used by the internal
AB> web application system to provide access to these different parts.

well, so it's role-based system
AB> project would be restricted to its own data store and the access to
AB> things would be limmited to AB> For an example, the Audio service
AB> would not need to know what is going on with the services for legal
AB> forms. Using the Audio service example, It would need access to a
AB> database with membership provider, its own database to store audio
AB> related information and it would need to have access to the
AB> app_data folder of the project that makes use of the audio service.

It sounds that it's better to create different webservers, because it
simplifies you the setting security for each of them
AB> Just trying to be more organized with the code. Why would you want
AB> methods for an Audio service located in a membership service? Well,
AB> ok not the best example, will try this again. Why would you want to
AB> mix methods for the Audio service with the methods from the News or
AB> events services? They are totally unrelated for one, and it makes it
AB> easier for me to know what service/section of the service to jump to
AB> if they are divided into multiple services.

exactly. split them logically and extract common stuff to the separate
assembly shared amont them

AB> What do you mean by this? See abovwe. Unless there are too many
AB> risks/performance problems with dividing the services up into each
AB> task type...Let me know if there are any?

if you are not going to end up with the 100 webservices I wouldn't
consider performace issues there

---
WBR, Michael Nemtsev [Microsoft MVP] :: blog:
http://spaces.live.com/laflour
"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo