Fórum: arquitetura – Discussão: Representações de URI´s no modelo

Na verdade você está trabalhando com a máquina de estado no cliente. Valeria à pena até fazer um exercício, um diagrama de estado para você entender como seu objeto capturará o estado no momento do negócio.

Não há uma regra fechada, vai de você criar algo que seja condizente ao seu processo.

Fórum: arquitetura – Discussão: Arquitetura e api externa

API ou SOA como gosto de chamar, estará cada dia mais presente, pois a cultura de desenvolvimento está cada vez plural, com diversas plataformas e linguagens e multi-device.

Mas acredito que haverá uma evolução também na forma de desenhá-las, muitos se preocupam somente com design Request-Driven, fazendo opções entre WS* vs Restful e vamos começar a assistir um movimento grande orientado a eventos. (Event-Driven).

Fórum: arquitetura – Discussão: Aplicação com banco relacional + não relacional

Bom, acho que pra isso serve o mapeamento para ORM do Framework (https://github.com/andreasronge/neo4j), como o Guilherme falou, os modelos não vão saber que se tratam de um grafo. Isso estará intrínseco ao mesmo e será transparente.

Acho que não precisaria usar um outro banco para guardar atributos, deixe o Mapping do Andreas cuidar das buscas transversais.

PS: Conheço o projeto, é da casa :-)

Fórum: arquitetura – Discussão: Rest com BPM

Só mais um adendo quanto aos links, eu sempre penso em “recursos” como conjuntos numéricos, Bolotas :-) Lembram ?

Excelente dica do Guilherme :-), mas lembre-se, BPM somente para altíssimo-nível :-)

Fórum: arquitetura – Discussão: Rest com BPM

Coreografia você tem os recursos ou serviços com consciência do próximo passo. Se você tem essa possibilidade de delegar a máquina de estado para o cliente ótimo seu design vai ficar enxuto. O problema é que em muitos cenários, você não conseguirá, quando tiver que lidar com sistemas legados, por exemplo:

- O ERP SAP, não sabe que o COBOL tributário existe e que a aplicação Java, consome recurso e por aí vai, então o estado deverá ser “controlado”, aí entra naturalmente a necessidade da Orquestração.

Fórum: arquitetura – Discussão: Rest com BPM

Bom Carlos, primeiramente acho que está acontecendo um equívoco quanto ao papel do BPM na sua solução.

BPM é para mapeamento de processos de negócio, simulação e otimização, mas em nível de cadeia de valor. Há uma “orquestração”, mas o nível é muito mais alto.

Vejo o pessoal confundindo isso o tempo todo e alguns players como JBoss, fazem referências a esse tipo de prática até comparando ao BPEL, outro erro grave.

Quanto ao BPEL, que seria a DSL para máquina de estados, há uma tese do professor Cesare Pautasso: http://portal.acm.org/citation.cfm?id=1551240 – dá uma olhadinha nela, vai ajudar bastante.

Quanto ao HATEOAS, é exatamente isso, você pode enviar o estado através da hypermedia, com links da sua representação, não precisa controlar os estados no servidor.

Fórum: arquitetura – Discussão: Apache Camel / Simplicidade

Olá Alexandre, tenho 2 modelos pra BH: 1 unidade física, que está nos planos mas ainda não temos data ou 2: aulas itinerantes, comigo ou um instrutor homologado que irá até BH ministrar treinamento para uma turma interessada.

O segundo está mais fácil, já que não envolve capital-estrutura, planejamento e tudo mais.

Fórum: arquitetura – Discussão: Apache Camel / Simplicidade

Olá Alexandre, vamos por partes:

1- Apache Camel hoje é um Light ESB (Kernel de alguns produtos como JBoss ESB) e está muito maduro e é recomendado até por quem não gosta de ESBs como a ThoughtWorks, ou seja, pode usar numa boa é excelente :-).

2- Ele já poussui uma inifinidade de Adapters – http://camel.apache.org/components.html Vai ser muito difícil você ter que criar algo.

3- Mensageria tem a ver com o design da sua aplicação. Você terá um serviço síncrono ou assíncrono ? Se o volume de dados for realmente grande e você precisa simular uma operação Síncrona, vale à pena criar algo com mensageria – Correlation ID, dê uma estudada nesse padrão.

º´s

Felipe

PS: Temos um curso de ESB que aborda OSB, Mule e Apache Camel :)

Fórum: arquitetura – Discussão: REST vs. SOAP para plataformas baseadas em Serviços

Não disse que AMPQ é bom, apenas é um padrão muito forte no mercado, senão, não estava tentando ajudar no RestMS, até pq o mesmo é em cima de HTTP e seria para cenários mais simples :-)

PS: Tá vendo como gosto de HTTP, tanto que coloequei o nome de uma sala de aula na SOA|EXPERT de Roy Fielding, em sua homenagem :-)

Fórum: arquitetura – Discussão: Dicas de construção de uma nova Arquitetura Orientada a Serviços (SOA)

Olá Fabiano, vamos lá por partes:

Bom, antes de optar totalmente por Restful, vale à pena você olhar nossa discussão: http://www.tectura.com.br/topics/rest_vs_soap_p…

E o conhecer os porquês e em qual cenário se aplica.

Aqui nessa parte da minha mensagem da discussão citada, esponho algumas questões:

Rest x WS*, vai depender das suas motivações. Todo e qualquer pattern é aplicado através de motivações e aqui não seria diferente.

Sempre partimos do mais simples, para o mais complexo, então começamos sim com Rest e analisamos o cenário:

- A aplicação estará em cima de HTTP ?
- Terei que integrar com outros protocolos ? (propagar segurança e etc)
- Terei long-running transactions ? e por aí vai …

Das suas motivações nascem as escolhas.

Então vale à pena ler toda a discussão, todos os pontos de vista :).

Bom, quanto aos elementos de SOA, vou começar pelo ESB.

Do que se trata o mesmo ? Enterprise Service Bus nada mais é que uma coleção de patterns de integração implementados, com algumas features extras como: monitoria, relatórios e facilidade de configuração.

O nome pomposo “ESB” deveria ser substituído por “Framework de Integração”, assim você saberia logo de cara, quando vai necessitar do mesmo.

Se sua aplicação é nova, ambiente homogêneo, como Restful em cima de HTTP, não há motivos pra colocar um ESB na sua estrutura.

Essa falácia de ESB é o ponto central do SOA, foi o que trouxe a má fama, projetos com custo gigantesco e extremamente complexos, pois o pessoal aplicava de forma desnecessária e o mesmo se dá para o Gof via blue prints da Sun quando introduziu o EJB – analogia.

Quanto ao repositório, nada mais é que um “Banco de dados” com Schema pré definido pra você armazenar informações relativas ao serviço.

Faz sentido você ter um banco de dados pra cadastrar algo que não existe ainda ?

Esse é um assunto controverso e daria um outro tópico, mas falando sobre sua dúvida, você pode utilizar UDDI, que é uma especificação ou não. A vantagem do mesmo é ser padrão junto aos produtos de mercado, então se você fosse mesmo utilizar um ESB, poderia integrá-lo ao repositório de forma mais simples, já que estão sob uma especificação forte.

No GUJ, falo um pouco mais a respeito de UDDI / http://www.guj.com.br/java/82435-webservice-wsd… (Kenobi nick).

Em Rest, você utilizaria outra abordagem, já que a URI é o ID do seu recurso e suas operações já estão definidas pelo protocolo HTTP. Você só precisaria cadastrar os Entry Points e contar a história de negócio daquele recurso.

Minha dica : Preocupe-se nesse momento com a Modelagem correta, granularidade, abstração do negócio, pois é aí que o bicho pega de verdade.

Aqui no GUJ, estamos discutindo sobre um problema de modelagem: http://www.guj.com.br/java/231789-web-service—…

Tecnologia é fácil de se assimilar, agora design ruim é complicado de se lidar.

[]s

Felipe Oliveira

Fórum: arquitetura – Discussão: REST vs. SOAP para plataformas baseadas em Serviços

Pessoal, desculpe-me ressucitar esse tópico, mas tinha deixado de responder, pois coloquei todas as argumentações e ainda não queria mais continuar argumentando na época.

Entretanto há uma nova discussão sobre Arquitetura SOA e eu vou referenciar esse tópico e pra que não haja falhas no entendimento, sou obrigado a responder ao Luca.

Quanto ao SOAP em cima de outros protocolos, acredtio que cada sistema cumpre seu papel num determinado cenário de negócio, o qual faça sentido.

Então, imagine uma aplicação Multicast em cima de UDP. Você pode trafegar tranquilamente o SOAP.

http://docs.oasis-open.org/ws-dd/soapoverudp/1….

Então, não estamos nem utilizando o TCP, quanto mais o HTTP no caso citado.

Outro transporte muito utilizado como mensageria, seria o JMS e imagine um cenário que você queira utiilizá-la através de outra plataforma.

Assim como SCTP e o próprio AMQP desenha na sua especificação, uma camada neutra em cima utilizando XML.

http://www.amqp.org/confluence/download/attachm…

Poderia citar Mainframe (SNA), SMPP ( Short Message Peer-to-Peer Protocol ) estrutra interna de muitas teles e a coisa é extensa.

Quanto ao REST, eu concordo que simplifica um montão e 80% ou mais do que é produzido, poderia ser simplificado.

Agora não poderemos utilizar HTTP pra tudo, é um protocolo infinitamente mais lento que o AMQP, por exemplo, pra trabalhar com Mensageria.

Existe uma especificação – RestMS – http://www.restms.org onde faço parte da mesma e estou fazendo a RI em Ruby/Java, o que me obrigou a estudar bastante a questão.

PS: Eu já havia respondido os motivos, na página 2 – http://www.tectura.com.br/topics/rest_vs_soap_p…

Fórum: arquitetura – Discussão: Framework Java para trabalho com XML

Desculpe-me Guilherme, entendo que o WS-Stack pode ser complexo para muitos entenderem, mas nesse caso específico, você teria a mesma dificuldade com Restful, onde ele teria que lidar com um mapeamento OXM.

O SOAP nesse caso, onde transportará o grafo e suas specs como security do WS, não irão interferir no processo.

Lembrando que as outras specs agem como metadados.

Respondendo à dúvida do amigo, você pode trabalhar com frameworks OXM como XmlBeans e JaxB, ou adotar uma ferramenta de manipulação como XStream.

Seria muito interessante você conhecer também ferramentas como XPath e XQuery para dinamizar sua manipulação, em java há a biblioteca XQJ e vai um link da IBM pra te ajudar no entendimento: http://www.ibm.com/developerworks/xml/library/x…

Fórum: arquitetura – Discussão: Separando Layers em Tiers

Hoje com a utilização de Restful em cima dos Controllers, você pode ter sua “API” separada e a camada view a consumir via JSON.

Isso pode se dar via Web, ou múltiplos devices de forma transparente. Isolaria a regra de negócio sem complicação.

Quanto às tiers físicas, vejo que poderia rodar na mesma máquina e utilizar um design stateless, vai facilitar o escalonamento.

Fórum: arquitetura – Discussão: REST vs. SOAP para plataformas baseadas em Serviços

Olá Guilherme, cocordo que tudo caminha para algo mais “Web”, mas as próprias empresas citadas, fazem uso de outros protocolos, como AMQ, Protocol Bufffer, Zero, pois há cenários onde a necessidade de processamento precisa ser atendida quase imediatamente.

Um exemplo que não imagino em cima de http: Bolsa de Valores.

Para esses, cenários onde cada milisegundo faz diferença, outras soluções serão adotas, como Complex Events – CEP.

Retirado da página do Esper: http://esper.codehaus.org/

Typical Uses

What these applications have in common is the requirement to process events (or messages) in real-time or near real-time. This is sometimes referred to as complex event processing (CEP) and event stream analysis.

Key considerations for these types of applications are the complexity of the logic required, throughput and latency.

Complex computations – applications that detect patterns among events (event correlation), filter events, aggregate time or length windows of events, join event streams, trigger based on absence of events etc.
High throughput – applications that process large volumes of messages (between 1,000 to 100k messages per second)
Low latency – applications that react in real-time to conditions that occur (from a few milliseconds to a few seconds)

Fórum: arquitetura – Discussão: REST vs. SOAP para plataformas baseadas em Serviços

Lucas, evidentemente não estava me referindo a usar SOAP + HTTP, senão ele seria mais lento e concordo contigo, pois não se valeria de técnicas como cacheamento – eTags.

Estava me referindo de SOAP + AMQ, SOAP + JMS, por exemplo, que são infinitamente mais rápidos que o Http.

Em cenário enterprise, você necessitará baixar um fluxo às vezes de 0.4ms para 0.2ms, cenário de alguns grandes clientes.

A complexidade nesse tipo de ambiente é outra, por isso digo, nem todos os problemas podem ser resolvidos com a as mesmas ferramentas, senão, tínhamos somente chave philips :-).

Fórum: arquitetura – Discussão: REST vs. SOAP para plataformas baseadas em Serviços

Olá Lucas, não são todos os cenários onde o REST ganharia, pois em muitos cenários de negócio,bolsa de valores por ex., onde você não mantém os dados em cachê e o protocolo http é bastante lento. Trabalharia com Tons de Eventos, disparando o SOAP Multicast por exemplo à vários brokers. Como disseram, o custo de processamento do SOAP hoje é praticamente nada, comparado à tramitação do protocolo.

Claro que existem outros protocolos mais eficientes, como o Google Protocol Buffers – http://code.google.com/apis/protocolbuffers/doc…, o duro são todos os partners e sistemas entenderem o formato.

Bom, eu não conheço nenhuma apresentação mais concisa que a do prof. Cesare Pautasso, sobre REST x SOAP, atualizada: http://www.slideshare.net/cesare.pautasso/soa20…

Ele vem fazendo esse trabalho desde 2008, comparando ambos cenários.
- http://www.slideshare.net/soasymposium/cesare-p…

º´s

Felipe.

Fórum: arquitetura – Discussão: REST vs. SOAP para plataformas baseadas em Serviços

Um novo Twitter, Facebook, sei lá…ainda vou criar uma startup dessas !! #dream

Fórum: arquitetura – Discussão: REST vs. SOAP para plataformas baseadas em Serviços

Luca , só um parenteses: O EJB Stateful distribui estado por questões de Failover e a idéia é bacana, com simples annotations, eu consigo montar uma estrutura que pode persistir em nós – grids, replicar em cluster, sem entender como aquilo tudo funciona por debaixo dos panos :-).

Sei que vc detesta a tecnologia e sinceramente eu não vou defender também. Realmente acredito que há outras maneiras de fazer isso, mas que a idéia de encapsular essa complexidade era bacana, era :-P

Mas você havia me pedido um exemplo com estado e eu passei :)

Fórum: arquitetura – Discussão: REST vs. SOAP para plataformas baseadas em Serviços

Guilherme e Luca,

No exemplo que o Guilherme citou, o “consumidor conhece”, bom então a máquina de estados está no cliente, então ele é o orquestrador. E se o cliente da operação não conhece o fluxo interno e o servidor controla ? Esse é o tipo de orquestração que estava me refereindo, pois normalmente, o cliente não sabe quantos sistemas está acessando, por baixo dos panos.

Outro problema, integração com Mainframe, ou softwares legados, não vão te voltar hypermedia. Como lidar com esse tipo de problema ?

Fórum: arquitetura – Discussão: REST vs. SOAP para plataformas baseadas em Serviços

Opa Luca, realmente não havia entendido sua colocação. Aplicações com estado, conforme mencionei, o próprio BPEL usava metadados num banco de dados para persistir as variáveis e por problemas de hidratação do banco, começaram a usar caches e grids.

Em Java, você poderia fazê-lo com EJB Session Stateful e dependendo do Application Server, Glassfish por exemplo, a replicação do estado se dará nos nós do HA, tecnologia que era da Clustra na época do Sun One e discutimos no passado no Guj.

Como disse, há muitas maneiras de se fazer a mesma coisa. Eu particularmente gostaria de encontrar uma maneira comum e que facilitasse as coisas :-)