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 - 6 3944
"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 -
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 -
"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
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
"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
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
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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
|
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>...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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....
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 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 former...
|
by: ryjfgjl |
last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
| |