PHP + .Net Web services for data access - Bad Design Choice?

The company has a PHP app that is in horrible condition. They want to start making plans to redesign it in .NET, however they need to run with the current design because of various reasons that I won't get into here.

They want to make some enhancements to the current design but do it in such a way that those enhancements can be in-part reused by their .NET version when it comes along. One idea to do this was to make the data and business logic portion of the app reside as a .NET webservice that would be consumed by the PHP end.

My question is will this cause problems in PHP? Can PHP consume .NET web se开发者_开发知识库rvices quickly and efficiently? Or is this just a bad design decision?

My question is will this cause problems in PHP? Can PHP consume .NET web services quickly and efficiently? Or is this just a bad design decision?

I have two thoughts here. First to answer your question directly. I don't believe it's a bad design and if the .NET services are written language agnostic then there should be little issue.

The second thought is a "hope". I hope the choice to go with a .NET framework was not due to poorly written PHP. Changing languages because of poor implementation in my opinion is where the design fails. There will be more effort converting to a new language than there would be if the company choose to re-write the PHP and the end result would be a single unified language base with built-in legacy support. But then I'm a PHP fan.

For PHP to consume .NET webservices quickly you'll need to use PHP5 native SOAP Client API, enabling cache to store WSDL locally. If you use PHP4 you can use Nusoap, but it isn't as fast as native classes.

The whole point of having a webservice is interoperability between various development platforms. For instance twitter is a rails-based website and its services are consumed by multitude of various desktop and web applications written in .NET, java, python, etc, through its RESTful web-api. Facebook is PHP and C++ based as far as I know and how many webapps consume it's services through api. SO I don't think it's a bad idea. The question is how you implement this webservice. Meaning, do you want to use it once and then get rid of it or sue it for a long time. If the second option is true - make sure you design your webservice api with that in mind. Also PHP can easily consume XML-RPC and SOAP. I used both ( provided by a Perl based service) without any problem or big hits on performance.

I think using .NET to migrate from PHP is not the smartest choice - but that is somewhat subjective opinion. In my experience it almost always ended being an overkill, badly designed, more expensive to maintain and more buggy - because of the nature of the beast.

P.S.: I'm not a PHP fan, but I don't believe in converting to .NET for the sake of converting. Also .NET infrastructure is more expensive to maintain and much more labor intensive.

The primary advantage of a webservice is its interoperability, or ability to be consumed by others independent of language. PHP should have something that allows it to consume webservices so that shou;dn't be too big of a deal. The disadvantage will be that it may be a little slower, but this is something you'd have to test out to see how much of an impact that has on your overall solution. Generally most solutions aren't inherently right or wrong, you have to test their usefulness to your particular circumstance.

PHP can consume .NET web services fine, as long as you stay away from WSHTTP based web services and use BASIC HTTP. You can secure BASIC HTTP web services with SSL for security.

WHen you are in Visual Studio 2008, and you have an ASP.NET (could be MVC or not, doesn't matter) project open, right click on the project and select "Add New Item." You will see see something under Web, called Web Service. This will create a .asmx file and you can find tutorials on how to create these basic web services.

Another alternative is to use Windows Communication Foundation, which has a lot of helpful classes, but it can be more complicated. The default configuration for a WCF service is WSHTTP, but it is possible to make a BASIC HTTP web service with the WCF too.

Not really much of a problem at all, just investigate your options.

Web Services can output data in a wide variety of formats. SOAP/XML are the default but there is no reason why you can't do YML, Xml serialized objects, or my current favorite JSON (which makes calling into it from a browser really easy).

Look also into WCF services, I believe they're supposed to supplant the Web Service format.

Finally, if you're looking for best practices check out Service Oriented Architecture. Its a large and varied field and this is exactly the sort of things they talk about.