encapsulating webservice proxy to hide complexity

[roberto]

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

[John Saunders [MVP]]

"roberto" <ro************ ****@gmail.comw rote in message
news:11******** **************@ u30g2000hsc.goo glegroups.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.

[roberto]

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
RefreshLocalCac he 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

[roberto]

(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 UpdateLocalCach e(); 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

[roberto]

(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 UpdateLocalCach e(); 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

[roberto]

On 16 Maj, 19:29, "John Saunders [MVP]" <john.saunder s at
trizetto.comwro te:

"roberto" <roberto.marchi [e-mail] rote in message

news:11******** **************@ u30g2000hsc.goo glegroups.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 UpdateLocalCach e(); 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

[John Saunders [MVP]]

"roberto" <ro************ ****@gmail.comw rote in message
news:11******** *************@k 79g2000hse.goog legroups.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
RefreshLocalCac he 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 RefreshLocalCac he operation in it.
--
John Saunders [MVP]

[mifsilvi]

On 17 mayo, 19:04, "John Saunders [MVP]" <john.saunder s at
trizetto.comwro te:

"roberto" <roberto.marchi [e-mail] rote in message

news:11******** *************@k 79g2000hse.goog legroups.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
RefreshLocalCac he 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 RefreshLocalCac he 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

[John Saunders [MVP]]

<mi******@gmail .comwrote in message
news:11******** **************@ x18g2000prd.goo glegroups.com.. .

On 17 mayo, 19:04, "John Saunders [MVP]" <john.saunder s at
trizetto.comwro te:

>"roberto" <roberto.marchi [e-mail] rote in message

news:11******* **************@ k79g2000hse.goo glegroups.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
RefreshLocalCac he 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 RefreshLocalCac he 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(par am);
int ret2 = svc.Method2(ret 1);
int ret3 = svc.Method3(ret 2);
// Do something with ret3

you would have:

// Get param from somewhere
NewProxyClass pxy = new NewProxyClass() ;
int ret3 = pxy.SimplerMeth od(param);
// Do something with ret3
--
John Saunders [MVP]

[mifsilvi]

On 17 mayo, 19:04, "John Saunders [MVP]" <john.saunder s at
trizetto.comwro te:

"roberto" <roberto.marchi [e-mail] rote in message

news:11******** *************@k 79g2000hse.goog legroups.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
RefreshLocalCac he 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 RefreshLocalCac he 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