Статьи

Лучшие практики на углеродной платформе WSO2

Октябрь 19, 2018

В этом посте обсуждаются лучшие практики программирования на платформе WSO2 Carbon , которая является основой для всех продуктов WSO2 .

Вот основные моменты, обсуждаемые в этом посте:

  1. Не задавайте жестко время компиляции, зависимости времени выполнения и повторно используйте свойства в корневом pom.
  2. Использовать декларативные сервисы OSGI
  3. Не копируйте код вставки, повторно используйте код через OSGI, методы Util и т. Д.
  4. Понимать Multi Tenancy и дизайн для Multi Tenancy
  5. Написать тесты для вашего кода

Эти пункты подробно обсуждаются ниже с указанием причин и HOWTO для каждого пункта. Надеюсь, вы найдете детали полезными, поскольку это длинное (и, вероятно, скучное) чтение.

  1. Не задавайте жестко время компиляции, зависимости времени выполнения и повторно используйте свойства в корневом pom.

Пример:
  
<dependency>
    <groupId>org.json</groupId>
    <artifactId>json</artifactId>
    <version>1.0.0.wso2v1</version>
</dependency>
 
Зачем это делать?

Этого следует избегать, так как это угрожает стабильности сборки. Если в продукт входят две версии одной и той же банки, это может привести к ошибкам, связанным с OSGI, для определения и устранения которых может потребоваться некоторое время.
 
Как этого избежать?
 

Убедитесь, что для корневого pom (components / pom.xml или platform / pom.xml) определена версия зависимости, и используйте ее.

Пример: в платформе / pom.xml

<Orbit.version.json> 2.0.0.wso2v1 </orbit.version.json>
 
Если он не определен, пожалуйста, определите его в корневом разделе и используйте эту версию
 
 
2. Использовать декларативные услуги OSGI
 

Не получать сервисные ссылки в методе активации.
  
ServiceReference serviceReference = componentContext.getBundleContext().getServiceReference(Foo.class.getName());
        if(serviceReference != null){
            Foo = (Foo) componentContext.getBundleContext().getService(serviceReference);
        }
 
Зачем это делать?
 

(Цитируя, Pradeep здесь) Это может привести к ошибочным ситуациям, и вам придется проверить, доступны ли сервисы в цикле while, чтобы заставить его работать должным образом. И это усложняется, когда две или более сервисных ссылок.

Зачем делать все это, когда инфраструктура DS обрабатывает все это для вас.
 
Как этого избежать?
 

Используйте ссылку DS в вашем сервисном компоненте.

Пример:
  

 * @scr.reference name=”foo.comp”
 * interface=”org.wso2.carbon.component.Foo”
 * cardinality=”1..1″ policy=”dynamic” bind=”setFoo”  unbind=”unsetFoo”
protected void setFoo(Foo foo) {
// do whatever ex:
        manager.setFoo(foo);
}
protected void unsetFoo(Foo foo) {
// make sure lose the reference
        manager.setFoo(null);
}
 
3. Не копируйте код вставки, не используйте
 повторно код через OSGI, методы Util и т. Д.
 

Если вам нужна функциональность, предоставляемая другими компонентами, не копируйте код вставки. Найдите другой способ повторно использовать код. Если вам нужно сделать что-то общее, скорее всего, для этого существует метод util или метод osgi. Если не добавить или создать.
 
Зачем это делать?


Это может потребовать определенных усилий и дисциплины, но позже вам (или кому-то еще) придется писать меньше кода. Если изменения произойдут с исходным кодом, вам также нужно будет исправить скопированный код (который часто пропускается).
 
Как это сделать?

я. Используйте утилитарные методы / константы
 

Легко сказать с примером. Пример: чтобы отделить доменное имя от имени пользователя, используйте MultitenantUtils.getTenantDomain (имя пользователя);

То же самое относится и к константам. Пример: MultitenantConstants.SUPER_TENANT_DOMAIN
 
II. Используйте и выставляйте сервисы OSGI
 

Вы можете просто выставить любой класс, который хотите, зарегистрировав сервис OSGI,

пример: в активаторе пакета,
context.getBundleContext().
                        registerService(Foo.class.getName(), new Foo(), null);
Get a reference and re-use as pointed in point 2.
 
4. Понимать Multi Tenancy и дизайн для Multi Tenancy
 

Я чувствую, что некоторые люди не понимают, что означает мульти-аренда (MT). Это важный аспект платформы, и он должен быть не продуманным, а частью дизайна.
 
Зачем это делать?


Создание кода для нескольких арендаторов требует тщательного проектирования. Это может быть не так просто для некоторых случаев. Поэтому размышления об этом после выпуска или когда вы хотите заставить код работать для MT, может потребовать серьезного рефакторинга. Теперь, когда продукты и услуги объединены, многопользовательская аренда вообще не должна быть отдельной.
 
Как это сделать?


Это обширная тема, поэтому я не буду вдаваться в подробности.

Используя AxisConfigurationContextObserver, реестры, осведомленные об арендаторах, представляют собой несколько простых способов, предоставляемых платформой. Если вы зависите от не-MT-зависимости, вам придется выяснить, как заставить ее работать в случае с MT. Вы всегда можете получить помощь от других людей, которые сделали вещи, осведомленные о MT.
5. Напишите тесты для вашего кода

Убедитесь, что вы пишете тесты для своего кода и получаете хороший% покрытия кода. Люди не будут знать, нарушат ли изменения функциональность или нет, пока не станет слишком поздно.
 
Зачем это делать?


Причины очевидны и были изложены многими. Но, повторяя, это делает кодовую базу 
чрезвычайно стабильной . Другие могут изменить ваш код, чтобы исправить ошибки или сделать улучшения, не беспокоясь о нарушении функциональности или фактическом нарушении функциональности.
 
Как это сделать?
 

Я лично предпочитаю юнит-тесты. Но у нас есть интегрированная среда тестирования, а также система тестирования системы (Clarity). Убедитесь, что у вас есть тесты для решения, чтобы охватить большую часть функциональности, если не всю функциональность. Функции не следует считать законченными, без тестового покрытия.

Если вы найдете улучшения по высказанным вопросам, пожалуйста, оставьте комментарий.

35
Share: