Arquitetura para um consumidor de serviços

[javaly]

Olá pessoal como vai?

Novamente aqui para pedir ajuda :). Estou trabalhando na aquitetura e desenvolvimento de um sistema que vai ser cliente de serviços. Esses clientes usarão diferentes tipos de interface, por exemplo, alguns deles terão interface desktop, outros uma interface 3D, outros interface web e possivemmente alguma coisa móvel.

Em muitos dos casos, um mesmo serviço terá seus recursos acessados por mais de uma view de diferentes tipos. A dúvida agora é como arquiteturar as aplicações que acessam esses serviços.

Pensei a princípio em um MVC adaptado, onde teriamos:

V: as interfaces em sí;
C: cada tipo de interface teria o seu controlador; Digo tipo porque imagino que um controlador de uma funcionalidade X do serviço Y deve ser o mesmo para as views que queiram acessar tal funcionalidade.
M: O modeo, onde teríamos, por exemplo, a infra de comunicação com o serviço.

Gostaria de receber sugestões a respeito dessa arquitetura e dicas que possam deixar ela bem robusta.

Preciso de algo que eu possa mudar a view sem muitos problemas, ou que eu possa mudar algo no modelo sem maiores problemas tbm.

PS: Um outro problema que tenho é que em alguns casos, o modelo notifica alguns eventos. Eventos esses que serão notificados pelo serviço. Nesse caso, a View já poderia monitorar diretamente o modelo ou o controlador deveria fazer isso e expor para a view.

Desde já agradeço…

[Giulliano]

Voc~e precisa ter uma interface que receba atributos em comum para todas as views.

por exemplo:

public class GravarCliente{

   public void gravar(String nome, Integer idade){...}

}

e as suas views chamam esse mesmo cara

//Servlet
public class Servlet extends Servlet...{
   doPut(...){
       //pega os atributos, instancia e passa a bola;
       new GravarCliente(...);
   }
}

//WebService
public class WebServices implements Serializable{
   execute(...){
       //pega os atributos, instancia e passa a bola;
       new GravarCliente(...);
   }
}

e por aí vai…basta separar bem a camada de domínio da camada de aplicação que tudo funciona.

[sergiotaborda]

[quote=javaly]Olá pessoal como vai?

Novamente aqui para pedir ajuda :). Estou trabalhando na aquitetura e desenvolvimento de um sistema que vai ser cliente de serviços. Esses clientes usarão diferentes tipos de interface, por exemplo, alguns deles terão interface desktop, outros uma interface 3D, outros interface web e possivemmente alguma coisa móvel.

Em muitos dos casos, um mesmo serviço terá seus recursos acessados por mais de uma view de diferentes tipos. A dúvida agora é como arquiteturar as aplicações que acessam esses serviços.

Pensei a princípio em um MVC adaptado, onde teriamos:
[/quote]

Pior que achar que MVC é camadas ( MVC não é camadas) , é achar que é arquitetura de distribuição…

Pense na aplicação core como vc pensa num banco de dados. Essa é a melhor metáfora.
Encara cada interface como uma aplicação diferente.
Agora junte tudo num sistema só

[Giulliano]

[quote=sergiotaborda]
Pior que achar que MVC é camadas ( MVC não é camadas) , é achar que é arquitetura de distribuição…

Pense na aplicação core como vc pensa num banco de dados. Essa é a melhor metáfora.
Encara cada interface como uma aplicação diferente.
Agora junte tudo num sistema só[/quote]

hahahahah…po cara isto deve ser alguma piada né… ou não soube interpretar texto. Basicamente camada pode ser qualquer coisa…ninguém disse q mvc é uma ou várias camadas…

Pensar em uma aplicação OO como se fosse um banco de dados (este conselho foi de longe um dos mais curiosos que eu já li).

[javaly]

[quote=sergiotaborda][quote=javaly]Olá pessoal como vai?

Novamente aqui para pedir ajuda :). Estou trabalhando na aquitetura e desenvolvimento de um sistema que vai ser cliente de serviços. Esses clientes usarão diferentes tipos de interface, por exemplo, alguns deles terão interface desktop, outros uma interface 3D, outros interface web e possivemmente alguma coisa móvel.

Em muitos dos casos, um mesmo serviço terá seus recursos acessados por mais de uma view de diferentes tipos. A dúvida agora é como arquiteturar as aplicações que acessam esses serviços.

Pensei a princípio em um MVC adaptado, onde teriamos:
[/quote]

Pior que achar que MVC é camadas ( MVC não é camadas) , é achar que é arquitetura de distribuição…

Pense na aplicação core como vc pensa num banco de dados. Essa é a melhor metáfora.
Encara cada interface como uma aplicação diferente.
Agora junte tudo num sistema só[/quote]

Não entendi bem a metáfora Sergio. Mas a idéia não foi de usar o MVC como camadas, nem como arquitetura de distribuição. Foi mesmo de separar as coisas para a implementção ficar mais fácil, possibilitar o reuso e diminuir o acoplamento.

Cada uma das interfaces que vamos fazer não será uma aplicação, serão partes que compõe essa aplicação e teremos várias aplicações plugadas nesse serviço.

Pensamos em conseguir facilidade na implementação por ter um padrão definido.
Pensamos em conseguir reuso porque posso usar meu controlador/modelo de uma determinada interface para uma outra interface da aplicação.
O desacoplamento vem do fato de trabalharmos com interfaces e termos como trocar as implementações em qualquer um dos níveis.

Obrigado por alertar, mas já estavamos pensando assim.

Mais alguma sugestão?

Abraço.

[javaly]

[quote=Giulliano]Voc~e precisa ter uma interface que receba atributos em comum para todas as views.

por exemplo:

public class GravarCliente{

   public void gravar(String nome, Integer idade){...}

}

e as suas views chamam esse mesmo cara

//Servlet
public class Servlet extends Servlet...{
   doPut(...){
       //pega os atributos, instancia e passa a bola;
       new GravarCliente(...);
   }
}

//WebService
public class WebServices implements Serializable{
   execute(...){
       //pega os atributos, instancia e passa a bola;
       new GravarCliente(...);
   }
}

e por aí vai…basta separar bem a camada de domínio da camada de aplicação que tudo funciona.[/quote]

Essa é a idéia. O que muda um pouco é que tenho uma interface para esse controlador e minhas views tem uma ref a essa interface. Se um dia eu quiser mudar de WebService pra Servlet ou vice-versa, vou apenas trocar a implementação. A idéia também é padronizar a forma de acesso a ele.

Obrigado pela ajuda…

[sergiotaborda]

[quote=javaly][quote=sergiotaborda][quote=javaly]Olá pessoal como vai?

Novamente aqui para pedir ajuda :). Estou trabalhando na aquitetura e desenvolvimento de um sistema que vai ser cliente de serviços. Esses clientes usarão diferentes tipos de interface, por exemplo, alguns deles terão interface desktop, outros uma interface 3D, outros interface web e possivemmente alguma coisa móvel.

Em muitos dos casos, um mesmo serviço terá seus recursos acessados por mais de uma view de diferentes tipos. A dúvida agora é como arquiteturar as aplicações que acessam esses serviços.

Pensei a princípio em um MVC adaptado, onde teriamos:
[/quote]

Pior que achar que MVC é camadas ( MVC não é camadas) , é achar que é arquitetura de distribuição…

Pense na aplicação core como vc pensa num banco de dados. Essa é a melhor metáfora.
Encara cada interface como uma aplicação diferente.
Agora junte tudo num sistema só[/quote]

Não entendi bem a metáfora Sergio. Mas a idéia não foi de usar o MVC como camadas, nem como arquitetura de distribuição. Foi mesmo de separar as coisas para a implementção ficar mais fácil, possibilitar o reuso e diminuir o acoplamento.

Cada uma das interfaces que vamos fazer não será uma aplicação, serão partes que compõe essa aplicação e teremos várias aplicações plugadas nesse serviço.
[/quote]

Vc está pensando em interfaces , em classes, como se a comunicação acontecesse apenas através de uma classe. Não é tão simples.
Veja o JDBC. Vc usa várias interfaces para alcançar um objetivo. Por isso que eu disse que vc tem que encarar cada sistema como vc encara o banco nos sistemas normais. Vc tem um conjunto de mecanismos no protocolo, não apenas uma interface simples.

em bom português é o seguinte: pense em Bridge, não em Service.

Pelo que entendi vc terá uma aplicação “core” que serve a todos os tipos de interface gráfica. O que eu disse é que pense em cada interface como uma aplicação completa e não apenas como um conjunto de classes. No meio vc tem um protocolo comum (usando bridge).

A metáfora do banco de dados é esta: um mesmo banco comunica com diferentes aplicações através de um mesmo protocolo.

[javaly]

Então Sergio,

Na verdade, temos um serviço. Ele é o core da nossa aplicação. Nele tem toda a lógica do negócio. Ele nos possibilita realizar operações e também observar algumas coisas.

O que vamos fazer é criar interfaces diferentes para esse nosso serviço. O que chamamos de “aplicações”.

Todas as nossas aplicações tem que comunicar com o serviço e para isso vamos criar um mecanismo base de comunicação.

Agora dentro das aplicações é que entra essa arquitetura que estou tentando definir.

Desde a comunicação base já começo a usar interfaces, pois mesmo o serviço base de comunicação posso trocar caso seja necessário.

Vou passar a idéia novamente para ver se consigo expressar melhor.

Suponhamos que tenho um serviço de Tempo:

Vou criar um modelo de tempo TimeModel que usa o mecanismo de comunicação base (Na verdade, todos os modelos vão usar).

Agora quero expor esse serviço em uma interface (V do MVC):

Então vou criar um ViewTime implements ViewTimeInterface

Essa view vai precisar de um controlador TimeController implements TimeControllerInterface (C do MVC)

Esse controle vai ter um model que poderia já ser o TimeModel diretamente. Mas não vamos fazer assim.

Vamos criar um Model implements ModelInterface único (M do MVC) para aquela aplicação que disponibilizaria o TimeModel e coisas de outros modelos relevantes para aquela aplicação em sí.

Nesse caso, por mais que meu modelo de tempo tivesse N coisas, o model dessa aplicação poderia expor apenas a hora atual em alguns formatos.

Dessa forma espero portar meus modelos reais, como o TimeModel, para os modelos que estaram em aplicações diferentes.

Agora dentro de uma mesma aplicação, posso querer trocar a implementação de uma determinada View, ou Controller… Como temos muitos clientes do mesmo negócio e em muitos casos eles acabam pedindo as mesmas informações, só que de uma forma ou volume diferente, achamos isso necessário e por isso das Interfaces. Voce pode notar que o model também implementa uma interface, apesar de achar que nunca trocaremos um modelo, até porque não faz sentido, optamos por deixar a interface por termos algumas coisas básicas que tem de ser usadas, como por exemplo a interface de comunicação base.

Uma outra coisa que desejamos com isso é poder trocar uma determinada interface no cliente sem trocar de versão. Vamos ter formas de configurar quem está implementando cada interface e instanciar isso em tempo de execução.

Caramba… Acho que escrevi demais… Se não tiver paciência de ler não tem problemas, suas opiniões já nos fez levar muitas coisas em consideração.

Obrigado.

[Giulliano]

Olha só cara…do jeito que vc esta falando é como se tudo estivesse dentro do mesmo servidor.

Vc tem uma aplicação X que provê serviços.

Agora vc tem uma aplicação Y que consome estes serviços, aí vc só comentou de criar uma view com uma interface que acessa esse serviço. Eu imagino que vc esteja falando no mínimo de uma view web + EJB (invocação remota).

Agora imagina que foi preciso criar a aplicação W que será via Mobile e acessará um servidor que não é o mesmo servidor que tem o serviço. O único modo de alcançar este serviço seria via SOAP.