Re: Implementing a common SOAP Header across multiple Web Service Pages

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.com> wrote in message
news:%23tMwssIUHHA.2256@xxxxxxxxxxxxxxxxxxxxxxx
"Joseph Geretz" <jgeretz@xxxxxxxxxx> wrote in message
news:%23t%23G9SIUHHA.1000@xxxxxxxxxxxxxxxxxxxxxxx
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 -






.

Relevant Pages

  • Re: returning strongly typed dataset from web service
    ... When you reference a web service, a proxy class for the web service is ... If the client will be receiving a strongly-typed DataSet, ...
    (microsoft.public.dotnet.framework.aspnet.webservices)
  • Re: Pass by reference to a WebService
    ... When you pass a variable by reference to a web service, the client ... Of course, if you change the value again on the local machine, the web ...
    (microsoft.public.dotnet.framework.webservices)
  • Re: passing custom classes or stucture as arguments
    ... As soon as you reference the web ... The WSDL tool is used to generate a proxy class. ... Considerations for Custom Web Service Client Proxy Classes here ...
    (microsoft.public.dotnet.framework.aspnet.webservices)
  • Re: returning strongly typed dataset from web service
    ... When you reference a web service, a proxy class for the web service is ... If the client will be receiving a strongly-typed DataSet, ... Of course proxies are created for the WebMethod return types. ...
    (microsoft.public.dotnet.framework.aspnet.webservices)
  • Re: how to use asynchronous calls in asmx
    ... I'm still not sure to fully understand what you expect from this scheme. ... you could just display client side that processing has started and then ... call the web service once. ... My client calls my asmx webservice --here i need to send a message ...
    (microsoft.public.dotnet.framework.aspnet)