![]() | |
![]() |
| | Thread Tools | Display Modes |
#11
| |||||||
| |||||||
|
|
For a standard ISP that provides LAMP or hosted ASP/ASP.NET, you could use a forwarding technique which accepts the request then redirects it wherever you want using sockets or Web Services. |
|
When you go to someone's home page where they show you the weather, you don't really think they have a weather station there do you? Of course not. Arequest is made to another server and the results are incorporated into the end-user's page. This is how the net works and this is the core of SOA. |
|
For security reasons some ISP's don't allow outbound socket calls except outbound HTTP on port 80 or 443. This is an invitation to use Web Services - which is one of the reasons why I wrote my articles ont this topic over two years ago. http:// removethisNebula-RnD.com/articles/ Your home or office firewall/router should not accept HTTP requests from any IP address(es) other than your static HTML host (the LAMP people). This gives you almost rock solid security. |
|
From there your real back-end environment probably doesn't need any more security than what you require for your own LAN. Being paranoid I'd put more effort into this but YMMV. So what do you need? 1) PHP or Perl on your LAMP host that accepts a web query and parses out the request data. Millions of examples of this on the Net. |
|
2) A PHP/Perl-based Web Service client that accepts a block of text (from #1), passes it on for external processing, and returns the results to #1 for final end-user rendering - probably HTML. Again, tons of examples available everywhere. |
|
3) A firewall that you can tune to only accept port 80 traffic from a selected IP block. 4) Any HTTP server you want on any OS you like on your own LAN. 5) Any freeware/buyware Web Service Server software that will extract data from an XML packet and return the data back to the client - again, all free, lots of examples. 6) Any freeware/buyware discussed in these forums to pass a block of text from #5 to your MV server and return the results. (With mv.NET and Visual Studio you can do #4-6 in a couple minutes.) Any help? |
|
"dawn" wrote: Luke Webber wrote: dawn wrote: I am wondering how many ways there are to write a Pick/DataBASIC service that takes in a parameter from a URL and returns (via http) a result. Let's say that there is JavaScript in a browser that is doing an XMLHttpRequest (or ActiveX), aka AJAX, request to a URL such as www.mydomain.com/myservice.whatever?this=that What all is behind this URL? It might be enlightening (to me at least) to inventory the ways to accomplish this feat. 1. PHP + OpenQM client/server library + OpenQM In a non-transaction processing environment (in fact doing only read-only right now), I have done this with a PHP wrapper that Tom D wrote for OpenQM, which uses the OpenQM client/server interface written in C (IIRC). 2. Tomcat + Java + UOJ library + UniData I have also done this using a tomcat app server (either in addition to or instead of another web server), Java, and UniObjects for Java (UOJ) with UniData. I had to add in home-grown connection pooling at the time, but UOJ now comes with it (for a price). 3. Tomcat + Java (or PHP or ASP) + JD3 + D3. 4. Tomcat + Java + Java OBjEX + jBASE. 5. CGI + jBASE binary executable. Note that Tomcat is not the only servlet container out there. Far from it - so you can substitute Resin, Weblogic, WebSphere, JRun, Sun One Server or what-have-you for Tomcat. Likewise, in your point 2, you could have UV instead of UDT. Luke Everything so far (you and Glen) requires either a servlet container or CGI. Neither of those is readily available for those doing web site development using a typical ISP (which is often similar to what a corporate web setup might look like for developers who don't have a lot of say on that setup). That's why LAMP (linux, apache, MySQL, PHP) is so popular -- it works both for shops with their own servers and those using ISPs, most of whom provide both PHP and MySQL (typically for extra dollars on the latter). Does anyone have a solution that uses neither CGI nor a servlet container? --dawn |
#12
| |||
| |||
|
|
Frankly, I don't know why you're so stuck on the public server approach. It's dead cheap to run your own server at home. Not for most people, it isn't. All you need is a cheap server PC and Linux, plus a static IP address. OK, the speed may not be all that an ISP can offer directly, but with ADSL2+ it ain't half bad. I'm guessing I'm in the majority of people in the world when I say that I don't want to install and maintain a production server environment. Bandwith, disk space, OS upgrades, app installs, unplanned downtime, security, backups, user administration, fail-over, performance tuing, ... |
#13
| |||||
| |||||
|
|
Tony Gravagno wrote: Your home or office firewall/router should not accept HTTP requests from any IP address(es) other than your static HTML host (the LAMP people). This gives you almost rock solid security. at one level. There's still the "SQL injection" type of possibilities even if using MV. (This is irrelevant, I just wanted to argue with your "rock solid" designation ;-) |
|
From there your real back-end environment probably doesn't need any more security than what you require for your own LAN. Being paranoid I'd put more effort into this but YMMV. So what do you need? 1) PHP or Perl on your LAMP host that accepts a web query and parses out the request data. Millions of examples of this on the Net. Yes, but is there even one example of PHP with UniData and, if so, what was used for connectivity between PHP and UDT? That's why I'm asking for real examples of what people are doing or have done. |
|
2) A PHP/Perl-based Web Service client that accepts a block of text (from #1), passes it on for external processing, and returns the results to #1 for final end-user rendering - probably HTML. Again, tons of examples available everywhere. Still looking for what people are actually doing in this regard. |
|
3) A firewall that you can tune to only accept port 80 traffic from a selected IP block. 4) Any HTTP server you want on any OS you like on your own LAN. 5) Any freeware/buyware Web Service Server software that will extract data from an XML packet and return the data back to the client - again, all free, lots of examples. 6) Any freeware/buyware discussed in these forums to pass a block of text from #5 to your MV server and return the results. (With mv.NET and Visual Studio you can do #4-6 in a couple minutes.) Any help? Sure, but putting it in the form of actual web server, web server add-ins (e.g. PHP) or app server (e.g. tomcat, jboss), libraries or tools to get from there to the back-end database, and the back-end database with specifics of real implementations, might be more helpful. Thanks. --dawn |
|
"dawn" wrote: Luke Webber wrote: dawn wrote: I am wondering how many ways there are to write a Pick/DataBASIC service that takes in a parameter from a URL and returns (via http) a result. Let's say that there is JavaScript in a browser that is doing an XMLHttpRequest (or ActiveX), aka AJAX, request to a URL such as www.mydomain.com/myservice.whatever?this=that What all is behind this URL? It might be enlightening (to me at least) to inventory the ways to accomplish this feat. 1. PHP + OpenQM client/server library + OpenQM In a non-transaction processing environment (in fact doing only read-only right now), I have done this with a PHP wrapper that Tom D wrote for OpenQM, which uses the OpenQM client/server interface written in C (IIRC). 2. Tomcat + Java + UOJ library + UniData I have also done this using a tomcat app server (either in addition to or instead of another web server), Java, and UniObjects for Java (UOJ) with UniData. I had to add in home-grown connection pooling at the time, but UOJ now comes with it (for a price). 3. Tomcat + Java (or PHP or ASP) + JD3 + D3. 4. Tomcat + Java + Java OBjEX + jBASE. 5. CGI + jBASE binary executable. Note that Tomcat is not the only servlet container out there. Far from it - so you can substitute Resin, Weblogic, WebSphere, JRun, Sun One Server or what-have-you for Tomcat. Likewise, in your point 2, you could have UV instead of UDT. Luke Everything so far (you and Glen) requires either a servlet container or CGI. Neither of those is readily available for those doing web site development using a typical ISP (which is often similar to what a corporate web setup might look like for developers who don't have a lot of say on that setup). That's why LAMP (linux, apache, MySQL, PHP) is so popular -- it works both for shops with their own servers and those using ISPs, most of whom provide both PHP and MySQL (typically for extra dollars on the latter). Does anyone have a solution that uses neither CGI nor a servlet container? --dawn |
![]() |
| Thread Tools | |
| Display Modes | |
| |