Need options for custom Windows web service that can receive requests from PHP on Linux
I typically work on Windows development using Visual Studio and Microsoft Dynamics GP.
I have a client that would like to integrate their operational system (order taking and CC capture) with Dynamics GP.
However, their operational system is a custom web site that uses PHP on Linux. My understanding is that PHP on Linux cannot call COM, so I'm now thinking that we will need to have a Windows web service that will accept requests from the PHP / Linux web site.
The Windows web service will initially only need to support two different calls from the Linux machine, but they may add a few more over time. I'm thinking that the Windows web service will simply be a wrapper for the underlying Dynamics GP APIs that need to be called.
While I've done development to make calls to and integrate with an existing web services, I have not developed custom web services from scratch. I can spell REST and SOAP, but that's about it.
While I'm assuming it's not too hard to open Visual Studio and develop a basic web service to support the two or three integration calls we need, because this involves credit card data, the solution will need to have strong authentication and security between the Linux and Windows environments, preferably using a standards based implementation / protocols, etc. And I'm concerned about possible compatibility issues between PHP on Linux and the Windows web service.
I'm basically looking for any initial guidance as to development tools, product offerings, approach, etc.
I have a client that would like to integrate their operational system (order taking and CC capture) with Dynamics GP.
However, their operational system is a custom web site that uses PHP on Linux. My understanding is that PHP on Linux cannot call COM, so I'm now thinking that we will need to have a Windows web service that will accept requests from the PHP / Linux web site.
The Windows web service will initially only need to support two different calls from the Linux machine, but they may add a few more over time. I'm thinking that the Windows web service will simply be a wrapper for the underlying Dynamics GP APIs that need to be called.
While I've done development to make calls to and integrate with an existing web services, I have not developed custom web services from scratch. I can spell REST and SOAP, but that's about it.
While I'm assuming it's not too hard to open Visual Studio and develop a basic web service to support the two or three integration calls we need, because this involves credit card data, the solution will need to have strong authentication and security between the Linux and Windows environments, preferably using a standards based implementation / protocols, etc. And I'm concerned about possible compatibility issues between PHP on Linux and the Windows web service.
I'm basically looking for any initial guidance as to development tools, product offerings, approach, etc.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I don't know anything about OAuth. I do know that payment gateways like Paypal and Authorize.Net use API and identity keys that are passed as part of the POST data. If you are using 'https', I think that is just as secure as username and password. Paypal is a pain because they turned it into a multi-step process to complete a transaction. That's for the Express checkout for a shopping cart. Makes it more difficult to break in to but you probably won't need that on an internal network.
ASKER
"If you are using 'https', I think that is just as secure as username and password."
Sorry, I completely disagree with that statement. HTTPS has nothing to do with authentication.
Sorry, I completely disagree with that statement. HTTPS has nothing to do with authentication.
You're right, "HTTPS has nothing to do with authentication." 'https' is normally used on login pages to make it more difficult to steal the usernames and passwords from the network.
I was referring to using API keys in place of username and password. They are effectively the same thing as long as they are unique for each account. At least Paypal and Authorize.net think so. And passing the keys in the POST data means you don't have to make a separate request to 'login'. Your 'authentication' is sent with the data.
And you can take it a step further and only accept requests from a single IP address and/or referrer.
PS: On another question, I was reminded that you can also use a non-standard port to make it even less likely that someone else will connect to your 'web service'. You would want to pick a port above 1024 and make sure it is not being used for something else on your network.
I was referring to using API keys in place of username and password. They are effectively the same thing as long as they are unique for each account. At least Paypal and Authorize.net think so. And passing the keys in the POST data means you don't have to make a separate request to 'login'. Your 'authentication' is sent with the data.
And you can take it a step further and only accept requests from a single IP address and/or referrer.
PS: On another question, I was reminded that you can also use a non-standard port to make it even less likely that someone else will connect to your 'web service'. You would want to pick a port above 1024 and make sure it is not being used for something else on your network.
ASKER
What about authentication? I see some discussion of OAuth.
Since the communication will be between two internal corporate servers, some type of key would be okay vs. a password.