SVN

SVN
Надеюсь что такое svn вы знаете. Не лишним было бы помнить такие основные комманды как:
svn checkout - создать рабочую копию, получив текущую ревизию с сервера.
svn update - обновить рабочую копию с сервера (получить изменения). Помним про автоматический мердж и конфликты.
svn diff - посмотреть внесённые изменения в вашу рабочую копию.
svn commit - отправить изменения на сервер, при этом будет создана новая ревизия.

svn add - добавить файл в рабочую копию. При commit файл будет отправлен на сервер.
svn rm - удалить файл из рабочей копии. При commit файл будет удалён из текущей ревизии на сервере.
svn mv - переместить файл внутри репозитория.
svn revert - откатить изменения в файле из рабочей копии.

SOLID

SOLID

Single Responsibility Principle
Не должно существовать более одного мотива для изменения данного класса. Говорит о том, что на каждый класс должна быть возложена только одна определенная обязанность.

Open/Closed Principle
Нужно избегать случаев, когда появление новых требований к функциональности влечет за собой модификацию существующей логики, стараясь реализовать возможность ее расширения.

Liskov Substitution Principle
Наследующий класс должен дополнять, а не замещать поведение базового класса.

Interface Segregation Principle
Клиент не должен вынужденно зависеть от элементов интерфейса, которые он не использует. Говорит о том, что лучше иметь множество специализированых интерфейсов, чем один универсальный.

Dependency Inversion Principle
Абстракции не должны зависеть от деталей, в то время как детали должны зависеть от абстракций.

JPA

JPA – это технология, обеспечивающая объектно-реляционное отображение простых JAVA объектов и предоставляющая API для сохранения, получения и управления такими объектами.

JPA – это спецификация (документ, утвержденный как стандарт, описывающий все аспекты технологии), часть EJB3 спецификации.

Сам JPA не умеет ни сохранять, ни управлять объектами, JPA только определяет правила игры: как что-то будет действовать. JPA также определяет интерфейсы, которые должны будут быть реализованы провайдерами. Плюс к этому JPA определяет правила о том, как должны описываться метаданные отображения и о том, как должны работать провайдеры. Дальше, каждый провайдер, реализуя JPA определяет получение, сохранение и управление объектами. У каждого провайдера реализация разная.

Реализации JPA:

  • Hibernate
  • Oracle TopLink
  • Apache OpenJPA

JPA состоит из трех основных пунктов:

  1. API – интерфейсы в пакете javax.persistance. Набор интерфейсов, которые позволяют организовать взаимодействие с ORM провайдером.
  2. JPQL – объектный язык запросов. Очень похож на SQL, но запросы выполняются к объектам.
  3. Metadata – аннотации над объектами. Набор аннотаций, которыми мы описываем метаданные отображения. Тогда уже JPA знает какой объект в какую таблицу нужно сохранить. Метаданные можно описывать двумя способами: XML-файлом или через аннотации.

SOAP

SOAP - Simple Object ACCESS PROTOCOL
  1. SOAP – это целое семейство протоколов и стандартов, откуда напрямую вытекает, что это более тяжеловесный и сложный вариант с точки зрения машинной обработки. Поэтому REST работает быстрее.
  2. SOAP используют HTTP как транспортный протокол, в то время как REST базируется на нем. Это означает, что все существующие наработки на базе протокола HTTP, такие как кеширование на уровне сервера, масштабирование, продолжают так же работать в REST архитектуре, а для SOAP необходимо искать другие средства. 
  3. Есть мнение, что разработка RESTful сервисов намного проще. Наверное, это правда, если использовать Notepad в качестве основной среды разработки, но вот с использованием наших чудесных средств разработки, я позволю себе усомниться в верности этого утверждения.
  4. В первом гугловском результате по запросу «REST vs SOAP» акцентируется внимание на том, что ответ REST может быть представлен в различных форматах, а SOAP привязан к XML. Это действительно важный фактор, достаточно представить себе вызов сервиса из javascript, ответ на который мы определенно хотим получать в JSON.
  5. «REST vs SOAP» можно перефразировать в «Простота vs Стандарты», что проявляется в том, что для SOAP мы имеем протокол WSDL для исчерпывающего описания веб-сервиса, который с использованием все тех же чудесных средств разработки прото-таки волшебным образом делает почти всю работу за нас. Со стороны REST мы имеем загадочный и неиспользуемый протокол WADL, который, в принципе, и не нужен – он мешает простоте.
  6. Второй аспект предыдущего пункта – обработка ошибок. В SOAP она полностью стандартизована, а REST может использовать давно известные коды ошибок HTTP (если здесь Вас посетила мысль, что это же очевидно и зачем я это пишу, то значит Вы внимательно читаете статью).
  7. То, с чего можно было бы начать, но я припас напоследок. Это одна из ключевых мыслей. SOAP работает с операциями, а REST – с ресурсами. Этот факт в совокупности с отсутствием клиентского состояния у RESTful сервисов приводит нас к тому, что такие вещи как транзакции или другая сложная логика должна реализовываться «SOAP-но».
Веб-сервис(endpoint) — содержит всю логику с которой вы будете работать, именно через него активируются запросы в базу данных, обработка данных и т.д.
Паблишер(publisher) — сервис который загружает веб-сервис в сеть для общего к нему доступа.
Клиент(client) — сервис который обращается к веб-сервису для получения того или иного результата.
Пишем наш веб-сервис.
Для начала нам надо сделать интерфейс который описывает скелет будущей функциональности веб-сервиса:
1
2
3
4
5
6
7
8
9
10
11
12
13
package dev.bay.ws;
import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
@WebService
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT)
public interface SayHello {
    @WebMethod
    String hi();
}
Как вы можете видеть, это интерфейс похож на сотни других, веб-сервисом его делают аннотации, которые мы к нему дописали. Основной аннотацией является @WebService, именно указывает что интерфейс на который мы смотрим является веб-сервисом. Аннотация @SoapBinding служит для определения к какому стилю принадлежит веб-сервис и как он отображается в wsdl файл. Style=Document/Use=Literal является стандартными параметрами и когда вы будете писать свои собственные веб-сервисы и вас будут удовлетворять стандартные установки, вам не надо будет это прописывать. Аннотация @WebMethod служит для корректного отображения метода в wsdl(xml-подобные формат в в который отображаются веб-сервисы) файле. @WebMethod содержит такие аргументы: perationName — отвечает за имя операции, action — этот атрибут отвечает за значения поля soapAction (стандартным значением этого атрибута является пустая строка), exclude — определяет должен ли метод отображаться в wsdl файле или нет.
Теперь пилим реализацию нашего веб-сервиса.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
package dev.bay.ws;
import javax.jws.WebService;
@WebService(endpointInterface = "dev.bay.ws.SayHello")
public class SayHelloImpl implements SayHello{
    @Override
    public String hi() {
        return "Hey there, sweety!";
    }
    @Override
    public void printOut() {
        System.out.println("Is that what you wanted to see?");
    }
}
Демон — он в деталях, обратите внимание на уже знакомую аннотацию @WebService, но смысл ее кардинально иной за счет атрибута endpointInterface = «dev.bay.ws.SayHello», этот атрибут говорит нам, что этой реализации отвечает имеет этот веб-сервис.
Согласно нашей небольшой диаграмме представленной в начале статьи, мы уже знаем, что после того как мы заполучили сервис, нам надо его запустить для общего доступа в сеть иначе смысла в нем немного. Для этого нам нужен паблишер.
1
2
3
4
5
6
7
8
9
10
11
12
13
package dev.bay.ws.publisher;
import dev.bay.ws.SayHelloImpl;
import dev.bay.ws.SayRPCImpl;
import javax.xml.ws.Endpoint;
public class Publisher {
    public static void main(String[] args) {
        Endpoint.publish("http://localhost:9999/ws/hello", new SayHelloImpl());       
    }
}
Вас может удивить простота приведенного выше кода, но не обольщайтесь, это самая примитивная реализация и обычно функцию паблишинга берет на себя сервлет контейнер. http://localhost:9999/ws/hello — это url на который будет запаблишен наш веб-сервис (мы его прописываем сами).
После того как вы запаблишили наш веб-сервис нам надо к нему как-то стучаться, для этого пишем клиент.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
package dev.bay.ws.client;
import dev.bay.ws.SayHello;
import javax.xml.namespace.QName;
import javax.xml.ws.Service;
import java.net.MalformedURLException;
import java.net.URL;
public class Client {
    public static void main(String[] args) throws MalformedURLException {
        URL url = new URL("http://localhost:9999/ws/hello?wsdl");
        QName name = new QName("http://ws.bay.dev/","SayHelloImplService");
        Service service = Service.create(url,name);
        SayHello sayHello = service.getPort(SayHello.class);
        System.out.println(sayHello.hi());
    }
}
Первостепенная задача клиента — это достучаться до веб-сервиса. Поскольку наш веб-сервис уже имеет адресс в сети(http://localhost:9999/ws/hello) мы его и прописываем. Первая непонятная деталь состоит в приписке к нашему url адресу: ?wsdl. Не поленитесь и зайдите по этому адресу, то что вы увидите и есть наш wsdl файл который является точным отображением нашего веб-сервиса в xml-формате. Дальше идет QName, откуда мы берем значение для него? Ответ мы найдем в wsdl файле который мы только что просматривали. Обратите внимание на атрибуты targetNamespace=»http://ws.bay.dev/»и на соседний с ним атрибут name=»SayHelloImplService».
И так, алгоритм запуска приложения:
1) Запускаем паблишер;
2) Запускаем клиент.
При удачном исходе, в консоле клиента мы должны получить следующее: «Hey there, sweety!».
Все, успех!;)