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

Implementing a common SOAP Header across multiple Web Service Pages

P: n/a
I have the following class which I am serializing and passing back and forth
between my Web Service application and the client.

public class Token : SoapHeader
{
public string SID;
public string UID;
public string PWD;
}

This is working nicely. However, I'd like to elaborate on my WS application
by splitting my application up into several different pages. For example,
one page will handle Login / Logout (and other session lifecycle) methods,
one page will handle document retrieval methods, one page will handle
prescription methods, etc, etc.

I think that I have to go this route so that I can have multiple developers
working concurrently on different areas of the application without
contending for the same ASMX page. Hmm, now that I'm thinking about this,
perhaps this can be achieved via partial classes? This might be a better
solution so that ultimately, the client would only need to bind to a single
Web Service page, rather than to a dozen or so separate Web Service pages
representing the various functional areas of my application. So here's an
ancillary question; What is your recommendation for partitioning a Web
Service application into areas of functionality? Should these be implemented
as separate pages or as separate partial classes? Are there any performance
or other implications? The difference to these approaches as far as the
client would be concerned would be the instantiation of one large class for
every transaction, as opposed to the instantiation of different smaller
classes for different areas of the application, however in the latter case,
the client would need to bind to multiple Web Service pages. Would any of
this make any difference?

Anyway, let's say I were to proceed to develop separate ASMX pages. How and
where would I define this class so that it would be available to all pages
on the server and to the client on the workstation as well? Would I need to
define this in a separate Assembly (i.e. DLL Utility Library) which would
then need to be deployed to both client and server tiers?

Thanks for your advice.

- Joseph Geretz -
Feb 14 '07 #1
Share this Question
Share on Google+
6 Replies


P: n/a
"Joseph Geretz" <jg*****@nospam.comwrote in message
news:%2******************@TK2MSFTNGP05.phx.gbl...
>I have the following class which I am serializing and passing back and
forth
between my Web Service application and the client.

public class Token : SoapHeader
{
public string SID;
public string UID;
public string PWD;
}

This is working nicely. However, I'd like to elaborate on my WS
application
by splitting my application up into several different pages. For example,
one page will handle Login / Logout (and other session lifecycle) methods,
one page will handle document retrieval methods, one page will handle
prescription methods, etc, etc.
Joseph,

I think you'll find it easier to not consider these as pages. They're not,
really, and they don't need to correspond to pages in a web site.
I think that I have to go this route so that I can have multiple
developers
working concurrently on different areas of the application without
contending for the same ASMX page. Hmm, now that I'm thinking about this,
perhaps this can be achieved via partial classes? This might be a better
solution so that ultimately, the client would only need to bind to a
single
Web Service page, rather than to a dozen or so separate Web Service pages
representing the various functional areas of my application. So here's an
ancillary question; What is your recommendation for partitioning a Web
Service application into areas of functionality? Should these be
implemented
as separate pages or as separate partial classes? Are there any
performance
or other implications? The difference to these approaches as far as the
client would be concerned would be the instantiation of one large class
for every transaction, as opposed to the instantiation of different
smaller classes for different areas of the application, however in the
latter case, the client would need to bind to multiple Web Service pages.
Would any of this make any difference?
First of all, you shouldn't be thinking about implementation at this stage
of your design. Don't worry about partial classes, versus whatever. Worry
about the interface that the clients will use.

Now, it's not going to matter in terms of performance whether you have a
single .asmx file (that is, a single [WebService]) with a lot of
[WebMethods], or multiple [WebService] classes. The proxy classes are very
lightweight and store little, if any, instance data. The differences will
have to do with how the client wants to use the service. For instance, is
the client likely to use many different parts of your system within a given
session? If so, then that suggests the client would be better off
instantiating a single class and passing the reference throughout the
application (possibly as an instance member), rather than having to
instantiate a class when they're in one part of the application, then having
to instantiate another in a different part of the application.

Frankly, if this is the first web service you're implementing, I'd keep it
simple - a single .asmx file.

As to multiple developers, keep in mind that the .asmx files don't need to
contain your implementation. In fact, they probably should not contain your
implementation. Instead, each web method should instantiate one or more
implementation classes and should delegate the operation to them. I
personally like to treat the web service as a Facade in front of my
application. My web methods each instantiate a class specific to that
method, then delegate to that instance.

Of course, related "service layer" classes share an inheritance hierarchy,
so common code is shared in that way. For instance, all of my service layer
classes which require that the user be logged in all inherit from a base
SessionServiceLayer class, which knows how to validate an authentication
token.

In this way, you can easily change how functions are arranged at some later
date. For instance, you may find that you have clients who should never even
know about some part of your application. You can easily create a .ASMX file
which only contains those methods. This will still be very little duplicated
code, since the web methods will be little more than:

[WebMethod]
public ReturnType OperationOne(int a, string b, ...)
{
OperationOneServiceLayer service = new OperationOneServiceLayer(a, b,
....);
return service.Execute();
}
As to your original question, simply put the soap header class in a separate
file. As a public class, it can be used by any class that needs it. Each
..ASMX file will have to have its own public instance of that header, but so
what?

John

Anyway, let's say I were to proceed to develop separate ASMX pages. How
and
where would I define this class so that it would be available to all pages
on the server and to the client on the workstation as well? Would I need
to
define this in a separate Assembly (i.e. DLL Utility Library) which would
then need to be deployed to both client and server tiers?

Thanks for your advice.

- Joseph Geretz -


Feb 14 '07 #2

P: n/a
Hi John,

Actually, I strongly favor the single ASMX page application model, as you
suggest. I've noted of course, that the Web references (i.e. client proxy
classes) are created to bind to a particular page, rather than to a site.
It's cumbersome therefore, to set a client up to reference multiple Web
Service pages, especially in a development environment where pages are
constantly changing and multiple Web references will thus need updating on
an ongoing basis. (It would be interesting if we could bind to a site and
have a bunch of proxies created for each page/class within the namespace of
the selected site. For example, it would be nice to bind a single
WebReference to MyWebApp and then have access to MyWebApp.Session,
MyWebApp.Documents, MyWebAppp.Rx where the site hosts Session.asmx,
Documents.asmx, Rx.asmx, etc. In this way, the Web Service site would
closely conform to the paradigm of a classlLibrary - sort of a remotely
deployed class library. Maybe VS 2010...? )

Your point about leaving the ASMX page as lean as possible and acting just
as a gateway to the server application classes is interesting. I'd like to
explore this a bit. I've worked with n-tier application architectures in the
past (prior to .NET) which utilized an asp page running under IIS as the
application gateway (i.e. facade). For this type of environment, I felt
strongly, as do you, that the asp script should *not* contain any
significant processing logic, but should simply act as the medium for
instantiating the Server application object (ActiveX) and all business
processing took place inside our ActiveX classes. In this case, the choice
was driven by the fact that the development and debugging environments for
VB6 were so far ahead of the comparable environments for asp VBScripting
that I wanted the bulk of the application implemented as VB6, rather than as
VBScript.

However, I don't see a significant difference at all between implementing
application processing as a Web Service project (asmx) vs implenting this in
a Class Library project (dll). In fact, the Web Service project generates a
DLL and by the way, all public Web Service methods in the DLL are accessible
directly via a reference to the DLL without using Web Service protocols at
all. So while I agree with you that some methods will be of sufficient
complexity to warrant the creation of specific classes in order to
encapsulate their processing, I can also see that certain functions might be
simple enough to encode their processing directly into the ASMX page.

This being the case, I would very much like to be able to physically
partition the ASMX page into multiple physical files (partial classes) to
minimize Source Control contention for different developers working on
different areas of the application. I am assuming that a Web Service class
can be partitioned into partial classes with no problem?

I am interesting to hear your thoughts on these issues. Thanks for your
advice,

- Joseph Geretz -

"John Saunders" <john.saunders at trizetto.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
"Joseph Geretz" <jg*****@nospam.comwrote in message
news:%2******************@TK2MSFTNGP05.phx.gbl...
>>I have the following class which I am serializing and passing back and
forth
between my Web Service application and the client.

public class Token : SoapHeader
{
public string SID;
public string UID;
public string PWD;
}

This is working nicely. However, I'd like to elaborate on my WS
application
by splitting my application up into several different pages. For example,
one page will handle Login / Logout (and other session lifecycle)
methods, one page will handle document retrieval methods, one page will
handle prescription methods, etc, etc.

Joseph,

I think you'll find it easier to not consider these as pages. They're not,
really, and they don't need to correspond to pages in a web site.
>I think that I have to go this route so that I can have multiple
developers
working concurrently on different areas of the application without
contending for the same ASMX page. Hmm, now that I'm thinking about this,
perhaps this can be achieved via partial classes? This might be a better
solution so that ultimately, the client would only need to bind to a
single
Web Service page, rather than to a dozen or so separate Web Service pages
representing the various functional areas of my application. So here's an
ancillary question; What is your recommendation for partitioning a Web
Service application into areas of functionality? Should these be
implemented
as separate pages or as separate partial classes? Are there any
performance
or other implications? The difference to these approaches as far as the
client would be concerned would be the instantiation of one large class
for every transaction, as opposed to the instantiation of different
smaller classes for different areas of the application, however in the
latter case, the client would need to bind to multiple Web Service pages.
Would any of this make any difference?

First of all, you shouldn't be thinking about implementation at this stage
of your design. Don't worry about partial classes, versus whatever. Worry
about the interface that the clients will use.

Now, it's not going to matter in terms of performance whether you have a
single .asmx file (that is, a single [WebService]) with a lot of
[WebMethods], or multiple [WebService] classes. The proxy classes are very
lightweight and store little, if any, instance data. The differences will
have to do with how the client wants to use the service. For instance, is
the client likely to use many different parts of your system within a
given session? If so, then that suggests the client would be better off
instantiating a single class and passing the reference throughout the
application (possibly as an instance member), rather than having to
instantiate a class when they're in one part of the application, then
having to instantiate another in a different part of the application.

Frankly, if this is the first web service you're implementing, I'd keep
it simple - a single .asmx file.

As to multiple developers, keep in mind that the .asmx files don't need to
contain your implementation. In fact, they probably should not contain
your implementation. Instead, each web method should instantiate one or
more implementation classes and should delegate the operation to them. I
personally like to treat the web service as a Facade in front of my
application. My web methods each instantiate a class specific to that
method, then delegate to that instance.

Of course, related "service layer" classes share an inheritance hierarchy,
so common code is shared in that way. For instance, all of my service
layer classes which require that the user be logged in all inherit from a
base SessionServiceLayer class, which knows how to validate an
authentication token.

In this way, you can easily change how functions are arranged at some
later date. For instance, you may find that you have clients who should
never even know about some part of your application. You can easily create
a .ASMX file which only contains those methods. This will still be very
little duplicated code, since the web methods will be little more than:

[WebMethod]
public ReturnType OperationOne(int a, string b, ...)
{
OperationOneServiceLayer service = new OperationOneServiceLayer(a, b,
...);
return service.Execute();
}
As to your original question, simply put the soap header class in a
separate file. As a public class, it can be used by any class that needs
it. Each .ASMX file will have to have its own public instance of that
header, but so what?

John

>Anyway, let's say I were to proceed to develop separate ASMX pages. How
and
where would I define this class so that it would be available to all
pages
on the server and to the client on the workstation as well? Would I need
to
define this in a separate Assembly (i.e. DLL Utility Library) which would
then need to be deployed to both client and server tiers?

Thanks for your advice.

- Joseph Geretz -



Feb 15 '07 #3

P: n/a
"Joseph Geretz" <jg*****@nospam.comwrote in message
news:OF**************@TK2MSFTNGP02.phx.gbl...
Hi John,

Actually, I strongly favor the single ASMX page application model, as you
suggest. I've noted of course, that the Web references (i.e. client proxy
classes) are created to bind to a particular page,
Joseph, you're the only person I've ever heard refer to ASMX files as pages.

....
However, I don't see a significant difference at all between implementing
application processing as a Web Service project (asmx) vs implenting this
in a Class Library project (dll).

I didn't say that the service classes should be in a separate project. They
can be in the same project, which is where they are in my web service.

John
Feb 15 '07 #4

P: n/a
I didn't say that the service classes should be in a separate project.
They can be in the same project, which is where they are in my web
service.
Certainly. But my original point, and question still remains. Since there's
no fundamental difference between ServerApp.asmx.cs and MyBusinessClass.cs
(whether or not this latter class is within the same project) what is the
compelling reason for eschewing implementation altogether from within
ServerApp.asmx.cs? Obviously, certain complex operations will be implemented
by classes which are designed to encapsulate these operations, however what
would be wrong with implementing simpler functions, or top level algorithms
directly into the ServerApp.asmx.cs class itself? Restricting Web Service
methods to contain *only* a method call to a business class containing the
actual implementation seems like a layer of indirection, but I don't see
what is acheived by this layer of indirection. Am I missing something? What
is the benefit to this pattern?

BTW, the segmentation of the Web Service class into partial classes is
working out really nicely. Whether or not this class will contain
implementation code, application developers will need to introduce methods
for whatever features they develop. Having this class partitioned by
application feature is a terrific way of keeping this under source control,
without creating a bottleneck to a single file.

- Joseph Geretz -

"John Saunders" <john.saunders at trizetto.comwrote in message
news:eZ**************@TK2MSFTNGP06.phx.gbl...
"Joseph Geretz" <jg*****@nospam.comwrote in message
news:OF**************@TK2MSFTNGP02.phx.gbl...
>Hi John,

Actually, I strongly favor the single ASMX page application model, as you
suggest. I've noted of course, that the Web references (i.e. client proxy
classes) are created to bind to a particular page,

Joseph, you're the only person I've ever heard refer to ASMX files as
pages.

...
>However, I don't see a significant difference at all between implementing
application processing as a Web Service project (asmx) vs implenting this
in a Class Library project (dll).


I didn't say that the service classes should be in a separate project.
They can be in the same project, which is where they are in my web
service.

John


Feb 15 '07 #5

P: n/a
"Joseph Geretz" <jg*****@nospam.comwrote in message
news:OQ**************@TK2MSFTNGP05.phx.gbl...
>I didn't say that the service classes should be in a separate project.
They can be in the same project, which is where they are in my web
service.

Certainly. But my original point, and question still remains. Since
there's no fundamental difference between ServerApp.asmx.cs and
MyBusinessClass.cs (whether or not this latter class is within the same
project) what is the compelling reason for eschewing implementation
altogether from within ServerApp.asmx.cs? Obviously, certain complex
operations will be implemented by classes which are designed to
encapsulate these operations, however what would be wrong with
implementing simpler functions, or top level algorithms directly into the
ServerApp.asmx.cs class itself? Restricting Web Service methods to contain
*only* a method call to a business class containing the actual
implementation seems like a layer of indirection, but I don't see what is
acheived by this layer of indirection. Am I missing something? What is the
benefit to this pattern?
It's one of the standard benefits of the Facade design pattern: you can use
the same subsystem classes with different facades. For instance, the same
classes could be used by a Windows Forms application, an ASP.NET web site,
by a Windows Service or by a different web service entirely.

There is also the argument about separation of concerns. Only your .ASMX.CS
files will have to worry about being a web service. The classes hidden by
the facade will simply worry about doing their own thing.

Note, I'm not suggesting some strict "n-tier" separation. I'm not saying
that those hidden classes would be your business object layer. I'm just
saying that they should be out of the "web service" layer.

This also gives you the improved ability for multiple develoeprs to work on
the project, as they can each be working on a separate service layer class.

John
Feb 15 '07 #6

P: n/a
Thanks John,
There is also the argument about separation of concerns. Only your
.ASMX.CS files will have to worry about being a web service. The classes
hidden by the facade will simply worry about doing their own thing.
This is a good point. I think that this will be the rule of thumb for our
approach; ASMX.CS code should only take care of those operations which will
be intrinsic to WS access; that is checking for the Token (which travels via
SOAP Header) ensuring that the Session is still valid, etc. Other
application features not related to the WS Application infrastructure should
be implemented, within standard application classes, along the lines of your
recommendation.
This also gives you the improved ability for multiple developers to work
on the project, as they can each be working on a separate service layer
class.
This is true. In addition to this separation along the 'depth' of the
application, the segmentation of the ASMX facade layer into multiple partial
classes provides separation along the 'width' of the application. That is,
this will allow multiple developers to work concurrently on the facade layer
in different application areas without contending for write access to a
single application facade file.

I think that this is going to work out well for us. Thanks for your advice!

- Joseph Geretz -

"John Saunders" <john.saunders at trizetto.comwrote in message
news:%2***************@TK2MSFTNGP03.phx.gbl...
"Joseph Geretz" <jg*****@nospam.comwrote in message
news:OQ**************@TK2MSFTNGP05.phx.gbl...
>>I didn't say that the service classes should be in a separate project.
They can be in the same project, which is where they are in my web
service.

Certainly. But my original point, and question still remains. Since
there's no fundamental difference between ServerApp.asmx.cs and
MyBusinessClass.cs (whether or not this latter class is within the same
project) what is the compelling reason for eschewing implementation
altogether from within ServerApp.asmx.cs? Obviously, certain complex
operations will be implemented by classes which are designed to
encapsulate these operations, however what would be wrong with
implementing simpler functions, or top level algorithms directly into the
ServerApp.asmx.cs class itself? Restricting Web Service methods to
contain *only* a method call to a business class containing the actual
implementation seems like a layer of indirection, but I don't see what is
acheived by this layer of indirection. Am I missing something? What is
the benefit to this pattern?

It's one of the standard benefits of the Facade design pattern: you can
use the same subsystem classes with different facades. For instance, the
same classes could be used by a Windows Forms application, an ASP.NET web
site, by a Windows Service or by a different web service entirely.

There is also the argument about separation of concerns. Only your
.ASMX.CS files will have to worry about being a web service. The classes
hidden by the facade will simply worry about doing their own thing.

Note, I'm not suggesting some strict "n-tier" separation. I'm not saying
that those hidden classes would be your business object layer. I'm just
saying that they should be out of the "web service" layer.

This also gives you the improved ability for multiple develoeprs to work
on the project, as they can each be working on a separate service layer
class.

John


Feb 15 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.