Hi all,

Thanks for the many responses, this Is a lot of info! I haven't had the chance to go through all the explained options but I'll do so shortly. I may come back to you later once I've had the time to get my head around it.

Once again, thanks.

Abraham 

On Wednesday, January 9, 2013, Caoilte O'Connor wrote:

It's just a couple of headers, you can add them on the LB proxy.

But I wouldn't recommend CORS unless you don't have to support IE pre v10 (unlikely knowing retail upgrade cycles...).

This has a good cross-compatability matrix.

http://caniuse.com/cors

On Mon, Jan 7, 2013 at 6:34 PM, Kevin Wright <[address removed]> wrote:

Not so.

All you need to do is supply the relevant CORS headers for your service - http://en.wikipedia.org/wiki/Cross-origin_resource_sharing

A few lines of code in a servlet filter will suffice.  It's also available through an easy to use mechanism in a great many frameworks (this is true in the Scala ecosystem, anyway)

Again… This is a domain/url based mechanism, and so will play along very nicely with any DNS-based resource discovery - allowing you to restrict the allowed origins to something less than the entire internet :)

JsonP is neither required, nor recommended.

On 7 January[masked]:02, Peter Reisinger <[address removed]> wrote:

just one think about "rest - easier to access from javascript", keep in mind that if you want to call something from javascript it has to be on the same host (or you would have to use jsonp), so you would need some server side proxy.

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

--

Blogs: http://www.gatogordo.es/ -- http://www.FromFragileToAgile.com/

Twitter: @AbrahamMarin

LinkedIn: http://lnkd.in/TTHC8W

--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])

This message was sent by Kevin Wright ([address removed]) from LJC - London Java Community.
To learn more about Kevin Wright, 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]

--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])

This message was sent by Caoilte O'Connor ([address removed]) from LJC - London Java Community.
To learn more about Caoilte O'Connor, 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]

--

Blogs: http://www.gatogordo.es/ -- http://www.FromFragileToAgile.com/

Twitter: @AbrahamMarin

LinkedIn: http://lnkd.in/TTHC8W

--

Aviso: Se você clicar em "RESPONDER", a sua mensagem será enviada a todos desta mala direta ([address removed])

Esta mensagem foi enviada de Abraham Marín Pérez ([address removed]) do LJC - London Java Community.
Para conhecer melhor o Abraham Marín Pérez, visite o seu perfil de membro

Alterar as notificações da minha lista de discussões para que eu receba os e-mails A medida que forem enviados | Em um único e-mail diariamente | Não quero receber notificações da lista de discussões

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]