Кодирование архитектурного вопроса - PullRequest
3 голосов
/ 31 августа 2009

Я следую некоторым советам о том, как подходить к кодированию проблемы, я не хочу сразу переходить к кодированию, не задумываясь об этом, поскольку мне нужно, чтобы он был как можно более универсальным и настраиваемым,

Сценарий состоит в том, что у меня есть веб-служба, которая действует как шлюз для нисходящих сервисов, с целью аутентификации и авторизации SOAP-сообщений, предназначенных для нисходящих сервисов, что в основном мешает нисходящему сервису делать это самостоятельно. Каждое сообщение SOAP имеет множество различных механизмов WS-Security, к которым обычно присоединяются WS-UsernameToken, WS-Timestamp и подпись XML тела сообщения.

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

Я думал о наличии класса контроллера, который инициализируется и контролирует поток проверки, т.е.

ISecurityController controller = SecurityControllerFacotry.getInstance();
boolean proceed = controller.Validate(soapMessage);

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

public Boolean Validate(Message soapMessage)
{
    return ValidateAuthentication(soapMessage) && ValidateTimeStamp(soapMessage) && ValidateSignture(soapMessage);
}

Будет ли это лучшим средством решения проблемы?

Также было бы лучше поместить каждый из этих методов проверки в свой класс, реализующий общий интерфейс? Так что класс может быть создан и извлечен из какой-либо фабрики проверки, т.е.

IValidationMechanism val = ValidationFactory.getValidationType(ValidationFactory.UsernameToken);
boolean result = val.Validate(soapMessage);

Это дало бы мне легко расширяемый аспект.

Было бы это приемлемым решением или кто-нибудь может придумать другие способы сделать это?

Я разбираюсь в шаблонах проектирования и хороших принципах, поэтому хотел бы пойти по пути, используя их, если это возможно.

Заранее спасибо

Jon

РЕДАКТИРОВАТЬ: служба в основном является службой безопасности шлюза, которая снимает бремя аутентификации и авторизации от служб, которые стоят за ним. Служба безопасности может рассматриваться как неявно вызывающий посредник на пути сообщения SOAP, который проверяет механизмы безопасности в сообщении SOAP и в зависимости от результата проверки направляет сообщение в соответствующую службу нисходящего потока путем опроса заголовков WS-адресации. Хотя сервис на самом деле не является вопросом, это больше о том, как реализовать процедуру проверки.

Ответы [ 3 ]

2 голосов
/ 31 августа 2009

Я думаю, что ваша интуиция хороша; идти с подходом единого интерфейса. То есть скрыть свои реализации валидации за одним интерфейсом валидации; это позволяет вам расширить ваши реализации проверки позже без изменения вызывающего кода.

И да, идея поместить валидацию в свой собственный класс хороша; Вы можете подумать о наличии общего базового класса, если у вас есть какие-либо общие элементы проверки (например, имя пользователя может быть общим элементом проверки, даже если каждая другая схема проверки может кодировать его по-разному: одна как элемент, другая как атрибут и т. д.). Я думаю, что классы валидации являются более подходящим отображением уровня сложности, о котором вы говорите, в отличие от методов валидации; Я подозреваю, что тип проверки, который вы делаете, требует групп методов (то есть классов).

1 голос
/ 01 сентября 2009

Spring имеет универсальный пакет проверки, который хорошо обрабатывает этот тип процессов ИМХО.

Их выглядит как

public interface Validator {
    public boolean supports(Class<?> clazz);
    public void validate(Object o, Errors errors);
}

Конечно, они используют параметр Errors для возврата проблем с проверкой, которые могут или не могут соответствовать вашей цели.

1 голос
/ 01 сентября 2009

Я могу придумать другой способ проверить ваше SOAP-сообщение в сравнении с другими проверками. Вы используете шаблон посетителя.

Для этого у вас будет простая оболочка вокруг получаемого SOAP-сообщения.

     MySoapMessage{
         SOAPMessage soapMessage;
         List<String> validatonErrors;

        void accept(Validator validator){
           validator.isValid(this);
}
         }

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

     SecurityController{
        List<IValidator> validators;

        //Validate the message
       void validate(MySOAPMessage soapMessage){
        forEach(Validator validator: validators){
         soapMessage.isValid(validator)
             }
        }  
  }

Ваши валидаторы будут выглядеть примерно так.

UserNameValidator implements IValidator{
public void validate(MySOAPMessage message){
// Validate and put error if any
}

}

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...