align-toparrow-leftarrow-rightbackbellblockcalendarcamerachatcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-crosscrosseditemptyheartfacebookfullheartglobegoogleimagesinstagramlocation-pinmagnifying-glassmailmoremuplabelShape 3 + Rectangle 1outlookpersonplusImported LayersImported LayersImported Layersshieldstartwitteryahoo

Re: [ljc] SOAP web services vs. simpler RESTful

From: Gerald L.
Sent on: Monday, January 7, 2013 3:22 PM
hi Abraham,

you formulate some interesting requirements. I think the crux of the matter is the nature of the interaction between clients, in-shop services and central server, not so much the discovery aspect of it.

I believe that whether that interaction is by webservices or REST is, at this stage, irrelevant. (In general, don't be intimidated by SOAP: support for it on all relevant platforms is near-optimal and it's perfectly easy to use.) Just stay away from UDDI, if that is what you've had in mind when you said "SOAP includes a discovery protocol".

I'd focus on the following questions first (just sketching here in the hope that it might be useful):

1. Is the deployment/roll-out/maintenance of rich client apps at end-user machines (PCs and tables) likely to be a problem? If so, then i'd stick with a pure web frontend. I'll assume this to be the case.

2. What proportion of the interaction is with in-shop vs. central services? How many use cases need central vs. in-shop vs. both services, and how will these be distributed at runtime (i.e., which servers will be hit most). Do the stores have the IT capabilities to maintain their (presumably crucial) in-store services in a reliable fashion (or should as much as possible be hosted centrally and hence reliably)?

3. What is the exact difference between in-shop services at different shops?: Just the location (hostname, IP) of the servers, or (also) their implementation (logic or even language), or (also) their interface (as expressed by a WSDL or REST contract), or (also) how many and what kinds of services are available at what shop? That's crucial, i'd think, and will determine how you tie these in-shop services together into one application. Somehow i can't believe that you'll get by without some store-specific configuration. But, if all stores are expected to run the same services with the same interface at the same port, just at different machines, then a common set of hostnames (as suggested by Kevin) for all stores is a nice, simple solution.

4. Depending on the above, one straightforward architecture could be for each store to host their own appserver and webapp, with each client in that store being just a browser connecting to only that one webapp. That in-store webapp would then need to be configured (or coded to discover) all in-store services and call out to them when needed (intra-store calls). Similarly, the in-store webapp could also call the central server if and when needed - the central server would just be another service (irrelevant if SOAP or REST). In that model, authentication of end-users by the webapp could be done by an in-shop service (against an in-house user store) or a central service (against a central user store that knows all users in all stores) - which is probably also an important question.

The only way to decide this rationally is to think through the exact nature of the dependency and interaction (static and dynamic) between central and in-house resources, request throughput, IT capabilities in the shops, and the like.

I hope i've not missed the nature of your question.

  cheers
  gerald



On Sun, Jan 6, 2013 at 8:56 PM, 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 1

The 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.1

Web services are implemented in SOAP, which includes a discovery protocol that is handled by the wrapper app.

SUBOPTION 1.2

Web 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 2

In-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.1

Web services in SOAP, which requires only one technology but may be too complex a protocol to be managed from JavaScript

SUBOPTION 2.2

Web services in RESTful, easier to access from JavaScript but then need to implement UPnP or other in JS.


OPTION 3

Remove 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.1

Web services in SOAP, maybe a bit of an overkill since discovery is not needed now.

SUBOPTION 3.2

Web 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,
Abraham

--
Twitter: @AbrahamMarin





--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])
This message was sent by Abraham Marín Pérez ([address removed]) from LJC - London Java Community.
To learn more about Abraham Marín Pérez, visit his/her member profile
Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, PO Box 4668 #37895 New York, New York[masked] | [address removed]



--
Gerald Loeffler
mailto:[address removed]
http://www.gerald-loeffler.net

Our Sponsors

  • Our Blog

    Read the latest news from the LJC

  • RecWorks Ltd

    Fixing Tech Recruitment using the Power of Community

  • jClarity

    Java/JVM Performance Analysis Tools & mentoring for Java related matters

  • LJC Aggrity

    Our LJC Aggrity site contains blog posts from our members

  • LJC Book Club

    Our Book club with book reviews from our members

  • Devoxx UK

    Java Community Conference in collaboration with the LJC, 8-10th June 16

  • SkillsMatter

    "Host, help organise, promote, film many of our meetings."

  • IBM

    Build Enterprise-grade apps at start-up speed.

  • New Relic

    New Relic makes sense of billions of metrics a day in real time.

  • Hazelcast

    Hazelcast is the leader in operating in-memory computing.

  • Java.Net

    We are an official Java User Group recognised by Oracle's JUG program

  • JRebel

    Free 3 month J-Rebel license.

  • O'Reilly

    40% discount on printed books and 50% on e-books.

  • Craft Rebellion

    Your choice of fresh craft beer, delivered. For 10% off use ‘LJC'

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy