SOAP, middle tier layer or presentation layer?

[Humberto Morales]

When designing an n-tier system that is distributed between multiple
machines, is it best to:
1) develop a COM object to handle all SOAP messages between machines that is
called from an ASP or 2) simple develop ASP classes that another ASP can
call to make SOAP messages?

Now at first glance I say use the second method because of the deployment
issues that method one exposes. Is there any real advantage to have this
done in a dll verses an ASP class?

Finally this leads me to my final question, does SOAP logic belong in the
presentation level or middle tier layer, or maybe both depending on the
situation?

Thoughts?

Humberto

[Randy Charles Morin]

SOAP is definately an upper-tier layer. I think that its a presentation
layer activity and most like yourself agree. Some have incorrectly suggested
that SOAP is a transport and this is simply wrong. On the other hand, SOAP
is XML over HTTP and HTTP is definitely an application layer as per the
Internet-centric model (application, transport, network, data-link,
physical). So the protocol stack in SOAP (on the Internet) will be something
similar to SOAP, HTTP, TCP, IP, Ethernet, cable. This again, like all
Internet-centric applications, is not conforming. But undoubtedly, SOAP is
an upper-tier layer.

The question of whether your ASP should call COM objects or ASP objects
depends on your needs and has little to do with establishing the correct
protocol stack. Don't think of COM as belong to your communication network,
rather COM is an application layer library and COM components are
application layer components. So when your ASP calls your COM object (or ASP
object), then you are simply making programmatic calls within your
application layer.

If you want speed, then no substitute will compare to a COM object written
in C++. If you are a good ASP programmer, then you might benefit from
time-to-market benefits of using something familiar.
--
Randy Charles Morin
Author of Programming Windows Services
http://www.kbcafe.com

Feel free to contact me by private email or messenger
MSN Messenger - morin_randy@hotmail.com
Yahoo Messenger - randymorin@yahoo.com

"Humberto Morales" <HUMBERTO@socal.rr.com> wrote in message
news:3b304724@news.devx.com...
> When designing an n-tier system that is distributed between multiple
> machines, is it best to:
> 1) develop a COM object to handle all SOAP messages between machines that
is
> called from an ASP or 2) simple develop ASP classes that another ASP can
> call to make SOAP messages?
>
> Now at first glance I say use the second method because of the deployment
> issues that method one exposes. Is there any real advantage to have this
> done in a dll verses an ASP class?
>
> Finally this leads me to my final question, does SOAP logic belong in the
> presentation level or middle tier layer, or maybe both depending on the
> situation?
>
> Thoughts?
>
> Humberto
>
>

[Matt Liotta]

Saying SOAP should be in the presentation tier of an N-tier application can
give people the wrong idea. I think it is better to say that SOAP is a
presentation of middle-tier functionality. This means that SOAP and HTML
perform the same role for different audiences; HTML for humans and SOAP for
machines. With this notion in mind it becomes clear that SOAP is just a
wrapper. Wrappers should be in the same tier as what they wrap.

-Matt

"Randy Charles Morin" <rmorin@kbcafe.com> wrote in message
news:3b30c452$1@news.devx.com...
> SOAP is definately an upper-tier layer. I think that its a presentation
> layer activity and most like yourself agree. Some have incorrectly
suggested
> that SOAP is a transport and this is simply wrong. On the other hand, SOAP
> is XML over HTTP and HTTP is definitely an application layer as per the
> Internet-centric model (application, transport, network, data-link,
> physical). So the protocol stack in SOAP (on the Internet) will be
something
> similar to SOAP, HTTP, TCP, IP, Ethernet, cable. This again, like all
> Internet-centric applications, is not conforming. But undoubtedly, SOAP is
> an upper-tier layer.
>
> The question of whether your ASP should call COM objects or ASP objects
> depends on your needs and has little to do with establishing the correct
> protocol stack. Don't think of COM as belong to your communication
network,
> rather COM is an application layer library and COM components are
> application layer components. So when your ASP calls your COM object (or
ASP
> object), then you are simply making programmatic calls within your
> application layer.
>
> If you want speed, then no substitute will compare to a COM object written
> in C++. If you are a good ASP programmer, then you might benefit from
> time-to-market benefits of using something familiar.
> --
> Randy Charles Morin
> Author of Programming Windows Services
> http://www.kbcafe.com
>
> Feel free to contact me by private email or messenger
> MSN Messenger - morin_randy@hotmail.com
> Yahoo Messenger - randymorin@yahoo.com
>
> "Humberto Morales" <HUMBERTO@socal.rr.com> wrote in message
> news:3b304724@news.devx.com...
> > When designing an n-tier system that is distributed between multiple
> > machines, is it best to:
> > 1) develop a COM object to handle all SOAP messages between machines
that
> is
> > called from an ASP or 2) simple develop ASP classes that another ASP can
> > call to make SOAP messages?
> >
> > Now at first glance I say use the second method because of the
deployment
> > issues that method one exposes. Is there any real advantage to have this
> > done in a dll verses an ASP class?
> >
> > Finally this leads me to my final question, does SOAP logic belong in
the
> > presentation level or middle tier layer, or maybe both depending on the
> > situation?
> >
> > Thoughts?
> >
> > Humberto
> >
> >
>
>

[Humberto Morales]

Thanks for clearing things up.

"Humberto Morales" <HUMBERTO@socal.rr.com> wrote in message
news:3b304724@news.devx.com...
> When designing an n-tier system that is distributed between multiple
> machines, is it best to:
> 1) develop a COM object to handle all SOAP messages between machines that
is
> called from an ASP or 2) simple develop ASP classes that another ASP can
> call to make SOAP messages?
>
> Now at first glance I say use the second method because of the deployment
> issues that method one exposes. Is there any real advantage to have this
> done in a dll verses an ASP class?
>
> Finally this leads me to my final question, does SOAP logic belong in the
> presentation level or middle tier layer, or maybe both depending on the
> situation?
>
> Thoughts?
>
> Humberto
>
>