конфигурация сервера worklight — разделение адаптеров и сервера

Вопрос из двух частей. Общий вопрос о функции конфигурации сервера, а затем возможные последствия для того, что мы хотели бы сделать.

В файле свойств Worklight есть записи publicWorklightHostname, publicWorklightPort, publicWorklightProtocol. Отдельные приложения также указывают почти такую ​​же информацию в дескрипторе приложения. Понятно, что приложениям нужна информация дескриптора, чтобы «найти» сервер. Для какой цели служат соответствующие записи в worklight.properties? Я считаю, что эти два должны совпадать.

У нас есть сценарий, в котором нам нужно развернуть наши адаптеры на определенной машине, поскольку только она имеет подключение к нашим бэкендам. В идеале мы хотели бы, чтобы каждый разработчик разрабатывал приложения, использующие эти адаптеры. Каждый разработчик развертывал свои приложения на собственном WL-сервере. Я надеялся, что, настроив дескриптор приложения, приложения будут использовать сервер общего адаптера для своих вызовов сервера. Кажется, это не работает, Worklight, по-видимому, возражает против использования своих адаптеров таким образом, что имеет смысл с точки зрения безопасности. Можно ли заставить наш подход работать?


testing ibm-mobilefirst worklight-server
person djna    schedule 17.06.2013    source источник
comment
djna, ответ ниже на ваш вопрос?   -  person Idan Adar    schedule 16.07.2013
comment
Идан, я занимаюсь настройкой некоторых автоматизированных сборок, которые, я надеюсь, позволят мне проверить это на практике. Однако я не уверен, что сценарий, который вы описываете, соответствует потребности в эффективном общем сервисе - я думаю, что каждому разработчику в конечном итоге понадобится свой собственный след на сервере, что будет возможно в версии 6.0; Я бы предпочел иметь один общий сервер адаптеров.   -  person djna    schedule 17.07.2013
comment
@dnja, твой вопрос решен?   -  person Idan Adar    schedule 14.03.2014

Ответы (1)


arrow_upward
2
arrow_downward

  • Свойства, находящиеся в worklight.properties, относятся к серверу Worklight. Упомянутые вами свойства: publicWorklightHostname, publicWorklightPort, publicWorklightProtocol необходимы, потому что сам сервер должен знать, каков его URL-адрес для внешнего мира, чтобы он мог встраивать его в перенаправления и тому подобное. Они также необходимы для среды Mobile Web, Desktop Browser и Worklight Console.

  • Свойства, содержащиеся в файле application-descriptor.xml, относятся (в основном, не все) к приложению Worklight. Как вы упомянули, приложение должно знать, к какому серверу Worklight подключаться.

  • Некоторые свойства «перекрываются» и должны совпадать (хост, порт, корень контекста, ...) для правильного поведения.


Что касается вашего сценария - я думаю, что он работоспособен.

Чтобы это работало, файл .war, который вы развернете на сервере Worklight, в котором размещены адаптеры, должен содержать файл authenticationConfig.xml, способный удовлетворить потребности приложений различных проектов, то есть содержать все необходимые области. и т. д. для всех приложений.

Имея в виду вышеизложенное:

  1. Настройте файл application-descriptor.xml так, чтобы он указывал на сервер Worklight, на котором размещены адаптеры.
  2. Подключитесь к консоли Worklight этого сервера Worklight и разверните сгенерированные файлы .wlapp приложений. Это необходимо для того, чтобы приложения распознавались сервером Worklight.

Теперь приложения должны иметь возможность подключаться к серверу и использовать адаптеры.
Также предполагается, что эти адаптеры также являются частью того же проекта, в котором размещены приложения.

Примечания:

  1. После каждой локальной сборки, которую сделает разработчик, ему/ей потребуется повторно развернуть .wlapp на удаленном сервере, потому что chceksum приложения изменился, и без повторного развертывания вы всегда будете получать запрос на прямое обновление.
  2. Альтернативой (1) является отключение прямого обновления.
  3. Если у вас есть код Java (например, для пользовательской аутентификации) и вы вносите в него изменения, вам также потребуется повторно развернуть файл .war на удаленном сервере.


Примечание 2:

  • В Worklight 6.0 упомянутого перекрытия в свойствах подключения к серверу между файлами worklight.properties и application-descriptor.xml больше нет.

  • В Worklight 6.0 теперь вы можете одновременно запускать несколько проектов Worklight (или файлов .war) на одном экземпляре сервера, поэтому, хотя адаптеры по-прежнему являются сущностями для каждого проекта, вы можете дублировать их в отдельных проектах на одном и том же сервере. Worklight Server и иметь несколько отдельных проектов (приложений), использующих этот сервер для подключения к серверной части.

person Idan Adar    schedule 18.06.2013