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 services 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.
Related
In .Net, I think about a web service as being a project type that you select from the menu, define your classes and methods then .Net does all this black magic under the hood to allow someone on the other side of the world to reference my web service and start coding using my classes and methods directly within their visual studio.
So having this preconceived notion, when looking at writing REST web services using MVC 3 (I know MVC 4 has a REST api baked in but am waiting for a full release) I'm wondering all the usual stuff like "is this a good idea", "will this stand up to heavy use" and "am I just writing toy web services that other developers will laugh at".
Now I think a lot of my anxiety is probably down to microsoft not having wrapped a big, overly complicated, bloated, shiny REST package around it yet. So I'm looking to have my anxiety relieved hopefully by people telling me yes MVC web services are perfectly good things to create.
Any help?
I've done it a few times, I am still using it in production and haven't got any complaints.
I actually think its a nice solution because it so simple to setup and maintain.
Not this incredibly xml-configuration-heavy wcf stuff..
You might want to also have a look at the WebAPI stuff that is in the process of being released (.net 4.5):
http://weblogs.asp.net/scottgu/archive/2012/02/23/asp-net-web-api-part-1.aspx
It's very much to do with exposing plain html services.
I would suggest you take a look at ServiceStack: http://www.servicestack.net/. It 's not only quite mature, but it can help you produce cleaner code.
It really does depend on what you plan on doing with your application. Yes, you could write an MVC website that doubles as a RESTful service. However, you are then tying your UI layer very closely to your logic layer, and that is what you really need to consider. I am working on an MVC site with a ServiceStack REST service (already mentioned by #Ioannis) . The reason that I did not make MVC my REST service is because I did not want any changes in my UI to potentially affect any third party application that might be using my logic service. So, as long as you carefully consider the ramifications of making your site also your RESTful service, then either decision could be ok. :)
As others have mentioned here, ServiceStack provides a solid, terse REST Web Services Framework allowing you to effortlessly develop typed, idiomatic C# API's end-to-end.
ServiceStack also includes a number of high-performance components that deeply integrates with ASP.NET MVC using the ServiceStack.Host.Mvc NuGet package.
To learn more about the benefits ServiceStack can add to your MVC project see:
http://www.servicestack.net/mvc-powerpack/
I am a c++ developer and need insight with current project...
I have a C# .net application that I want to securely connect to a mysql database
I have a sql database created and have created a "webservice" using php that I supposedly can connect to and through that it will access my sql database
but Need some insight into how to talk to this php code
Also would like to hear thoughts on this metholidgy ... is this best practices for doing this? (most secure, fastest, what about hundreds (thousands?) of users accessing a database will this hold up?)
My end result is to have this run on mobile platforms (android, ios) using Unity3D
I am trying to get the basic running using .net 3.5 c# so I understand it before I have to port it to mobile platform and the .net subset with unity
If someone would help me outside of the scope of answering these questions, I am always willing to pay to get this figured out
A great choice that would be very easy to implement in PHP and C#, as a bridge, would be Web Services built using JSON as the interchange format.
This looks like a good basic introduction for a JSON PHP Web Service.
This is another in C#.
With a neutral interchange format you should be able to connect the two components with ease.
I prefer to use JSON.NET and it works really well with JSON object serialization. Though JSON serialization is built into the core framework now (since .NET 3.5).
+1 on using JSON, but only if actually needed.
You can treat 'talking' to the php code as any other webservice. Create your api on the server side (ie. what the scripts do, what params they need), then forget the implementation when writing the client code.
Think about security. If you'll be exchanging sensitive information, you may want to encrypt it. So... SSL.
Do you have user-specific data? You may want some kind authentication.
One easy solution, if you're an optimist, may be to use a private salt and hash your parameters to make sure requests are coming from code you have distributed. However, this won't stop one user to pose as another.
As for scaling, it all depends on just how many calls you do, how many concurrent users you have etc., only you can estimate this stuff. Getting a cloud account would be good. Set up everything on one box at first. As traffic increases, move the database on a new node, then add a webserver, a master-slave setup, a load balancer..etc.
I think it's a nice approach, just be very careful with authentication and security. Performance shouldn't be an issue as long as you optimize the access to the database (performant queries, caching on the client and the service if necessary).
As for the web service consuming in C#, you should use service references for SOAP web services, or HttpWebRequest for REST web services.
For more information on the subject, this kind of architectures are called Service Oriented Architectures (SOA).
I'm interested in gaining a better understanding of WCF.
Of course, I can read books and tutorials about it, but it seems that a better way would be to actually come up with some project idea (either open-source or a startup) which would actually benefit from using WCF, and then build it using WCF.
What are your ideas for small-scale projects which might benefit from WCF?
I'm not sure it is really a matter of scale that drives a decision to use WCF. If a learning project is all you are interested in, then take a normal idea for a project, and turn the entire data access layer into WCF calls.
This should give you a fair understanding of all the little nooks and crannies of WCF, and allow you to fail in a controlled manner. That way you can make decisions in the future about when are where it is best to apply a service boundary using WCF.
As was already mentioned, anything to do with the web can benefit tremendously from WCF. Heck, you could build a pure JavaScript and HTML 5 application using WCF without ever touching ASP.Net.
A hosted service that a mobile device (such as a WP7 or iPhone) could connect with to retrieve data
WCF is great for setting up non-ASPX endpoints for Ajax clients. See for example this article. There are many more out there.
Any project involving .NET and communication is likely to benefit from WCF. WCF is the replacement for ASMX web services and for .NET Remoting. There's no one particular type of application that it is suited for. For instance, it's not like it's suitable for Enterprise applications but not for small ones.
WCF data contracts are very easy and handy for storing application configuration, settings and state. Write a library/application to take care of serialisation and editing.
While this stems from the age-old debate between Java and .NET, I'm interested in the merits of these two technologies in terms of SOA/web services.
I'm starting a new project writing web services. I don't have extensive experience writing them in either Java or C#, and I'm open to using either a Microsoft stack (running IIS) or a Linux stack (running Tomcat). So far in my research, the complexity of the two languages seems to be about equal.
I'll be running a MySQL database (SQL Server is out of the question). Database access thus has no bearing on the rest of the stack.
I will be consuming REST services (and possibly SOAP as well), and exposing SOAP services.
What are the advantages or disadvantages of these two technologies in terms of ease of use, complexity, typical development time, total cost of ownership (esp. maintenance costs), etc.? Which has better integration to existing security and authentication frameworks (e.g., CAS, LDAP, or OAuth)?
While I am a java proponent and have little C# experience, I will honestly say they will likely be about equal, and you should go with whatever language you are most familiar with and comfortable in programming.
On the Java side, both exposing and consuming web services (SOAP or REST) can be easily done via open source libraries (and there may even be some stuff built into the JDK at this point, although usually they are a bit behind the open source community), one of the most popular being Spring. This will do for you all the complexity and plumbing around creating and consuming SOAP, and exposing or consuming REST.
For SOAP:
For REST:
http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/
http://blog.springsource.com/2009/03/27/rest-in-spring-3-resttemplate/
For SOAP:
http://static.springsource.org/spring-ws/sites/1.5/
Note Spring is just one option (but a good one), but my overall point is don't write the plumbing yourself, choose an existing framework to do it for you and it shouldn't matter what language you use.
As mentioned I don't know much about C# but what I've found is they usually take the good parts of the core JDK and the open source java community and build it into the language, so there may be some nice native stuff in C# that mirrors what Spring has done for Java.
I have been working with webservices for over 2 years now. I have lot to say about services like Soap 1.2, WSDL, the way communication is taking place and 100 of other things.
I have seen people talking about their heavy ASMX background and web services expertize. But, when it comes to implementation I don't find anything but adding a web reference and calling few methods from C#. All the things that we talk about (serialization, deserialization, soap, blah blah) is taken care by Microsoft internally.
So I want to know if it is all we have to do while dealing with WebServices or is there anything more to it?
Rephrase: I wana know what an expert of ASMX must know about these services.
I'll appreciate if you can provide some good references, material or any comments on this.
I think you are approaching this from a implementor/tools standpoint; yes, Visual Studio does a lot of the heavy lifting to make a developer feel like calling Web services is the same as calling any method -- but developers who use the tools blindly without knowing what code is being generated and how it all works are, as you suggest, not experts.
To say you are an expert, I think you would need to be able to talk about things like the following:
Pros and Cons of using services in your architecture (performance considerations, versioning issues, synchronous versus async, etc.)
Reasons you would want to use ASMX versus WCF
Internal implementaiton of the SOAP protocol, how SOAP headers can be used for security, etc.
Knowledge of the "internals", so you could potentially expose services for consumption by non-Microsoft clients (java, etc.)
Features of WSE, including the different versions
Security concerns -- how to secure access to a service, and how to secure the data being transferred back and forth
If you want to consider yourself an expert in ASMX, then you need to understand the SoapExtension class and the related SoapExtensionAttribute. I do not feel that it's necessary to understand SoapExtensionImporter and SoapExtensionReflector.
You should also understand XML Serialization, since that is what is used to serialize and deserialize between objects and SOAP in an ASMX service.
You should also understand that Microsoft now considers ASMX web services to be "legacy technology" (reference on request).
I would say that just knowing ASMX and/WCF basics doesn't make an expert out of you from a web service point of view.
It is true that all the plumbing is taken care of, but you generally have to go back to it at one point or another. It's always very easy to connect asmx to asmx, wcf to wcf, axis2 to axis2... But once you start to make these communicate together, problems start to show. Did you ever worked on a project using web services where at some point you had issues with the generated WSDL, or the generated proxy?
I would say that for someone to claim being asmx expert, he shouldn't look surprised if you start talking about soap 1.1 and 1.2, WS basic profile, WS-*, and all those things that apears to be abstracted away at first sight, but which you'll have to come back to at some point.