Reply to thread

Message

<blockquote data-quote="samuel337" data-source="post: 87972" data-attributes="member: 10347">Not sure about that, but there's been a .NET implementation of PHP out for a while, called phlanger - <a href="http://www.php-compiler.net/" target="_blank">http://www.php-compiler.net/</a>. However, the advantage of my architecture is that it does not require the web service to be running on every client. Each client will have to run the ECP2 plugin, however, only one client/server will have to run the web service, which will automatically route the requests to the appropriate machine. This should make it much easier for web service users to communicate with MP.Note that MPBlue actually uses .NET remoting in its web service form. That is, the .NET remoting part actually acts as a SOAP web service. The downside is that without a 'broker', each client will have to run the MPBlue server plugin and the web service (and also that generics aren't supported).I don't believe that there is a significant performance lag with using .NET remoting coupled with a web service. Another advantage of this is that .NET applications can communicate directly with MP using MP objects without having to serialise and deserialise to and from XML (improving performance). This is in fact the main performance lag&nbsp; - the serialisation of MP objects into XML by the web service and unfortunately cannot be helped given the nature of web services.MPBlue devs - please don't take this the bad way, in fact I'd be quite interested in seeing what you guys are doing to handle the new client/server configuration. Do correct me if I have the facts above wrong.Sam</blockquote>

[QUOTE="samuel337, post: 87972, member: 10347"] Not sure about that, but there's been a .NET implementation of PHP out for a while, called phlanger - [url]http://www.php-compiler.net/[/url]. However, the advantage of my architecture is that it does not require the web service to be running on every client. Each client will have to run the ECP2 plugin, however, only one client/server will have to run the web service, which will automatically route the requests to the appropriate machine. This should make it much easier for web service users to communicate with MP. Note that MPBlue actually uses .NET remoting in its web service form. That is, the .NET remoting part actually acts as a SOAP web service. The downside is that without a 'broker', each client will have to run the MPBlue server plugin and the web service (and also that generics aren't supported). I don't believe that there is a significant performance lag with using .NET remoting coupled with a web service. Another advantage of this is that .NET applications can communicate directly with MP using MP objects without having to serialise and deserialise to and from XML (improving performance). This is in fact the main performance lag - the serialisation of MP objects into XML by the web service and unfortunately cannot be helped given the nature of web services. MPBlue devs - please don't take this the bad way, in fact I'd be quite interested in seeing what you guys are doing to handle the new client/server configuration. Do correct me if I have the facts above wrong. Sam [/QUOTE]

Verification