The API



  • Ok, thats not an ominous title, but it is perfect for this monstrosity. Building an API for a service or set of them should be really simple, or not. The backend is based on a set of services using .net remoting. We use c# and are stuck with it. Using .net remoting is NOT SOA despite what anyone says. We have an API the basically allows control over there service in various way, pretty standard stuff. The interface is a c++ library that connects to a web service through SOAP. This web service then connects to a service through .net remoting which uses remoting itself to connect to various parts of our system to do something useful. What doesn't make sense is why we need a web service and a .net remoting service in the middle of the stack just to get this to work. One is probably needed, but I cant help get the feeling its overly convoluted somewhere. There is also a certain database that is on a similar level of insane to some of the designs on this forum.



  • @Tachyon said:

    ...Wall of text...


    Please clarify...



  • Is the web service being called from the local machine? Because I seem to recall working on a project where the original developer made the entire DAL use web services, despite the DAL and the rest of the program running on the same machine...



  • @ekolis said:

    Is the web service being called from the local machine? Because I seem to recall working on a project where the original developer made the entire DAL use web services, despite the DAL and the rest of the program running on the same machine...

    At least that way they can be separated out later. Just remember to change the connector from 127.0.0.1.

    (many systems use client/server architecture, assuming that different layers may not reside on the same platform.)



  • @swayde said:

    @Tachyon said:
    ...Wall of text...

    Please clarify...
    Just pretend it's something like this:

    They have C# which calls a C++ libary which calls a SOAP WS which calls a .Net remoting component which does something.

    Close enough, anyway.



  • @Sutherlands said:

    @swayde said:

    @Tachyon said:
    ...Wall of text...


    Please clarify...
    Just pretend it's something like this:

    They have C# which calls a C++ libary which calls a SOAP WS which calls a .Net remoting component which does something.

    Close enough, anyway.

     More like C++ -> SOAP -> Web Service -> .Net remoting -> middle-man service -> .Net remoting -> various other services which do real work (-> .Net remoting? -> DAL -> db)

    i.e. the WTF that the OP is trying to expose is why have the middle-man/men when you could just connect the c++ library or the Web Service directly to the various services.



  • @airdrik said:

    i.e. the WTF that the OP is trying to expose is why have the middle-man/men when you could just connect the c++ library or the Web Service directly to the various services.

     

    Because that doesn't scale well. Salary scale I mean.

     


Log in to reply