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

encapsulating webservice proxy to hide complexity

P: n/a
I'm to deploy a .NET DLL which internally communicates with the WS. I
don't want others to see internal complexity of the web service
classes generated by "Add a Web reference" VS option.
As a WebSerive contains a lot of methods and different types creating
a web proxy class manually is too time consuming.

I tried to edit a class manually, changing the highest-level access
modifiers from public to internal - this way I could use the classes
from within the DLL, exposing only my API. However, this does not work
correctly - "some" of the classes have to be public (e.g. a class
defined as a SoapHeader, but not only) - when changing the access
modifier to internal, I got an error "Method XXX can not be reflected"
when trying to create an instance of the web proxy...

So the question is:
a) where could I find some information what is exactly done by
hte .NET framework during a proxy class lifetime
b) is there any other method (preferably automatic...) to hide as much
information as possible from the proxy class?
Thanks

May 16 '07 #1
Share this Question
Share on Google+
10 Replies


P: n/a
"roberto" <ro****************@gmail.comwrote in message
news:11**********************@u30g2000hsc.googlegr oups.com...
I'm to deploy a .NET DLL which internally communicates with the WS. I
don't want others to see internal complexity of the web service
classes generated by "Add a Web reference" VS option.
As a WebSerive contains a lot of methods and different types creating
a web proxy class manually is too time consuming.

I tried to edit a class manually, changing the highest-level access
modifiers from public to internal - this way I could use the classes
from within the DLL, exposing only my API. However, this does not work
correctly - "some" of the classes have to be public (e.g. a class
defined as a SoapHeader, but not only) - when changing the access
modifier to internal, I got an error "Method XXX can not be reflected"
when trying to create an instance of the web proxy...

So the question is:
a) where could I find some information what is exactly done by
hte .NET framework during a proxy class lifetime
b) is there any other method (preferably automatic...) to hide as much
information as possible from the proxy class?
Yes. You should write a second web service which abstracts the first. The
second service should try to be less fine-grained. That is, it should use an
SOA metaphor. You should then expose the second service.
--
John Saunders [MVP]

P.S. Of course, the alternative would be to have written the web service
that way to begin with, but if that's not an option, then a "proxy" service
is one way to fix the original without touching the code.
May 16 '07 #2

P: n/a
The question is not about server-side methods - they are optimised for
web access. The problem is that a client proxy DLL is to be used in
third-party application, so I'd like to hide its methods to not
confuse people when they try to use Intellisense.

The simpliest example: the web service gives a list of available files
and allows to download them one by one (e.g. GetFilesInfo,
GetFileByName). What I want to expose to DLL's clients is
RefreshLocalCache method, which will internally call the
aforementioned and take care of error handling etc. So - in this case
- I really don't want my Web Proxy class to be exposed...

As I said, nothing wrong WILL happen if somebody calls the WS either
directly or from the proxy; but by exposing too much I'll have to
respond to questions concerning the internal (from my POV) method
usage - who reads the documentation? developers use Intellisense....
(that's another argument against - web proxy methods don't have any
documentation by default)

Thanks

May 17 '07 #3

P: n/a
(sorry if the similar message is already posted, but I don't see it on
the list since "successful" posting 3 hours ago...)

Web Service API is a minimal one, there is nothing to refactor. What I
want is to hide complexities of the proxy from third-party
applications using my DLL (not a WS).
Example: I'm exposing a .NET DLL with method UpdateLocalCache(); it
transparently call some methods from the proxy:
GetFileList() x1
GetFileByName() x N
In this example I don't want the DLL's users to see GetFilexxx methods
(and all proxy additional details, e.g. timeouts, credentails etc.).

Don't get me wrong - I know the WS methods can be used either directly
from user generated proxies or from the web browser... I just don't
want to answer questions/problems like "how should I call the
method...." - and this will come, as developers tend to use
Intellisense withour bothering about documentation (btw, another issue
with the proxy class - it's not documented by default...).

Thanks

May 17 '07 #4

P: n/a
(sorry if the similar message is already posted, but I don't see it on
the list since "successful" posting 3 hours ago...)

Web Service API is a minimal one, there is nothing to refactor. What I
want is to hide complexities of the proxy from third-party
applications using my DLL (not a WS).
Example: I'm exposing a .NET DLL with method UpdateLocalCache(); it
transparently call some methods from the proxy:
GetFileList() x1
GetFileByName() x N
In this example I don't want the DLL's users to see GetFilexxx methods
(and all proxy additional details, e.g. timeouts, credentails etc.).

Don't get me wrong - I know the WS methods can be used either directly
from user generated proxies or from the web browser... I just don't
want to answer questions/problems like "how should I call the
method...." - and this will come, as developers tend to use
Intellisense withour bothering about documentation (btw, another issue
with the proxy class - it's not documented by default...).

Thanks

May 17 '07 #5

P: n/a
On 16 Maj, 19:29, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:
"roberto" <roberto.marchic...@gmail.comwrote in message

news:11**********************@u30g2000hsc.googlegr oups.com...


I'm to deploy a .NET DLL which internally communicates with the WS. I
don't want others to see internal complexity of the web service
classes generated by "Add a Web reference" VS option.
As a WebSerive contains a lot of methods and different types creating
a web proxy class manually is too time consuming.
I tried to edit a class manually, changing the highest-level access
modifiers from public to internal - this way I could use the classes
from within the DLL, exposing only my API. However, this does not work
correctly - "some" of the classes have to be public (e.g. a class
defined as a SoapHeader, but not only) - when changing the access
modifier to internal, I got an error "Method XXX can not be reflected"
when trying to create an instance of the web proxy...
So the question is:
a) where could I find some information what is exactly done by
hte .NET framework during a proxy class lifetime
b) is there any other method (preferably automatic...) to hide as much
information as possible from the proxy class?

Yes. You should write a second web service which abstracts the first. The
second service should try to be less fine-grained. That is, it should usean
SOA metaphor. You should then expose the second service.
--
John Saunders [MVP]

P.S. Of course, the alternative would be to have written the web service
that way to begin with, but if that's not an option, then a "proxy" service
is one way to fix the original without touching the code.- Ukryj cytowanytekst -

- Pokaż cytowany tekst -
(sorry if the similar message is already posted, but I don't see it on
the list since "successful" posting 3 hours ago...)

Web Service API is a minimal one, there is nothing to refactor. What I
want is to hide complexities of the proxy from third-party
applications using my DLL (not a WS).
Example: I'm exposing a .NET DLL with method UpdateLocalCache(); it
transparently call some methods from the proxy:
GetFileList() x1
GetFileByName() x N
In this example I don't want the DLL's users to see GetFilexxx methods
(and all proxy additional details, e.g. timeouts, credentails etc.).

Don't get me wrong - I know the WS methods can be used either directly
from user generated proxies or from the web browser... I just don't
want to answer questions/problems like "how should I call the
method...." - and this will come, as developers tend to use
Intellisense withour bothering about documentation (btw, another issue
with the proxy class - it's not documented by default...).

Thanks

May 17 '07 #6

P: n/a
"roberto" <ro****************@gmail.comwrote in message
news:11*********************@k79g2000hse.googlegro ups.com...
The question is not about server-side methods - they are optimised for
web access. The problem is that a client proxy DLL is to be used in
third-party application, so I'd like to hide its methods to not
confuse people when they try to use Intellisense.

The simpliest example: the web service gives a list of available files
and allows to download them one by one (e.g. GetFilesInfo,
GetFileByName). What I want to expose to DLL's clients is
RefreshLocalCache method, which will internally call the
aforementioned and take care of error handling etc. So - in this case
- I really don't want my Web Proxy class to be exposed...

As I said, nothing wrong WILL happen if somebody calls the WS either
directly or from the proxy; but by exposing too much I'll have to
respond to questions concerning the internal (from my POV) method
usage - who reads the documentation? developers use Intellisense....
(that's another argument against - web proxy methods don't have any
documentation by default)
Roberto, the point I was trying to make is that if you feel the need to
simplify the proxy classes, then you should consider simplifying the web
service. In particular, I would suggest simplifying it to more closely align
with the ways your clients will be using the service. For instance, the
simplified service would have the RefreshLocalCache operation in it.
--
John Saunders [MVP]
May 17 '07 #7

P: n/a
On 17 mayo, 19:04, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:
"roberto" <roberto.marchic...@gmail.comwrote in message

news:11*********************@k79g2000hse.googlegro ups.com...


The question is not about server-side methods - they are optimised for
web access. The problem is that a client proxy DLL is to be used in
third-party application, so I'd like to hide its methods to not
confuse people when they try to use Intellisense.
The simpliest example: the web service gives a list of available files
and allows to download them one by one (e.g. GetFilesInfo,
GetFileByName). What I want to expose to DLL's clients is
RefreshLocalCache method, which will internally call the
aforementioned and take care of error handling etc. So - in this case
- I really don't want my Web Proxy class to be exposed...
As I said, nothing wrong WILL happen if somebody calls the WS either
directly or from the proxy; but by exposing too much I'll have to
respond to questions concerning the internal (from my POV) method
usage - who reads the documentation? developers use Intellisense....
(that's another argument against - web proxy methods don't have any
documentation by default)

Roberto, the point I was trying to make is that if you feel the need to
simplify the proxy classes, then you should consider simplifying the web
service. In particular, I would suggest simplifying it to more closely align
with the ways your clients will be using the service. For instance, the
simplified service would have the RefreshLocalCache operation in it.
--
John Saunders [MVP]- Ocultar texto de la cita -

- Mostrar texto de la cita -
I have exactly the same problem as Roberto, and in my case I am not
the developer of the WebService, so I can not adapt it to my needs.
I would like to provide a simpler interface from my WS client DLL,
hiding most of the methods and types which are not needed for my DLL
clients.

I tried declaring the WS class as friend, but it didn't work. Any help
would be apreciated.

Thanks

May 22 '07 #8

P: n/a
<mi******@gmail.comwrote in message
news:11**********************@x18g2000prd.googlegr oups.com...
On 17 mayo, 19:04, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:
>"roberto" <roberto.marchic...@gmail.comwrote in message

news:11*********************@k79g2000hse.googlegr oups.com...


The question is not about server-side methods - they are optimised for
web access. The problem is that a client proxy DLL is to be used in
third-party application, so I'd like to hide its methods to not
confuse people when they try to use Intellisense.
The simpliest example: the web service gives a list of available files
and allows to download them one by one (e.g. GetFilesInfo,
GetFileByName). What I want to expose to DLL's clients is
RefreshLocalCache method, which will internally call the
aforementioned and take care of error handling etc. So - in this case
- I really don't want my Web Proxy class to be exposed...
As I said, nothing wrong WILL happen if somebody calls the WS either
directly or from the proxy; but by exposing too much I'll have to
respond to questions concerning the internal (from my POV) method
usage - who reads the documentation? developers use Intellisense....
(that's another argument against - web proxy methods don't have any
documentation by default)

Roberto, the point I was trying to make is that if you feel the need to
simplify the proxy classes, then you should consider simplifying the web
service. In particular, I would suggest simplifying it to more closely
align
with the ways your clients will be using the service. For instance, the
simplified service would have the RefreshLocalCache operation in it.
--
John Saunders [MVP]- Ocultar texto de la cita -

- Mostrar texto de la cita -

I have exactly the same problem as Roberto, and in my case I am not
the developer of the WebService, so I can not adapt it to my needs.
I would like to provide a simpler interface from my WS client DLL,
hiding most of the methods and types which are not needed for my DLL
clients.

I tried declaring the WS class as friend, but it didn't work. Any help
would be apreciated.
The suggestion I gave Roberto would be perfect for anyone who cannot modify
the web service - assuming you can create a proxy service of your own.

Another solution, which is so obvious that it's painful for me to admit it,
is to simply write a class library to entirely encapsulate all access to the
web service. Your clients don't even need to know which web service you're
calling. Instead of:

// Get param from somewhere
OriginalService svc = new OriginalService();
int ret1 = svc.Method1(param);
int ret2 = svc.Method2(ret1);
int ret3 = svc.Method3(ret2);
// Do something with ret3

you would have:

// Get param from somewhere
NewProxyClass pxy = new NewProxyClass();
int ret3 = pxy.SimplerMethod(param);
// Do something with ret3
--
John Saunders [MVP]
May 22 '07 #9

P: n/a
On 17 mayo, 19:04, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:
"roberto" <roberto.marchic...@gmail.comwrote in message

news:11*********************@k79g2000hse.googlegro ups.com...


The question is not about server-side methods - they are optimised for
web access. The problem is that a client proxy DLL is to be used in
third-party application, so I'd like to hide its methods to not
confuse people when they try to use Intellisense.
The simpliest example: the web service gives a list of available files
and allows to download them one by one (e.g. GetFilesInfo,
GetFileByName). What I want to expose to DLL's clients is
RefreshLocalCache method, which will internally call the
aforementioned and take care of error handling etc. So - in this case
- I really don't want my Web Proxy class to be exposed...
As I said, nothing wrong WILL happen if somebody calls the WS either
directly or from the proxy; but by exposing too much I'll have to
respond to questions concerning the internal (from my POV) method
usage - who reads the documentation? developers use Intellisense....
(that's another argument against - web proxy methods don't have any
documentation by default)

Roberto, the point I was trying to make is that if you feel the need to
simplify the proxy classes, then you should consider simplifying the web
service. In particular, I would suggest simplifying it to more closely align
with the ways your clients will be using the service. For instance, the
simplified service would have the RefreshLocalCache operation in it.
--
John Saunders [MVP]- Ocultar texto de la cita -

- Mostrar texto de la cita -
I have exactly the same problem as Roberto, and in my case I am not
the developer of the WebService, so I can not adapt it to my needs.
I would like to provide a simpler interface from my WS client DLL,
hiding most of the methods and types which are not needed for my DLL
clients.

I tried declaring the WS class as friend, but it didn't work. Any help
would be apreciated.

Thanks

May 22 '07 #10

P: n/a
On 17 mayo, 19:04, "John Saunders [MVP]" <john.saunders at
trizetto.comwrote:
"roberto" <roberto.marchic...@gmail.comwrote in message

news:11*********************@k79g2000hse.googlegro ups.com...


The question is not about server-side methods - they are optimised for
web access. The problem is that a client proxy DLL is to be used in
third-party application, so I'd like to hide its methods to not
confuse people when they try to use Intellisense.
The simpliest example: the web service gives a list of available files
and allows to download them one by one (e.g. GetFilesInfo,
GetFileByName). What I want to expose to DLL's clients is
RefreshLocalCache method, which will internally call the
aforementioned and take care of error handling etc. So - in this case
- I really don't want my Web Proxy class to be exposed...
As I said, nothing wrong WILL happen if somebody calls the WS either
directly or from the proxy; but by exposing too much I'll have to
respond to questions concerning the internal (from my POV) method
usage - who reads the documentation? developers use Intellisense....
(that's another argument against - web proxy methods don't have any
documentation by default)

Roberto, the point I was trying to make is that if you feel the need to
simplify the proxy classes, then you should consider simplifying the web
service. In particular, I would suggest simplifying it to more closely align
with the ways your clients will be using the service. For instance, the
simplified service would have the RefreshLocalCache operation in it.
--
John Saunders [MVP]- Ocultar texto de la cita -

- Mostrar texto de la cita -
I have exactly the same problem as Roberto, and in my case I am not
the developer of the WebService, so I can not adapt it to my needs.
I would like to provide a simpler interface from my WS client DLL,
hiding most of the methods and types which are not needed for my DLL
clients.

I tried declaring the WS class as friend, but it didn't work. Any help
would be apreciated.

Thanks

May 22 '07 #11

This discussion thread is closed

Replies have been disabled for this discussion.