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).
Related
I'm working on a side project where ive decided to expose data with a web api so that when i create the mobile app version of the project I can consume the web services instead of connecting straight to the database.
My questions are: Is this recommended? Will it reduce performance?
I've noticed that now whenever I add new functionality to the NhibernateRepository class I need to create the web api version exposing that data - this takes a little more time.
Also, what about when it comes to more complex queries, shall I just retrieve some of the data straight from the nhibernate queries and some from the web api?
Well "pulling data" directly from your database server it's a terrible idea, managing your connections / repositories / dao or whatever methodology your using from your mobile app would be a more challenging rather than just talking to a rest service.
some advantages of a rest service:
you can put any front end on top of that, that means a web
(javascript front end), mobile, tablet , etc.
you are reusing your code
you are using a thin server approach
you are decoupling your code
you can send json over the wire, your mobile app will be back-end agnostic, so you'll be able to switch your REST service implementation if you want (moving to another programming language) without refactoring you mobile app
take a look to a architecture design named API first probably by reading that you'll get a bigger picture of what I'm talking about.
performance?
well that's a little bit broad assumption, I wouldn't be too worried about that if you have a good / solid architecture design over a decent relationship between traffic / hardware you will be fine.
I'd suggest for you to take a look on servicestack which is a very nice framework out there with a very nice performance 3.9 is free and from 4.0 is a paid version either way using web API or Servicestack are good options the best that you feel more comfortable.
I have been building a console app the uses the Saleforce SOAP API, and now need to use the Salesforce API in a web app.
Am I correct to assume that SOAP is better suited for a non web-based app, and REST is better for a web app?
If I where to create a wrapper that would be used in either reporting from local apps, or posting to salesforce from our websites, should I expose both the REST and SOAP api's, depending on what the app is? Or should I just stick to using one? What are deciding factors I should look at if I just need to pick one?
The other answers contain some good general info, some salesforce specific things to take into account are
1) You can directly bulk update data in the SOAP API, but you'll need to use the Async Bulk API to do that from REST.
2) The soap API contains a few things not available in the REST API, most notably describeLayout, queryAll, getDeleted & getUpdated
3) the REST API contains a few things not available in the SOAP API, including the API for chatter, and access to the recently accessed records lists.
4) the REST API can access binary data (files, attachments, content, etc) without the overhead of base64 encoding/decoding.
So, depending on exactly what your app is trying to do may push you one way or the other.
I believe it ends up being personal preference if you're consuming it by a .NET application, regardless of whether it's a web app or not.
Personally, I would go with SOAP as .NET has a lot of built in functionality to consume a SOAP service, it builds all the method prototypes for you and will make development faster than you handcrafting REST requests yourself. .NET will take care of the marshalling of SOAP.
As for building a wrapper, you have to consider your target audience, if your target audience is other .NET application developers, then exposing your own WCF service might be a decent option, WCF also has endpoints for either SOAP or REST.
IMHO, if you are developing the solution from .NET as your question indicates, SOAP is the way to go. REST services are beneficial because they lack the bulk and tool set requirements that surround SOAP and are nice for the bootstrap developer without access to heavy investment tools like .NET. I agree with the other comments that REST more closely mirrors the underlying HTTP methodology, and is easier to read and parse explicitly, but that isn't really something you have to concern yourself with from within a tool like VS and .NET.
Additionally, since you have existing console apps that may be brought into the communication mix at some point, it might be good to have the WCF flexibility to be transport agnostic and not tied to HTTP as you would be with REST.
So I really don't think you are in a position to take advantage of the REST advantages or be impacted by the shortcomings of SOAP, so it makes sense to go with the heavily standardized option that fits best into your existing tool set.
The decision to use REST or SOAP when both are available is usually related to:
The tools and language you're using for your application
Your familiarity with either style
The performance needs of your application (JSON payloads are smaller than XML payloads)
If the 'local' apps are calling the services from the server side, then all else being equal, you can at least generate C# code directly from the WSDL and that makes using the SOAP API simpler (no hand coding).
If the web application needs to call the API directly from the client side (browser), then use REST and work with JSON. This will be far simpler. You wouldn't be able to reuse the same wrapper regardless, so no problem using two different APIs other than the time it takes to learn them.
If the web app usage of the API is on the server (not client) side, then definitely target just a single API. WSDL if you want to auto-generate the code to call it, REST otherwise for simplicity and efficiency.
IMO, SOAP was a standard created as a contract type messaging architect, I.e. When passing messages just use this "contract." It was generic enough that it doesn't embrace any particular technology.
REST is a actual methodology that embraces HTTP, it is a way of utilizing GET, POST, PUT and DELETE to it's max potential.
I wouldn't assume one is better then the other, what it really boils down to is using the right tool for the job. I wouldn't make a distinction between web-based app and non web-based. Because SOAP or REST can be beneficial to both.
Here are a few questions I would get answered first:
1) Who is my target client. Microsoft Workshop Client, Java, PHP type.
2) What types of (Lack of a better term.) "Endpoints" do I want to expose to my Api. (JSON, XML, Ajax, POX or all of the above.)
3) What will my clients be going with this API? Do they already have clients that are based on SOAP. If so, SOAP is the way to go.
4) REST will makes you think about your URL design and thus allowing a client to "mashup" data to build what they need. So if you think that's something you want. REST is the way to go.
5) REST makes use of the "GET" in HTTP, this allows a client to cache results. "Conditional GET is what it's called. It allows them to cache a big object, ask the server via just a header (small) if the last update matches what is cached, if so. don't bother with a full object GET, what is cached is the latest version. This can be done in SOAP, but out of the box, REST is better for this.
Anyway, hopefully that gives you the better data, so you can make the better decision. And if all else fails you can just do both. But then you'll have to deal with trying to get two types of services (different methodologies) and one codebase for both. (can be tricky, but not that difficult.)
Personally. I would pick one, then if you ever need the other, burn that bridge and pay the technical debt for it.
Late to this party, but just a quick note:
The Salesforce API isn't completely RESTful: I would call it REST-ish. It has SQL-like queries in URLs for some of its REST interface, that sort of thing.
SOAP API:
What is it for? Integrating your organization’s data with other applications using SOAP.
When to use it? You have pre-existing middleware services that need to work with WSDLs and XML data.
Protocol SOAP/WSDL
Data format XML
Communication Synchronous
REST API:
What is it for? Accessing objects in your organization using REST.
When to use it? You want to leverage the REST architecture to integrate with your organization.
No WSDL requirement.
Well-suited for browser-based applications, mobile apps, and highly-interactive social applications.
Protocol REST
Data format JSON, XML
Communication Synchronous
I am writing an application that fetches data from MS AX Dynamics once-in-a-very-long-while
The issue with AX (or with the company I am working for) is that AX does not allow cross domains connections.
Currently, we have 2 domains country1.company.com and country2.company.com on our Active Directory (AD) and the application is intended to run on both domains but AX is on country1.company.com. In fact, all country2 users RDP to country1 when they need to work on AX and it is terribly slow given our geographic distances.
To overcome this problem, I am thinking of writing a separate (console) program that runs at country1 such that users can send the data to it and let it query AX and return the results over the network.
The big question is:
Do I have to write the application like a client server thing or can i ride on existing windows features to acheive the same thing? Since I have zero network programming experience, I hope I dont have to go that way.... thanks in advance for any suggestions.
Instead of writing a console app and sockets, you should make use of WCF classes. Yes, it is networking, but anything that talks to any other computer is. You probably want to set up a WCF web service for this kind of feature. Here's a nice starter app as an example.
You can use thrift Link.
It enables efficient and reliable communication across programming languages and also .
You just need to define the data structures and service interface in an IDL file. Link
Then use the thrift compiler to generate the RPC and data serialization code in one of the supported programming language of your choice.
With that you are equipped with the infrastructure needed for serializing your data and RPC. Now you can just focus on your business logic.
P.S: This is not a windows feature though.
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.
I've started with Flex recently, I've noticed that some plugin for Visual Studio exist, instead of buying a licence for another program (Flex Builder).
I was wondering how I could manage to remotely connect to my database with a Flash/Flex application with the help of C#/Asp.Net.
If I've correctly understood what I've read in the last few days, there is basically no way to 'query' to a database with Flex 3. So I suppose there is another way by using a webservice in C# on the database server that would respond to the Http query from Flex.
Am I right or totally of the track? If you have any other thoughts about this, please share.
I prefer (and recommend) using Webservices for the communication between Flex and C#. It's easy to use, and they both support serialization, so you can easily transfer Strong-Typed Objects. More on Flex and .NET can be found at http://www.adobe.com/devnet/flex/flex_net.html
Alternatively, you could consider using WebORB. This program functions as a gateway between and Flex, and enables you to use the Flash RemoteObject API for the communication to C#. More on this can be found at http://www.adobe.com/devnet/flex/articles/flextodotnet_remoteobject.html.
You really should consider using FluorineFx.
It takes about 5 minutes to set up an will allow Flex to call your methods like a service. You can then pass classes back and forth from .NET to Flex and back.
It's also the standard form of communication by Adobe, it's free and it's super fast.
Your understanding is correct. Flex is intended for developing client-side applications, and communication with a database is done through a server-side application.
Pretty much the same as building a JavaScript application. Though, Flex has several additional options for communicating with the backend. Webservices are great in a lot of cases, but the other options are worth looking into.
Here's a pretty happening article on the topic, if you haven't already seen it.
http://www.dehats.com/drupal/?q=node/33