Re: [ljc] SOAP web services vs. simpler RESTful
| From: | Kevin W. |
| Sent on: | Sunday, January 6, 2013, 11:22 PM |
I'd definitely avoid SOAP, the overheads of developing against it are insane.
You've made the mistake of conflating service discovery and service implementation. Not entirely your fault, as it's the sort of nonsense that SOAP pushes on people. If you're consuming data in JavaScript then the protocol to use is obvious, think about discovery independently of this.
Just… don't overcomplicate things, even UPnP seems excessive for your needs. As this question on stack overflow shows, even a simple 3-line multicast implementation could work: http://stackoverflow.com/questions/3258959/network-discovery-in-java-using-multicasting
There's also SSDP, JGroups, Bonjour, etc. that operate in this space.
Or... you could simply go for option 2.5, the great granddaddy discovery protocol of them all, DNS. Hardcode a machine name in your code (local, not a fully qualified domain name), then customise the DNS config as required at each site.
Use service records to "do it properly" if you feel there's not enough "engineering" involved here! Either way, it has to be a lot easier to get approved than using hard-coded IPs. This has the obvious advantage of being trivial to use from JavaScript, and not requiring any fragile hacks to pass data from Java discovery code to an embedded web app using e.g. PhoneGap, you could probably get away without needing a native stub at all.
On 6 January[masked]:56, Abraham Marín Pérez <[address removed]> wrote:
Hello everyone,We've been having a bit of an architectural discussion to choose the right technology to implement some web services and I would appreciate any thoughts any of you could have on it. I'll try and explain the scenario as thoroughly as possible and the reasons why we can't decide between the different options, but please do ask if anything isn't clear.We are preparing a new web application for a retail environment, the application won't be accessed by final customers but by shop staff; shop staff will use both a standard PC and a tablet to access the web application.Although most of the information needed by the web app is held centrally and hence it is accessible by the web server, some information is specific to the shop and is stored within other machines in the very shop itself, which means the web application needs some means of local communication. We don't want the central server to know the configuration of each individual shop and we want to avoid manual configuration in each shop, so we're seeking a way in which the web application can automatically find the necessary local services.From here we thought of several options.OPTION 1The in-shop machines offer a web service API and the web application is accessed from a browser that is embedded on a thin, native application. The web application communicates with thin native application (the wrapper) by means of JavaScript, and the wrapper will marshal the calls to the in-shop machines, making the web application independent from the shop configuration. The wrapper finds the in-shop services by means of a discovery protocol, which leads us to two suboptions:SUBOPTION 1.1Web services are implemented in SOAP, which includes a discovery protocol that is handled by the wrapper app.SUBOPTION 1.2Web services are implemented in simpler RESTful (eg a URL get API), and a different technology is used for discovery protocol (like UPnP, also handled by wrapper app). This makes the web services simpler but adds the need of another technology.OPTION 2In-shop machines still offer a web service API, but there will be no wrapper application. Instead, the JavaScript in the web application will participate in the discovery protocol itself and will contact the other local machines. This eliminates the need of a local, native app simplifying deployments, but includes potential CORS conflicts and makes testing a bit trickier. In addition to this, the two suboptions about SOAP or simpler RESTful remain:SUBOPTION 2.1Web services in SOAP, which requires only one technology but may be too complex a protocol to be managed from JavaScriptSUBOPTION 2.2Web services in RESTful, easier to access from JavaScript but then need to implement UPnP or other in JS.OPTION 3Remove the wrapper application and discovery protocol and hard-code the IPs for the local services so these are known by the central web server. This may not render possible since we haven't got confirmation at this point that we can force the same hard-coded IPs in all shops, but assuming it is possible then the same two subtoptions appear.SUBOPTION 3.1Web services in SOAP, maybe a bit of an overkill since discovery is not needed now.SUBOPTION 3.2Web services in RESTful, easier to access from JS but again the potential CORS conflict.I think that's pretty much it, thoughts and comments greatly appreciated.Cheers,
People in this
group are also in:
-
Virtual Java User Group
18,054 vJUGers
-
Data, Cloud and AI in London
8,601 Data Mashers
-
Cloud Native London
8,380 Cloud Natives
-
GDG London
3,175 Members
-
Extreme Tuesday Club (XTC)
2,217 Extremists
-
K8SUG UK
5,814 K8SUGers