Nick, Arnaud and (others), What I need is not relatively simple. It will be heavily frequented, but I will have the luxury to have huge machines running the system. It will be an application with the continual development of modules in that application. In regards to calls to the DB, most of the calls to the DB can be handled with one SOAP call so there (hopefully) would not be multiple transmissions. Speed will be important, but there is a threshold, that if I can stay over, SOAP will be fine. I also want to use SQL Relay to help speed up the back end process. SQL Relay http://sqlrelay.sourceforge.net/ http://sqlrelay.sourceforge.net/sqlrelay/introduction.htm The other methodology that I am tinkering with is an XML/XSLT solution. Where the app server sends and receives custom XML that can be parsed by a specific XSLT page. I have been with a company that has done this before with success. What I do not like is the ridged XSLT language and the fact that the XML is not easily interoperable because it will be so custom. I see a real issue here taking PHP to the next level using N-Tier methodology. Another question in my mind is, where is the biggest performance issue in the PHP SOAP architecture - the SOAP package creation/translation or the HTTP transmission between servers. If it is the HTTP transmission, can I over come that with fiber or gigabit networks. If it is the creation/translation, would moving to PHP5 (better OO and XML support) or using the C implementation of XML-RPC help that? I feel like I am missing a solution out there. Is there any other way PHP can be integrated into a 3-tier architecture? - Paul P.S. Thanks for all the input, this is going to be a big deal and all the help, well, helps. -----Original Message----- From: Nick Oostveen [mailto:nicko-ml@hpmarketing.com] Sent: Wednesday, December 17, 2003 1:46 AM To: soap@lists.php.net Subject: Re: Architecture Question - Opinion If things were structured so that all business logic was located on the application server itself, and the web server was limited to essentially formatting and displaying data, wouldn't that eliminate a lot of the unnecessary overhead? This way instead of having one remote call per query, you would only have one or two per page, each of which executes a number of queries from the application server. As for government, I do understand their concerns. If the web server has direct access to the database, even to a restricted number of tables or views, if it gets exploited the attacker will likely be privy to all sorts of private and personal data. By adding an application server which isn't publicly accessible into the mix, the speed and ease with which an attacker can view or alter the data is severely limited. Nick At 07:16 AM 12/17/2003 +0100, Arnaud Limbourg wrote: >Well, doing all the db call via a soap or xml-rpc interface will be slow. >If you just have a few queries it is not a big deal, but on a site with >lots of queries and/or heavily frequented it will be different. > >I wonder why governments fear so much. You make a few views and restrict a >user/pass to access only those views. > >Anyway, if speed is important and wha tyou need is relatively simple the >xml-rpc might be best. > >Arnaud. > >-- >PHP Soap Mailing List (http://www.php.net/) >To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Soap Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Soap Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
