Just tell me why ? so confuse...

[serge calderara]

Dear all,

I was planning to build a web service component for one of my customer that
will be preliminary use in there company intranet.

This web service will be in charge of sending back data from an SQL server
database base on a user request like for example following webmethod :

- GetLastEntry :
will return last recorded data elements

- GetEntryBetween (Startdate, EndDate° : retrun a range of record between
those dates

base on that I have benn told that using Web service for database access is
a bad, bad idea due to performance and security reason because it is a SOAP
request.

But when I check for instance WebService provides by Amazon to get
information relative to a particular book, I guess tiere web service retrive
data from a database too.

So could anyone cold clearly explain ?

thanks for your help
regards
serge

 

[Scott M.]

Who told you that using a web service to access data was a bad idea? I
don't think that person knows what they are talking about.

Perhaps they meant that a web service class should not "directly" access a
database, but rather it should call another data layer class that gets the
data from the database and passes it back to the web service for the service
to pass back to the calling application.

Using web services to access data on remotes systems is possibly the most
common thing that people use web services for.

-Scott

 

[serge calderara]

Thanks for your reply.

What do you mean by WebService class should not directly access to database ?
Ok here is what I have done:

I have created a WebService project
Then defined in this web service some WebMethod that collects data

Do you mean that inside my web service project I should add a separate
classe that handle database request and then return the data to the webMethod
function?

Or do you mean that I should get a totally separate assembly which is
connected to database and retrun data and then my web srevice class
instanciate that assembly ?

If the second solution is the properway to do, how the web service will know
where the assembly will be located as web service could be install on a
registration server and the assembly on my customer web server ?

thnaks for your info

regards
serge

 

[Peter Kelcey]

Serge,

It is true that web services can sometimes be the wrong technology to
use when accessing data. However, there are other times when they are
the best solution. It depends on what you are trying to achieve with
your solution. I'll try to explain.

Web services and service oriented architectures are often used in the
wrong places by people designing applications. This usually occurs when
people use web services to connect a presentation layer to their
business or data layers within the same application. Web services are
based on "open" and vendor independent technologies such as XML, HTTP
and SOAP. Therefore they offer the best solution for interoperability,
but they do trail far behind other technologies in terms of
performance. Proprietary technologies such as .NET remoting take
advantage of a lot of performance boosts that web services can't.
Therefore, when you have control of the entire application from
presentation layer through to business and data layers, it is usually
recommended to use a vendor specific technology and avoid the large
overhead of web services. For example, if you have a Microsoft windows
form that needs to access Microsoft based business components on
another computer, the recommended solution for connecting the two layer
would probably be to use Microsoft .NET remoting. It will give you much
better performance than web services while still allowing you to easily
connect the two layers.

Where web services really provide a great solution is when you are
integration two systems/layers/applications that you don't have full
control over or that don't share the same technology. In a case such as
this your number one priority is getting the two systems to communicate
properly and performance comes after that.

So what you need to determine is what your requirements are and what
problem you are trying to solve. Since you are trying to build a
solution for you client, I would think that web services are your best
solution. I would guess that the client is in control of their own
technology and that you aren't free to dictate a proprietary
technology such as DCOM or .NET remoting. The problem facing you seems
to be and integration problem and not a performance problem. Unless
there are other requirements that you haven't listed here (such as
service level agreements outlining response times) I would recommend
sticking with your web services based solution.

Hope that helps

Peter Kelcey

 

[Scott M.]

Do you mean that inside my web service project I should add a separate

classe that handle database request and then return the data to the
webMethod
function?
Yes.

Or do you mean that I should get a totally separate assembly which is
connected to database and retrun data and then my web srevice class
instanciate that assembly ?

You certainly could do this if desired.

If the second solution is the properway to do, how the web service will
know
where the assembly will be located as web service could be install on a
registration server and the assembly on my customer web server ?

You would put the data assembly on the same server as the web service
assembly, otherwise you'd need you web service to call another web service.

 

[Scott M.]

Peter,

I have to disagree with your assesment that when you have total control over
the entire application, that a proprietary solution is best. I'm not sure
why you say that "it is usually recommended" to do this and that "the
recommended solution" is to go that way.

In my experience, working for large enterprises, I find just the opposite.
Even though these companies do have total control over the entire
application (intranet applications), they do NOT want to buy into a 100%
proprietary solution to connect the presentation layer to the services
layer. In fact, they (again, in my experience) want to make the
presentation to services connection as non-proprietary and as
platform-independant as possible (web services) to allow them scalability
and flexibility in the future.

Now, on the back end is a different story... Connecting a web service to a
business layer and that business layer to a data layer, is very often done
with 100% proprietary techniques.

IMHO
-Scott

 

[serge calderara]

Thanks peter for your explaination.

IN fact what I am trying to do, is to put in place an Web application that
offer data analysis to my customer.
Lets try to explain again.

We have a certain amout of quality data that are recorded under an SQL
database (Those data can be huge with the time). Base on those data, I need
to think about a simple way for my customer to be able to extract those data
and them perform some analysis on it. Those analysis data can be requested as
quality control documents.

My customer is sellinf telecomunication cables to their customers and their
customer can request quality reports from thier all production of cable.

For that I have I was planning to defnined following layers :
- the Web User Interface layer
- the logic layer
- the data layer

Note that as a first step, this application will run in my custmer Intranet.
But I was thinking that it could be an addition value if the final customer
of my customer could acess his own product quality data.

SO at the end I was thinking to place the database querry management as a
Web Service, then it can distribute data either inside my customer company
intranet or it can be used by my customer's final customers to access their
production report.

In case I plan to do thos database querry as a standard .NET assembly and
later on my customer request me this Web service approach I will have to redo
it again or add an extra interface layer

Then free to my customer's customer to implement this Web Service by their
own tools

What do you think about that approach ?

regards
serge

 

[Scott M.]

It seems that what you are doing is pretty straight-forward.

UI (web pages) that can be deployed on either an intranet or Internet server
depending on what kind of access you want to allow (these pages can easily
be moved at a later time if you want to provide Internet access).

Web Service running on an application server. The actual web service just
acts as a gateway or proxy to the actual business and data classes that will
do the work. The UI web server will have a web reference to this web
service and communicate via this web reference.

Business class(es) and data class(es) running on the same application server
as the web service. The Web Service makes instances of these classes as
determined by the web methods exposed by the service and passes data into
these layers (query data from UI layer) or sends the results of these
operations back the UI layer.

-Scott

 

[Peter Kelcey]

Scott,

I agree completely that vendor independent services are preferred
solutions in large enterprises that are looking to integrate multiple
applications and systems. I would also agree that a quality
architecture in that case would have a presentation layer communicating
with a service façade that calls various business objects. (Just as
you suggested). In these cases, we are willing to live with the
performance hit caused by web services because we are gaining so much
more towards our overall enterprise architecture.

This is where I potentially deviate from the architecture you
suggested. It's my opinion that an application should only have a
services layer if it is going to be integrated with one or more other
systems or you know that you may need to change vendors in the future.
In your post you stated that you had these requirements in your
projects.

Without these requirements I don't believe that a self contained
application should put a services layer between its business components
and it's presentation layer. I also think that service oriented
architectures are often incorrectly incorporated within application
architecture and that a lot of times, service layers only end up
creating a fatter and less responsive solution for no reason. When
looking at a system that doesn't have those requirements, web
services have as many shortfalls as they do benefits. I think that the
loss of any real transaction mechanism, the lack of binary
communications, the lack of any true version control and the increased
performance overhead are significant enough reasons to rule out web
services as a communication mechanism within the internals of a single
application. Therefore, I'd take something like .NET Remoting, RMI
etc in order to get the additional benefits. It's in a case such as
this where I meant that a proprietary solution is preferred and
recommended.

Now I've have worked on solutions that implement a hybrid of these 2
architectures. A presentation layer uses .NET remoting to connect to
business facades. We also had a small number of web services that
exposed a subset of those facades to other applications that needed to
access our data. We get our performance boost, our transaction control
and we get our system interoperability.

It always comes down to it is you need to accomplish and what your
requirements are.

Based on what Serge says he's trying to do. I'd recommend the same
thing you did.

IMHO as well.

Peter

 

[Scott M.]

Hi Pete,

Just a couple of additional thoughts...

Transaction management can certainly be implemented by using the business
layer as the start of the transaction and ensuring that the UI layer doesn't
do any business rule processing.

I think we'd all agree that Web Services (while very flexible and open) do
not perform as well as other, proprietary solutions do, but that is the
price we pay for the open-ness of the architecture. Having said that,
bandwith concerns are not the problem they once were and compression of data
only decreases that concern.

I've appreciated hearing your thoughts on this.

Have a good day.


Scott,

I agree completely that vendor independent services are preferred
solutions in large enterprises that are looking to integrate multiple
applications and systems. I would also agree that a quality
architecture in that case would have a presentation layer communicating
with a service façade that calls various business objects. (Just as
you suggested). In these cases, we are willing to live with the
performance hit caused by web services because we are gaining so much
more towards our overall enterprise architecture.

This is where I potentially deviate from the architecture you
suggested. It's my opinion that an application should only have a
services layer if it is going to be integrated with one or more other
systems or you know that you may need to change vendors in the future.
In your post you stated that you had these requirements in your
projects.

Without these requirements I don't believe that a self contained
application should put a services layer between its business components
and it's presentation layer. I also think that service oriented
architectures are often incorrectly incorporated within application
architecture and that a lot of times, service layers only end up
creating a fatter and less responsive solution for no reason. When
looking at a system that doesn't have those requirements, web
services have as many shortfalls as they do benefits. I think that the
loss of any real transaction mechanism, the lack of binary
communications, the lack of any true version control and the increased
performance overhead are significant enough reasons to rule out web
services as a communication mechanism within the internals of a single
application. Therefore, I'd take something like .NET Remoting, RMI
etc in order to get the additional benefits. It's in a case such as
this where I meant that a proprietary solution is preferred and
recommended.

Now I've have worked on solutions that implement a hybrid of these 2
architectures. A presentation layer uses .NET remoting to connect to
business facades. We also had a small number of web services that
exposed a subset of those facades to other applications that needed to
access our data. We get our performance boost, our transaction control
and we get our system interoperability.

It always comes down to it is you need to accomplish and what your
requirements are.

Based on what Serge says he's trying to do. I'd recommend the same
thing you did.

IMHO as well.

Peter

 

[serge calderara]

Thanks to all of you about that interresting discussion on architecture choice.
Web service are so fuzzy sometimes when you discuss with different type of
people.
Some of them use them for a matter of fashion, and some other are more
thinking in the sense do we realy have to.

What make me hesitate using tghem at first is from the fact that I attend a
devolopper forum recently in France and Web service was presented by a
Microsoft guy from belgium (really good presentation I have to say).

One sentence from him was :"Web service appears to be simple, but thats
complicated"

serge