Spudhead
11-17-2005, 01:54 PM
Right. SOAP. I don't really get it. Maybe I'm just looking at it wrong.
Our client has a website. ASP, MS SQLServer backend. Stores membership data, amongst other things. Members can do transactional stuff online, like renew their membership and buy "credits" for various services that the client offers. The client has just brought in a 3rd party solution to manage offline functionality for a sub-group of members. Point-of-sale, swipe card access, stuff like that. This system manages data fields for these members that the online system doesn't need to know about.
This necessitates two databases. Ours; the "main", online members database, and the one that this 3rd-party software uses (which is some sort of proprietary format that isn't ODBC compliant). Obviously if a customer buys credits online, then the offline database needs updating. And vice versa.
We don't know how to do this. The solution that seems easiest is straightfoward HTTP. We've got a server already for the online stuff, we can send and receive HTTP posts. If the other company builds some sort of HTTP library into their software and puts it on a machine with internet access, then we're dancing.
So... we're into HTTP messaging. And we're thinking about what messages we need to send back and forth, and what format we should agree on. And SOAP pops up.
Now, I'm thinking this: if they can send us a HTTP request, all that needs to happen is they call a page on the live webserver with a member ID in the GET or POST data, we do the database stuff and send them a HTTP request with the member's info in the GET or POST data. Right? We can do all of this with WinHTTP in ASP. Why do we need to wrap everything in a SOAP envelope? We don't have any sort of industry standard that we need to adhere to, we just want a closed communication between two servers.
Sorry, most of this is just me thinking out loud. I've got to communicate with a currently-offline, legacy (ie: built in Delphi about 8 years ago :rolleyes: ) system in order to keep two databases in sync. SOAP and Web Services... it all seems like an extra layer of obfuscation. You know where you are with GET and POST :D
Any thoughts? Apart from "that was a long post, why did I bother reading it?" ;)
Our client has a website. ASP, MS SQLServer backend. Stores membership data, amongst other things. Members can do transactional stuff online, like renew their membership and buy "credits" for various services that the client offers. The client has just brought in a 3rd party solution to manage offline functionality for a sub-group of members. Point-of-sale, swipe card access, stuff like that. This system manages data fields for these members that the online system doesn't need to know about.
This necessitates two databases. Ours; the "main", online members database, and the one that this 3rd-party software uses (which is some sort of proprietary format that isn't ODBC compliant). Obviously if a customer buys credits online, then the offline database needs updating. And vice versa.
We don't know how to do this. The solution that seems easiest is straightfoward HTTP. We've got a server already for the online stuff, we can send and receive HTTP posts. If the other company builds some sort of HTTP library into their software and puts it on a machine with internet access, then we're dancing.
So... we're into HTTP messaging. And we're thinking about what messages we need to send back and forth, and what format we should agree on. And SOAP pops up.
Now, I'm thinking this: if they can send us a HTTP request, all that needs to happen is they call a page on the live webserver with a member ID in the GET or POST data, we do the database stuff and send them a HTTP request with the member's info in the GET or POST data. Right? We can do all of this with WinHTTP in ASP. Why do we need to wrap everything in a SOAP envelope? We don't have any sort of industry standard that we need to adhere to, we just want a closed communication between two servers.
Sorry, most of this is just me thinking out loud. I've got to communicate with a currently-offline, legacy (ie: built in Delphi about 8 years ago :rolleyes: ) system in order to keep two databases in sync. SOAP and Web Services... it all seems like an extra layer of obfuscation. You know where you are with GET and POST :D
Any thoughts? Apart from "that was a long post, why did I bother reading it?" ;)