Round-up of PHP connectivity to MultiValue

[Dawn Wolthuis]

A colleague asked me about PHP connectivity options for MultiValue. I know Kevin King has done a lot of work on this front, Sierra Bravo (now the Nerdery) has something they use, and I'm sure that others have solutions too. Since I have done very little with PHP (I used some PHP connectivity code that Tom DeL wrote for OpenQM some years ago), I thought I would ask for a round-up of options. 

What is your DBMS and how are you (or would you) get from PHP to this MV data?  Inquiring minds...  Thanks!  --dawn

--
Dawn M. Wolthuis

Take and give some delight today

[George Gallen]

Because of the way I have my Browser/UV  interaction setup, I can use pretty much
any server side scripting language.
 
I have both a .cgi (PERL) and a .php (PHP) link
 
Basically, I write a file that contains the key and value using the PID of the script's process into one directory,
   then have it wait for a file to appear in a different directory of the same filename (PID).
 
My UV phantom looks in the one directory for new files, and processes the keys and data to determine which
   program to run, and that program then creates HTML output (or PHP/HTML output) and writes it to
   the output directory.
 
Of course, that requires the UV program to "know" HTML for output - but in general, it doesn't care who
  (PHP or PERL) created the key/value files, just that they appear, and doesn't care who serves it back to
  to the browser, just here's the HTML - do something with it.
 
George 

---

Date: Wed, 2 May 2012 10:07:02 -0500
Subject: [mvdbms] Round-up of PHP connectivity to MultiValue
From: dw...@tincat-group.com
To: mvd...@googlegroups.com

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[George Land]

We have developed a REST server that connects into UniData and provides an XML based interface that we can use with PHP and pretty much anything else.  It also provides a level of abstraction between the web server and the database server so that there is no direct communication between the two for security purposes.

George

[Dawn Wolthuis]

Cool! I am getting the feeling that there are almost as many solutions as developers out here, so maybe another piece that would be helpful to indicate they layers and what is supplied by the database provider compared to what you have as proprietary to your shop. 

So, you write PHP as a client to your web services that you publish to your own proprietary set-up for an Apache web server (?) specific to your UniData instance? Then you publish web services in some way (and I don't know how that works for UniData, but I know how to do it from Cache'). 

Middle tier in web sever: Standard PHP stuff to serve as a client to a web service
Middle tier REST Web Services server: Apache (?) plus some proprietary stuff your shop wrote

Back-end: services written to pass xml

Is this the picture? I'm a bit clueless on some of this, so this question might not be right on target, but what is the precise connection into UniData? Are you using named pipes, UniObjects, UOJ, UniRPC, some proprietary process written in mvbasic that your REST server runs, ...? --dawn

[Dawn Wolthuis]

OK, I think I get it. You are dropping jobs into a location where a phantom process picks them up, does something based on the key-value dropped there and returns html to another location. The requesting script that wrote the job out originally waits for a response and picks it up and processes it. There is nothing fancy and new-fangled, just nice and straight-forward with name-value pairs coming in and the actual output for the screen coming out. 

This seems like it might be less complex to pull off than some other solutions, but with a trade-off of not having a good separation of concerns between the front/middle tiers and the back-end. If you were to start from scratch today would you be more inclined to pass json or xml back rather than already-formed html or does this still seem like it works well from your perspective?  Thanks!  --dawn

[George Gallen]

I think I misunderstood your question. Are you looking for how PHP can login/open files/read records from UV for use in it's own programs, or
  how PHP can interact with UV as a server side scripting and UV being the dyanamic web server?
 
I wrote some UV routines that allowed java to open / close / read /write to UV including maintaining record locks if needed, however, it was
   very very slow - essentially I had the java methods send post requests to an API (PERL in my case) that then passed off the codes to
   the UV phantom, which then returned the data in XML back to java.
 
I'm sure it wouldn't be too difficult to convert the java over to php, and it might be slightly faster if there wasn't that initial API layer. I hadn't
   implemented the SELECT command to return multiple rows / columns of data yet. Just basic Read/Write and select/get/save lists.
 
It was more of a use case while learning/toying java - it worked - but it was too slow for any real production environment, and kinda
   of shelved it.
 

---

Date: Wed, 2 May 2012 10:07:02 -0500
Subject: [mvdbms] Round-up of PHP connectivity to MultiValue
From: dw...@tincat-group.com
To: mvd...@googlegroups.com

[George Gallen]

depends on the use. I have a similar setup that returns XML I use for webservices. It takes in XML or GET/POST key/values uses the same
technique for passing it off to UV and waiting for the response and sending back XML instead.
 
This also is helpful for those webpages that interface with UV using AJAX
 
But for general Dynamic HTML, I'd keep it the same.
 
For our side, the UV uses phantoms more out of cheapness - doesn't utilitize any user seats - tradeoff slowness waiting for phantoms
  to fire up.
 
Another option we are looking at is creating a parallel "universe" on a MySQL that only contains the data that would be needed, and would
  be updated on a timed basis (possibly realtime using triggers) - and at that point, you already have PHP natively that can interact with
  MySQL. Trying to figure an easy method of having MySQL update UV however if anything is written back.
 
George
 

---

Date: Wed, 2 May 2012 11:11:21 -0500
Subject: Re: [mvdbms] Round-up of PHP connectivity to MultiValue
From: dw...@tincat-group.com
To: mvd...@googlegroups.com

[Dawn Wolthuis]

No, I don't think you misunderstood. I am looking for a round-up of all of the ways that people access (read/write) data that is in an MV database from PHP. So, this is about web applications. I'm good with learning about any of the layers involved. Of course the question of record-locking or optimistic locking (concurrency testing) would be part of the design for any of the solutions.

I have not worked with any of these (with the one exception I mentioned), so I'm looking for an overall round-up on behalf of a colleague. I figure that if I understand what others are doing, I can get a better list of the options.

While I use Cache' with Zen (no PHP required in the mix), I will also be doing web services at some point soon. I do not intend to put PHP into the middle at this point, but if I were to use a CMS tool, then I would want to use PHP as the client to web services too. Right now I'm just looking for the full range of options that people use for getting data between PHP and MV.  Thanks!  --dawn

[Dawn Wolthuis]

A bit off-topic, but given what I am gathering are some of your requirements, you might be interested in this. I would love to see someone give InterSystems GlobalsDB a spin. You can put you MV data there, I am told. Access is via .net or java right now, but in the future (or maybe now, I haven't looked recently) it should work with node.js. This would mean js on the server-side to access mv data in an open source database. 

I don't know if GlobalsDB will add something opensource to the MV landscape or not, but it seems to have some promise. Any thoughts?  --dawn

--
You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[George Gallen]

javascript and server side don't go together. javascript is client side (in the browser), whereas PHP is server side (before it's sent to the browser).
 
The danger to client side is that if you need any passwords, they have to be sent either clear text or https, but either way, they will still
be clear text at the browser. With PHP (server side), any passwords are only stored on the server, and the client never sees it only the
output data.
 
George
 

---

Date: Wed, 2 May 2012 11:36:41 -0500

Subject: Re: [mvdbms] Round-up of PHP connectivity to MultiValue
From: dw...@tincat-group.com
To: mvd...@googlegroups.com

[Kevin King]

I'm a little late to the party but being how I was mentioned somewhere above...

We have several ways of connecting from PHP to Unidata, and a couple of ways to connect from PHP to anything else.  On Unidata we can connect with Uniobjects, with the dual-Apache method (that I've been expounding in Spectrum mag), and we also have our own Java based connector.  For QM or other platforms, we obviously don't have Uniobjects but we can use the other two methods.

The problem with making a direct connection into Unidata in particular is that Unidata doesn't really offer a general purpose thread server for communications.  There is Uniobjects, but that's very specific, proprietary, and inefficient.  So we use either Apache or our jConnector to provide the threaded server interface into the database.  This server accepts a packet of JSON-formatted data, sets it up into an environment variable, starts up Unidata/QM/whatever where a login program "senses" the environment variable, reads the request, parses it, calls an API subroutine, and then drops the output into a directory file.  Then the database shell terminates, the PHP script picks up the result, and returns it back through the connector to the client.  Sounds like a lot of stuff to go through, but it's amazingly fast.

There are several keys to this but one of the most important ones for us has been JSON support.  Using JSON we can easily pass structured data into and out of Multivalue.  Could have used XML, of course, but that requires significantly more characters to convey the same message.

Another thing we've done is that all of our connectivity is abstracted to a single PHP class.  We just replace this one class file with the appropriate connector for the environment to fluidly change between any of our connectors.

Does this help at all?  At the risk of sounding like a plug, you might check out the last couple of editions of Spectrum mag where I discuss the dual-Apache method in some detail.  The last part of this series will be in the next edition, I hear.

-K

--

[Tony Gravagno]

I have a client that was already using PHP against D3 but they recently created a simple wrapper around mv.NET so now their PHP client runs against their D3 system with a nice pooling server.

 

If I need PHP/MV for little ditties, I've been working on mvEsperanto which I mentioned that I was writing here some time recently. In short it exposes a single connectivity class for any MV DBMS. So far I have interfaces for all databases using mv.NET, D3/MVSP, U2/UOJ, QM/QMClient, and a couple others. There's also a SSH login to execute TCL/UDT commands without going  through a DBMS pipe, and a web service interface to get into anything else.  So it's "PHP to any MV system using whatever pipe you prefer". I haven't had much time to work on it but the "Esperanto" piece of this is that the same API and server interfaces can be used by other languages like Ruby, Java, .NET, or whatever other language one wishes. Need Ruby to U2? Got it. Want to swap out UOJ with UO.NET without changing your Ruby code? No problem. Want to swap QM and still use the same Ruby code? No problem. Want PHP with jBase? Sure. What if your developer writes with Java against jBase but you're running Caché? No problem, their code will work against your server. Need to pull from D3 and QM using the same PHP or Java code? Got it.

 

The code is awful and only partially working in places. It's supposed to be an Open Source project but I just haven't had time (in the last 3 years that I've been working on this) to publish the docs and code. Ultimately the idea here is that you should be able to get people who know any language to access any Pick environment, and they shouldn't need to learn UOJ for U2, MVSP for mvBase, and some custom API for QM. This is a single API for all languages to all MV platforms using any comms pipe … well, that's the plan if I can find any time (or funding) to keep working on it…  (What's a language/platform-agnostic binding worth to this industry?)

 

Anyway, that's not viable for general usage yet. Generally for anything more than a simple ditty, I use web services from PHP (REST or SOAP) because that's as fast and generic as it gets. Then on the back-end I tend to use mv.NET, but you can use any connector for any DB here.

 

I went through all of the above to provide an answer to "the next" question, which is "how do I use Ruby with MV?"  Substitute Java, Perl, BF, Eiffel, F#, COBOL, or any other language. This industry is short on language bindings. The MV providers are all playing the same game in providing what they think is important - and providing us with their proprietary APIs and bugs in the process. Then a decade goes by with inadequate solutions and people are still asking the same questions. The solution for all of these is the same. We need to stop thinking in terms of getting single-purpose solutions from vendors and start creating more general purpose solutions for ourselves.

 

T

[Dawn Wolthuis]

Yes, I read your articles and it sounds like a really good approach. If I were using UniData right now, I would definitely be looking into this further. Thanks for taking the effort to write it up for Spectrum magazine too.

Thanks.  --dawn

[James A]

On Wed, May 2, 2012 at 9:45 AM, George Gallen <g_ga...@hotmail.com> wrote:

.... javascript is client side (in the browser), 

 

What about:

http://en.wikipedia.org/wiki/Comparison_of_server-side_JavaScript_solutions

and in particular: 

http://nodejs.org/  seems to be getting the most attention...

- James

 

[Dawn Wolthuis]

Yes, I have been watching this, interested in nodejs, but not interested enough to give it a spin until someone gives me more clues how I could use it with MV data in Cache'. Once upon a time I liked to figure these things out for myself, but this profession just seems to get geekier and geekier and I'm not.

cheers!  --dawn

 

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[Doug Averch]

After seeing the hokum and smoke approach of some programmers have used to hookup to either Unidata and Universe with PHP.  We developed a simple easy solutions that allows you to call any subroutine or TCL command.  This interfaced is based on our proven U2WebLink middle-ware.  This middle-ware runs on Apache Tomcat using UniObjects for Java.  You can pass data either with JSON or text.  The middle-ware handles the user requests all you do is write the PHP code and/or UniBasic code.  Here is a code sample:

$results = $sharedsub->command($request, "0", "COUNT VOC");
echo "call sharedsub.command=$results";

Life can be really simple.  Check it out at http://www.u2logic.com/php.html for more example code.

Regards,

Doug

www.u2logic.com

[George Gallen]

ok. I was speaking from the point of view of javascript contained within a served webpage.
 
Can you utilize jQuery in conjunction with server side javascript?
 
George
 

---

Date: Wed, 2 May 2012 13:41:51 -0500

Subject: Re: [mvdbms] Round-up of PHP connectivity to MultiValue
From: dw...@tincat-group.com
To: mvd...@googlegroups.com

[James A]

On Wed, May 2, 2012 at 11:41 AM, Dawn Wolthuis <dw...@tincat-group.com> wrote:

Yes, I have been watching this, interested in nodejs, but not interested enough to give it a spin...

Me too: no time but it's fun to keep an eye on it all. It got higher on my interest list due to the globalsdb interface:

http://www.slideshare.net/robtweed/globalsdb-its-significance-for-nodejs-developers

 

This may mean more to you since you work with Cache; I'm still on UV.

Actually since  AFAIK globalsdb IS the same engine; the interface should work for the full version of Cache? But I presume it would work at the lower globals level and NOT with Objects and NOT directly with MV:

http://docs.intersystems.com/documentation/cache/20121/pdfs/GGBL.pdf

Still; if I was on Cache I might give it a whirl ? ...

- James

[James A]

Can you utilize jQuery in conjunction with server side javascript?
 

I haven't done it; but I presume you just send up the jQuery code to the browser as usual whether a template or whatever. Much of jQuery wouldn't do much good running on the server? But I could be wrong...in any case, lots of other libraries WOULD be useful on the server.

But while there are clear advantages of having to know only one language for both client and server (as well as HTML and CSS of course), I don't see this approach being very mature yet; but there's a lot of traction and time will tell.

- James

[montgomery]

Howdy,

QMPHP is a free PHP extension that provides access to QM through the
functions that are exposed via the qmclilib library. QMPHP is available
via the downloads page at http://www.openqm.com


\\//_

[Dawn Wolthuis]

Oh, it will work with MV data, I have been assured. You simply get a raw engine that will pass the data, currently to and front .net and java. I think it is supposed to work with nodejs sometime in the future, but I don't know how soon that is.

So, yes, this is a way to take MV data into an open source database with the same data model (without switching to an rdbms, for example). That sounds cool, but without a corresponding colon prompt, I'm just not geeky enough to work with it immediately, I'm guessing. There is likely an opportunity here for someone to write enough scaffolding for the average pickie to get moving with this new open source dbms.  --dawn

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

[Dawn Wolthuis]

Thanks Montgomery! I have also heard that this extension might work with other MV databases. Has anyone tried it with anything other than QM?  --dawn

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com

To unsubscribe, email to: mvdbms+unsubscribe@googlegroups.com

For more options, visit http://groups.google.com/group/mvdbms

[Dawn Wolthuis]

Sorry, I got confused when seeing both "client-side" and nodejs. 

I have not used nodejs for server-side javascript, but you would use js on both client, as usual, and on the server in place of PHP, for example. jQuery is a library for client-side js functions, and I suspect there might be a few functions (data manipulations, for example) that could be useful on the server-side too, but I doubt that it currently also functions as a significant server-side library.  --dawn

[uiterwyk]

For jBase, we use their jRCS add-on with a client library for PHP that directly interfaces with the database.

It allows us to make connections, directly read/write files, and execute command and or subroutines. 

Very fast and efficient and allows one to do almost anything in real-time.

Prior to being on jBase, we were on D3 and used the JD3  library written by Christophe Marchal.

A rather complete discussion of it can be seen here:  http://www.djpatterson.com/jd3php.html

We had basically the same functionality as we now have on jBase.  The only issue was timing. 
We had to make sure that the socket connection had minimal delays.

Robert

[Symeon Breen]

Rocket supply three supported methods to integrate into U2, a com one called uniobjects, a .net library called uniobjects.net and a java one called uniobjects.java.  The recommended approach is to write your access layer in one of these technologies (e.g. an asp.net web service) and to then access the data using whatever language you want via the web service.

 

We use uniobjects.net, and just happen to access the web services in asp.net, but I could just as easily access it via php.

 

 

Rgds

Symeon.

--

You received this message because you are subscribed to
the "Pick and MultiValue Databases" group.
To post, email to: mvd...@googlegroups.com
To unsubscribe, email to: mvdbms+un...@googlegroups.com
For more options, visit http://groups.google.com/group/mvdbms

---

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1424 / Virus Database: 2411/4972 - Release Date: 05/01/12

[Rex Gozar]

Just to mention it, www.PickWiki.com has some info on connecting
websites to mv databases. There's some PHP-specific pages there. I
invite everyone to contribute what they can to PickWiki.

rex

[Kevin King]

The problem with Uniobjects, at least in the context of PHP, is that it's a COM object that requires the COM wrapper in PHP to run, and that is only available on Windows.  It works, certainly, but if your web server is running on Debian, Ubuntu, or any of the other myriads of NoMOs (Not Microsoft O/S), Uniobjects isn't going to work unless you're running Java.  And while I believe Doug (Averch) has the PHP -> Java bridge working, I've never been able to wrestle enough performance out of it with UOJ.

-K

[Herb Rubin]

I wrote my own called "Web Application Server".

http://www.pfinders.com/phptod3/

It connects PHP and D3 and runs as phantoms.It works by passing arrays back and forth rather than sql style rows. But you can
simulate it by passing arras of arrays back from D3. I allow PHP to call Pick Basic subroutines by name.

You can single step this by putting a debug statement in the Basic subroutine and after it goes into the debugger you can tandem to it.

I have this running at 25 client sites. The biggest one gets 7000 subroutine calls a minute at 4pm. That's their peak time. So, they run 126 phantoms
sharing the load which turns out to be 1 call per second on each phantom. So, we have to make sure our Basic subroutines are fast.

I also have a monitoring system that text's me when we lose more than 50% of the phantoms due to phantoms aborting. This happens when we have
new code to deploy. The most common is when we forget to open a file and try to read record anyway!

Herb

[Symeon Breen]

As I say in my comments the interface into u2 is via web services. The web service can be written either using the com object or in asp.net or wcf or java, so the client can be anything and need not concern itself with the technology underneath. Uniobjects.java will work on basically any machine so you don’t have many restrictions in place at all. Uniobjects.net works inside the net framework, which is also free, with free development tools, you just have to buy a windows licence, but most businesses have windows licences anyway.

Version: 10.0.1424 / Virus Database: 2411/4975 - Release Date: 05/03/12

[towerjon]

I have worked on a PHP connector for D3 - which seems reasonable with one major drawback, which is it does not have connection pooling, severly limiting scalability.

Here is the architecture:

1) A PHP script runs the D3 TCL command line executable to pass commands directly into D3/TCL, with a unique "web request ID".  This is the "trigger" to start a job.

2) At TCL, a subroutine is called that spawns a "web request" job as a phantom.

3) At this point, PHP is done processing and waiting in a loop with a few microseconds sleep statement for a "web response", and the phantom goes off to do its work.  At this point, my connection to D3 through TCL is closed.

4) The phantom is running a generic subroutine that takes the name and arguments of another subroutine which represents some API piece of my app.  It takes in the name and arguments, executes that subroutine, captures the output, and writes it to a response file through FSI with the unique "web response ID" matching the "web request ID" from step 1.

5) PHP is polling the output file folder looking for its response.  If it doesn't receive a response before a specified timeout, PHP gives up.  In any case, the phantom runs until completion, whether PHP sees the result or not.

6) When PHP sees its request ID as a response in this output file folder, it opens that file, reads the response, returns it, and deletes the response file as it is no longer needed.

7) A job comes along every so often and deletes really old responses in the output folder that just collect when commands time out and the response is not processed.

I did it this way so as to spend as little time connected to a D3 session as possible.  The D3 TCL trigger gets in, spawns the job, and gets out.

This architecture has worked, but is limited by # of phantoms, and unfortunately, it is not connection pooling.

My experience thus far, for D3 at least, is MV.net or MVS toolkit are the only two robust commercial solutions for connection pooling connectivity.

MVSP is good up to a point, but does not have connection pooling built in.  Anything else is not really a solid option, unless you are a C programmer and build your own connection pooling socket server for D3 such as Coyote (or use that product).

Wish we had better options out of the box.

Jon

On Wednesday, May 2, 2012 8:07:02 AM UTC-7, Dawn Wolthuis wrote:

[CDMI - Steve T]

this may not really compare with PHP, yet you can do ALL HTML oriented 'stuff'

EasyCo has Coyote which is a HTTP 1.0 compliant web server that runs real time within the multi value database. you can be running LAMP (linux,apache,mySQL,php) with Coyote for all 'multivalue' queries and updates. you merely have apache 'proxy' to the coyote web server when 'dynamic' retrieval and/or update is required. you can perform 'php include' within an HTML page and that include could hit Coyote for 'just the dynamic' part of the page.

you could run Coyote on QM/Linux with the database on Universe, mvBASE, or D3

Coyote has RPC capabilities that can read, write, etc to any multivalue flavor regardless of where the original 'hit' came from.

Coyote is multi threaded and on most environments do NOT take up licenses (merely phantoms).

i've seen D3/Linux systems running '20 Coyote servers' all listening to different http ports

one great thing for me is that 90% of the coding is BASIC

the shell is HTML, but the heavy lifting is done in BASIC

 

sorry if this is 'off topic', just thought i'd add my 2 cents
 

Steve Trimble

Computerized Data Mgmt Inc
PO Box 13403
Maumelle, AR 72113
(501) 803-0974 09:00am - 6:00pm CST

---

From: towerjon <jsal...@towersys.com>
To: mvd...@googlegroups.com
Sent: Fri, May 4, 2012 2:20:23 PM
Subject: [mvdbms] Re: Round-up of PHP connectivity to MultiValue

[Wjhonson]

Isn't it true that you don't need LAMP with Coyote?

I thought when I'd seen Doug demo it before, it's a full stack so all you need is Coyote and your mv environment and CGI or something.

[Dawn Wolthuis]

Sorry I'm not interacting here, I took a drive from NW Iowa to SW Michigan yesterday and am not in the office for a week, but will occasionally check in as I am definitely interested.

Coyote definitely fits into the list of possible web options, even if not in a PHP round-up. I am not so enamored with PHP as I can get the job done without it by using the Cache' Zen framework too. This does not get a typical CMS interaction with the DBMS, however.  

So, yes to Coyote, Zen, and other options for complete web solutions, but for this thread I'm hoping to get a better clue on the various PHP options and perhaps some best practices. Thanks.  --dawn

[CDMI - Steve T]

no, you don't NEED LAMP to use Coyote, but Linux/Apache handles 'normal' web pages flawlessly.

Linux/Apache is also rock solid for 'allowing'/'disallowing' certain events.

Coyote better services dynamically driven scenarios, wereas Apache handles straight up web pages and images.

having this scenario also kind of 'protects' the multivalue system (even if it is the same system)
 

Steve Trimble

Computerized Data Mgmt Inc
PO Box 13403
Maumelle, AR 72113
(501) 803-0974 09:00am - 6:00pm CST

---

From: Wjhonson <wjho...@aol.com>
To: mvd...@googlegroups.com
Sent: Fri, May 4, 2012 3:53:07 PM
Subject: Re: [mvdbms] Re: Round-up of PHP connectivity to MultiValue

[Tony Gravagno]

(Consider this an AD)

Jon, for exactly the reasons you documented, one of my clients wrapped mv.NET into their PHP interface. So they get pooling without changing their PHP middle-tier page processing. Now that they have pooling (and this is my conclusion though I don't yet know how they intend to proceed here), the overall cost of their application to end-users can come down, thus making it easier for them to sell more product (and even more DBMS licenses) to new and existing sites.  I know this developer monitors this group, perhaps they will post their own commentary.

 

Tony Gravagno

Nebula Research and Development

TG@ remove.pleaseNebula-RnD.com

Nebula R&D sells mv.NET worldwide

and provides related development services

remove.pleaseNebula-RnD.com/blog

Visit http://PickWiki.com! Contribute!

http://Twitter.com/TonyGravagno

http://groups.google.com/group/mvdbms/about

 

 

 

 

From: jsaltzman

 

I have worked on a PHP connector for D3 - which seems reasonable with one major drawback, which is it does not have connection pooling, severly limiting scalability….

This architecture has worked, but is limited by # of phantoms, and unfortunately, it is not connection pooling.

 

My experience thus far, for D3 at least, is MV.net or MVS toolkit are the only two robust commercial solutions for connection pooling connectivity.

 

MVSP is good up to a point, but does not have connection pooling built in.  Anything else is not really a solid option, unless you are a C programmer and build your own connection pooling socket server for D3 such as Coyote (or use that product).

 

Wish we had better options out of the box..

 

Jon

 

 

 

[towerjon]

It's true, if you have a Microsoft platform available to you, you can hide your MV database behind a web service tier (REST, WS*, WCF, etc.) using mv.NET as the DAL/connectivity tier. 

If fact, I am personally advocating this route simply for the architectural advantages, with proper architectural patterns like repositories and inversion of control for injecting in the data access components, especially for medium to larger sized projects.  This will give you complete UI independence, a proper API layer in a modern programming language, and the ability to some day possibly swap backend databases out for other technologies.

However, if you are in the *nix/cross platform environment, mv.NET isn't necessarily an option (unless it runs under Mono.NET or in WINE, which I am not sure about).

So if you have a *nix based/cross platform environment, have a D3 (9.0) backend, and want to connect via PHP, the only scalable options that I am aware of are: MVS Toolkit, the MVSP API via the PHP to Java object bridge (which might work but is a lot of layers to go through) or home-brew tools.  Coyote could also be used primarily to serve up XML/JSON to front end consuming applications, but it doesn't have WS* support.

As I am primarily talking D3/*nix, Java/JSP instead of PHP (with the MVSP API) is a possible solution, minus the fact it lacks connection pooling.

Jon