SitePoint Sponsor

User Tag List

Results 1 to 11 of 11
  1. #1
    SitePoint Addict Trent Reimer's Avatar
    Join Date
    Sep 2005
    Location
    Canada
    Posts
    228
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    SOAP for multi-tier?

    Just curious if anyone has used SOAP to create a tiered PHP application?

    I read the book "Multi-Tier Application Programming with PHP" and while it was very straightforward it did raise the "why?" question several times in my head.

    Also, could you hook into a PHP/SOAP web service with Ruby on Rails? Trying to think if there would be a future use there...

  2. #2
    throw me a bone ... now bonefry's Avatar
    Join Date
    Nov 2004
    Location
    Romania
    Posts
    848
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Of course you can connect Ruby and PHP with SOAP. Because it is based on XML. ANd it's a standard.

    But try to stay away from SOAP as long and as hard as you can
    Even in the enterprise world, SOAP is comatose.
    Use REST instead.

  3. #3
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If I recall the whole point of SOAP (Simple Object Application Protocol) is that one service could connect to another server, regardless of the technology.

    So I suppose going by SOAP, any response is XML in nature, so if you have a Ruby service, you should be able to connect to it via the revalant technologies no? Obviously you can't read or write Ruby scripts from PHP, but with PHP you can parse XML, so you should be able to get a response via SOAP from any technology other than what your using.

    If that ain't possible, then what is the -BEEP- point of SOAP huh?

  4. #4
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

  5. #5
    SitePoint Guru
    Join Date
    Dec 2003
    Location
    oz
    Posts
    819
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Trent Reimer
    I read the book "Multi-Tier Application Programming with PHP" and while it was very straightforward it did raise the "why?" question several times in my head.
    When you build an application, you don't know how big it will grow. Heavily used applications need to be able to scale, and that's usually done by increasing the number of servers for the tiers that have the highest load. For example, you might have your database on its own box so that you can minimise the number of connections, and use a web service to call an appliction that holds the connections. This easily reduces the number of connection from hundreds to single digits.

    You could only really do this if you start with a logical layer via using web services, so that when the time comes to scale, you can convert it to a physical layer and all you need to do is call the same web service on another box instead of on localhost.

    Of course, if you have almost no chance of the app requiring that scaling, the extra work isn't necessary. But almost every largely used app that started out small has performance problems because they didn't allow the flexibility to scale for performance.

    Quote Originally Posted by Trent Reimer
    Also, could you hook into a PHP/SOAP web service with Ruby on Rails? Trying to think if there would be a future use there...
    You could, but it wouldn't be a good idea. In general, most people are very proficient at one language at most (and often not even one!). By having different parts of the system in different languages/platforms, you would need a larger skillset of people to maintain the system - and chanced are that development in atleast one of the langeuages would be sub-par.

    Regards,
    Eli

  6. #6
    SitePoint Addict pointbeing's Avatar
    Join Date
    Jun 2004
    Location
    London, UK
    Posts
    227
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    There seem to be two interpretations of what Trent's asking...

    If the question is why you might use SOAP as the protocol over which your tiers communicate, I'm afraid I couldn't recommend that at all. SOAP is slow at the best of times. You simply don't want the overhead of all that XML parsing and an extra HTTP request happening behind the scenes every time your - say - business tier goes to the database. It would suck, and it would violate the 'Keep it Simple' principle quite dramatically.

    On the other hand, building a SOAP interface onto an app is one of the places why you may really feel the benefit of having taken the multi-tiered approach in the first place. Suppose you have a database-driven application with a web interface (a pretty safe bet 'round here!), and the day comes when you need to integrate it with someone else's app. If you can merely swap in the new interface and leave all the business logic and database code untouched, you're half way there already.

    On the subject of SOAP having died at the hands of REST? Looking at our clients and our competitors, that's not what we're seeing at all.

  7. #7
    SitePoint Guru
    Join Date
    Dec 2003
    Location
    oz
    Posts
    819
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by pointbeing
    There seem to be two interpretations of what Trent's asking...
    I assumed he was asking about soap as a way to access different tiers in an application. It seemed logical to me, but I could be wrong.

    Quote Originally Posted by pointbeing
    If the question is why you might use SOAP as the protocol over which your tiers communicate, I'm afraid I couldn't recommend that at all. SOAP is slow at the best of times. You simply don't want the overhead of all that XML parsing and an extra HTTP request happening behind the scenes every time your - say - business tier goes to the database. It would suck, and it would violate the 'Keep it Simple' principle quite dramatically.
    Creating a soap interface is extremely simple. All you need it a data transfer object to move the data between the domain object and the xml data. It's also fast. Over a local network, it takes around 15 ms. It's even faster if you are using a framework with a built in way to send it as binary data such as Java's RMI or .Net's remoting.

    If you have many pc's accessing the database on the local network, then you will have alot of connections to that database. If you have one app that connects to the database and all the other pc's use this app as the extra tier to get to the db, you can cut down the number of connections by a staggering amount. So much in fact that you wouldn't need to add more database servers to account for the poor performance for a much longer time.

    Cheers,
    Eli

  8. #8
    SitePoint Guru
    Join Date
    Dec 2003
    Location
    oz
    Posts
    819
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I haven't heard of REST before.
    I just checked it out from here

    I sounds quite interesting.
    I think there would be a major issue though - which is that if you want to deal with an two entities that relate to eachother (eg an invoice and a list of invoice lines), you could end up having excess trips over the net - and each trip over the net is significant overhead. But this is also an issue with web services where you need to have a chunky interface for you web method calls.

    The thing with web services is that you can modify these two entities via a single call, whereas I get the idea that you would need to call one method to update the first entity and either the original caller or the first entity would need to call a second method to update the additional entity.

    Although I could be wrong - I only just read about it. Has anyone used REST or read up more on it that could let me know if that's correct or not?

    Cheers,
    Eli

  9. #9
    SitePoint Addict Trent Reimer's Avatar
    Join Date
    Sep 2005
    Location
    Canada
    Posts
    228
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You guys are definitely answering my question. I understand the benefit of using teirs but I am not sold on using SOAP for those tiers. I don't want to be hard-headed though. If you have reasons why this would be a good or bad idea I'm readin' em

  10. #10
    SitePoint Guru
    Join Date
    Dec 2003
    Location
    oz
    Posts
    819
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It depends on the architecture and performance/scalability requirements.
    But in most cases, I don't really think it's necessary to use soap between each tier.

    The main point is that you understand the concept behind it - which is that logical layers are often there so that if performance requires these layers to be seperated physically, you are able to do so with no more than a change in a config file. Once you unerstand the idea, you have the insight to make informed decisions.

    For example, if your system is expected to serve 10 million page requests a day, you might need to take more consideration for this. If it's a company-internal app, it's not likely to be an issue.

    Eli

  11. #11
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi.

    We tier over XML-RPC. This was dictated by the need for a separate API anyway, but it has also helped us with failover and loading issues specific to a tier. It hasn't significantly complicated the application and anyway forced some discipline on us. I could imagine tiering early in a project would seriously stifle creativity in exploring the initial designs though. This app. had been around for a good few years before we tiered it.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •