Just tell me why ? so confuse...

Discussion in 'ASP .Net Web Services' started by serge calderara, Nov 9, 2005.

  1. 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
    serge calderara, Nov 9, 2005
    #1
    1. Advertising

  2. serge calderara

    Scott M. Guest

    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" <> wrote in
    message news:...
    > 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., Nov 9, 2005
    #2
    1. Advertising

  3. 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

    "Scott M." wrote:

    > 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" <> wrote in
    > message news:...
    > > 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
    > >

    >
    >
    >
    serge calderara, Nov 10, 2005
    #3
  4. serge calderara

    Peter Kelcey Guest

    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
    Peter Kelcey, Nov 10, 2005
    #4
  5. serge calderara

    Scott M. Guest

    > 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.

    >
    > thnaks for your info
    >
    > regards
    > serge
    >
    > "Scott M." wrote:
    >
    >> 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" <> wrote in
    >> message news:...
    >> > 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., Nov 10, 2005
    #5
  6. serge calderara

    Scott M. Guest

    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

    "Peter Kelcey" <> wrote in message
    news:...
    > 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., Nov 10, 2005
    #6
  7. 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

    "Peter Kelcey" wrote:

    > 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
    >
    >
    serge calderara, Nov 11, 2005
    #7
  8. serge calderara

    Scott M. Guest

    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



    "serge calderara" <> wrote in
    message news:...
    > 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
    >
    > "Peter Kelcey" wrote:
    >
    >> 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., Nov 11, 2005
    #8
  9. serge calderara

    Peter Kelcey Guest

    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
    Peter Kelcey, Nov 11, 2005
    #9
  10. serge calderara

    Scott M. Guest

    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.


    "Peter Kelcey" <> wrote in message
    news:...
    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., Nov 11, 2005
    #10
  11. 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

    "Scott M." wrote:

    > 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
    >
    >
    >
    > "serge calderara" <> wrote in
    > message news:...
    > > 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
    > >
    > > "Peter Kelcey" wrote:
    > >
    > >> 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
    > >>
    > >>

    >
    >
    >
    serge calderara, Nov 12, 2005
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Bruce .J Sam
    Replies:
    2
    Views:
    581
    Bruce .J Sam
    Apr 3, 2005
  2. iceColdFire
    Replies:
    3
    Views:
    4,409
    Ioannis Vranos
    May 24, 2005
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,842
    Smokey Grindel
    Dec 2, 2006
  4. A little confuse

    , Nov 19, 2006, in forum: Python
    Replies:
    0
    Views:
    310
  5. manish sahu
    Replies:
    3
    Views:
    1,003
Loading...

Share This Page