Архитектура за уебсайт за чат, използващ Openfire, Smack и Play! рамка

Разработвам уебсайт за чат, който използва Openfire XMPP сървъра, като клиентската страна използва Smack API. Уеб проектът, който използва Smack API, е реализиран с помощта на Play! рамка, което го прави RESTful. Избрах Игра! поради своите предложения за асинхронно програмиране (Comet Sockets/WebSockets).

По принцип моята архитектура досега е като по-долу:

Openfire ‹-> Уеб сървър ‹-> Потребител/браузър.

За да поддържам и устройства с Android и да увелича максимално повторното използване на кода, трябва ли да внедря XMPP кода от страна на клиента като RESTful уеб услуга, която е обща както за уеб сайта, така и за клиентите на Android?

Openfire ‹-> Уеб услуга ‹-> Уебсайт ‹-> Браузър/Потребител.

Openfire ‹ -> Уеб услуга ‹ -> Приложение за Android.

Страхувам се от проблеми с мащабируемостта, поради въвеждането на междинна уеб услуга? Ще въведа ли забавяне в комуникацията в резултат на това, че трябва да премина през множество компоненти?

Всеки съвет относно горното би бил полезен. Благодаря.


java web-services playframework openfire smack
person c05mic    schedule 23.09.2012    source източник

Отговори (2)


arrow_upward
4
arrow_downward

Ключът към мащабируемостта е отделянето. Така че по същество можете да мислите за проблема от гледна точка на "Ако един от компонентите се повреди, другите компоненти ще продължат ли да работят нормално?". В допълнение към избягването на сценарии за края на света, можете също така независимо да мащабирате хоризонтално всеки компонент.

Имайки това предвид, нека сега да преминем към вашия конкретен случай на употреба. Слоевете в името на слоевете са това, което все още ме кара да виждам кошмари за някои Java EE архитектури наоколо. Не само въвежда ненужно забавяне, но и затруднява определянето на проблем. Ако услугата ви се провали, повредата причинена ли е от уеб сървъра, Android приложението или уеб услугата?

Ако искате повторно използване на код, използвайте повторно код вместо дублиране на компоненти. За това са библиотеките. Вземете своя общ код и го извлечете като библиотека и го използвайте както в уеб сървъра, така и в приложението за Android.

person Mirko Adari    schedule 30.09.2012

arrow_upward
1
arrow_downward

Мисля, че най-добре е да направите лека уеб страница, която консумира директно уеб услугата (като всяко приложение) от браузъра, след като се зареди.

Така че единствената разлика между приложението и уеб страницата е, че уеб страницата ще се зарежда от браузъра всеки път, когато потребителят влезе в нея.

person Jonathan Barbero    schedule 27.09.2012