473,562 Members | 3,059 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Implementing a common SOAP Header across multiple Web Service Pages

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
6 3972
"Joseph Geretz" <jg*****@nospam .comwrote in message
news:%2******** **********@TK2M SFTNGP05.phx.gb l...
>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
SessionServiceL ayer 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(in t a, string b, ...)
{
OperationOneSer viceLayer service = new OperationOneSer viceLayer(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
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.Sessio n,
MyWebApp.Docume nts, 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.saunder s at trizetto.comwro te in message
news:%2******** ********@TK2MSF TNGP02.phx.gbl. ..
"Joseph Geretz" <jg*****@nospam .comwrote in message
news:%2******** **********@TK2M SFTNGP05.phx.gb l...
>>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 SessionServiceL ayer 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(in t a, string b, ...)
{
OperationOneSer viceLayer service = new OperationOneSer viceLayer(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
"Joseph Geretz" <jg*****@nospam .comwrote in message
news:OF******** ******@TK2MSFTN GP02.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
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.saunder s at trizetto.comwro te in message
news:eZ******** ******@TK2MSFTN GP06.phx.gbl...
"Joseph Geretz" <jg*****@nospam .comwrote in message
news:OF******** ******@TK2MSFTN GP02.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
"Joseph Geretz" <jg*****@nospam .comwrote in message
news:OQ******** ******@TK2MSFTN GP05.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
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.saunder s at trizetto.comwro te in message
news:%2******** *******@TK2MSFT NGP03.phx.gbl.. .
"Joseph Geretz" <jg*****@nospam .comwrote in message
news:OQ******** ******@TK2MSFTN GP05.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
MyBusinessClas s.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
implementati on 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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
7870
by: Mark | last post by:
i have a very simple web servive Imports System.Web.Services <System.Web.Services.WebService(Namespace:="urn:Example1")> _ Public Class Example1 Inherits System.Web.Services.WebService
0
2283
by: Michael Jackson | last post by:
I have attempted to mark up a service and it's methods so that it doesn't require the SOAPAction HTTP header to resolve the methods being called, this is done from first element in <SOAP-ENV:Body> and the request and responses are not suffixed with Request and Response. Is there some more I could do with the attributes on the class that...
5
8229
by: jb | last post by:
*Please* help --- I'm tearing my hair out. I want to use sessionstate in a webservice, accessed from a client, written in script (JScript, InfoPath). I have written my webservice (C# .NET). I have marked the method(s) with EnableSession=true. I have read everything there is to read! I am told that to reuse session, my client needs to...
0
4657
by: Daniel Thune, MCSE | last post by:
I am having a problem with formatting a SOAP Header in a .Net client. The client calls a Java Axis 1.1 based web service. In order to authenticate the caller, the web service call is intercepted by another web service that validates a security token in the header. I have pasted my current SOAP message that my code sends as captured from a...
5
4146
by: vthakur | last post by:
Hello: I have a Axis Web Service that sets the sessionid in the SOAP header for persisting the session. The client is a .Net client that processes the header as an Unknown Header. It sets the session id received from the Service request on subsequent requests to the service. However the Axis Web service does not process the SOAP header...
6
42995
by: Peter van der veen | last post by:
Hi I have the following problem. I'm calling a webservice from within a VB.net 2005 Windows program. For this i got a WSDL file and loaded that in VB. Until now i just call the webservice and everything works OK. Now i need to add an extra attribute/header element to the SOAP header before i contact the webservice.
5
4121
by: =?Utf-8?B?SmltbWVy?= | last post by:
Hello, I've been trying to create a WCF SOAP Router Service that can forward not just the message body but also any security headers set by the originator of the message. The destination service I'm routing messages to uses WSHttpBinding, SSL with UserName/Password client credentials. Using guidance from the Technology samples I can create...
3
16296
by: Enda Manni | last post by:
Hi, I have a gSoap Web Service written using C++, it uses SOAP username and password authentication. I also have a C# form client consuming the web service, all this was working fine until I added the authentication on the server, now I can not get the client to authenticate. Can someone tell me how to add authentication info to the...
0
2228
by: vigneshrao | last post by:
Hi, I have been working on a script that loops through multiple records and sends data (one record per call) to a WS. I am supposed to make a new call for each record before sending the data. The problem I have is the first record gets processed fine where as the second record always; reason being the EAI expects it to be a seperate call...
0
7576
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language...
0
8095
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that...
1
7625
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
0
6219
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
1
5476
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes...
0
5193
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert...
0
3621
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in...
0
3606
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
0
901
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.