Re: Web Services configuration
- From: Scott Seely <ScottSeely@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 2 Nov 2006 08:54:02 -0800
Lots of interesting feedback here. Thank goodness you are using WCF. What you
should do is separate your feature sets into separate contracts. One class
can implement many contracts. Then, when the application starts up, it can
have logic to decide which of those contracts should be exposed as endpoints.
If you own the entire application and not just a library, the code to
add/remove endpoints would go somewhere between the lines
ServiceHost service = new ServiceHost();
and
service.Open();
"Claus Konrad [MCSD]" wrote:
Okay. That changes the situation a bit..
I still feel that controling this by means of 3 distinct assemblies with
various functionality will be "overkill". How to you intend to control it
anyways?
Will you provide a licensefile openign up to this functionality if purchased?
And image the hazzle of maintaining three almost simular builds!
Refactor your code and provide functionality from within a factory
internally. The interface will be the same to the client (presenting the full
monthy), but only some of the methods will function. Others will throw
"NotAvailableException"s or somthing like that.
The fact that the Client actually can see the methods, but just not use them
also encourages him to purchase this added functionality?
--
rgds.
/Claus Konrad
MCSD.NET (C#)
"A" wrote:
Thank you for your answer.
Our problem is a little bit different. We are selling the WebService to the
client (he will install the WebService on his server) and if he is not
buying a certain functionality, he mustn't be able to see it in the
WebService. I was thinking like something similar with having 3 libraries,
and at the deployment time deploy just one of them (the one he bought it).
Thank you
"Claus Konrad [MCSD]" <ClausKonradMCSD@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:F1A7C9FA-4CB5-4BA7-8660-4B2F1FFFFB53@xxxxxxxxxxxxxxxx
The Client will be programming against an interface or a proxy if you
will.
Once this is generated or created, he will see the operations presented by
this interface. If you want this bahaviour, you could potentially factor
the
interface into 2 distinct parts on the client side, allowing only use of
the
one over the other.
This is only good as long as the client does not regenerate the proxy!
However - a much better approach is to simply govern the use of the two
methods (get/set) by means of PrincipalPermissionAttribute. When ever
calling
into the service from the clientside, an exception will be thrown if the
caller does not present the appropriate credentials.
--
rgds.
/Claus Konrad
MCSD.NET (C#)
"A" wrote:
Hello
I'm using WCF and I would like to know if there is possible to have
something like:
a WebService with 2 methods: Get and Set
and at the deployment time on a server X to decide that the Set method
must
be "hidden" (a X's clients cannot call it or cannot see it) and
on another server Y the Set method is visible an functional (all the Y's
clients can call it).
Thank you
- Follow-Ups:
- Re: Web Services configuration
- From: A
- Re: Web Services configuration
- References:
- Web Services configuration
- From: A
- Re: Web Services configuration
- From: A
- Re: Web Services configuration
- From: Claus Konrad [MCSD]
- Web Services configuration
- Prev by Date: More description on the web page - maybe a label?
- Next by Date: RE: facing problem to "Calling dotnet created Web Services in VB6"
- Previous by thread: Re: Web Services configuration
- Next by thread: Re: Web Services configuration
- Index(es):
Relevant Pages
|
