Muito genérico, elabore, exemplifique.
[quote=andre_salvati][quote=asaudate]
Podem existir, sim, projetos novos em SOA. É só questão de saber dar nome aos bois, ou seja, é SOA ou SOA-Ready ???
[/quote]
Muito genérico, elabore, exemplifique.[/quote]
Ué! É razoavelmente simples: você está fazendo um projeto novo. Ele é orientado a serviços? Aliás, ele tem serviços publicados num repositório de serviços, inteiramente federado? Se você responde sim para a primeira pergunta e não para a segunda, você tem um projeto SOA-Ready, ou seja, ele não é 100% SOA, já que ele não é completamente aderente ao que SOA deve ser, mas ele está pronto para ser, já que, tecnicamente falando, ele é orientado a serviços.
Se encaixam no SOA-Ready praticamente todos os sistemas novos sob SOA, que ainda estão engatinhando nisso e, portanto, não usam um repositório integrado (muitos desses projetos, aliás, ainda são a primeira tentativa das empresas de usarem SOA). Mas, assim que a empresa passar para um próximo passo, de usar repositórios federados e integração entre sistemas, o SOA-Ready passa para SOA, capisce?
[]´s!
[quote=asaudate][quote=andre_salvati][quote=asaudate]
Podem existir, sim, projetos novos em SOA. É só questão de saber dar nome aos bois, ou seja, é SOA ou SOA-Ready ???
[/quote]
Muito genérico, elabore, exemplifique.[/quote]
Ué! É razoavelmente simples: você está fazendo um projeto novo. Ele é orientado a serviços? Aliás, ele tem serviços publicados num repositório de serviços, inteiramente federado? Se você responde sim para a primeira pergunta e não para a segunda, você tem um projeto SOA-Ready, ou seja, ele não é 100% SOA, já que ele não é completamente aderente ao que SOA deve ser, mas ele está pronto para ser, já que, tecnicamente falando, ele é orientado a serviços.
Se encaixam no SOA-Ready praticamente todos os sistemas novos sob SOA, que ainda estão engatinhando nisso e, portanto, não usam um repositório integrado (muitos desses projetos, aliás, ainda são a primeira tentativa das empresas de usarem SOA). Mas, assim que a empresa passar para um próximo passo, de usar repositórios federados e integração entre sistemas, o SOA-Ready passa para SOA, capisce?
[]´s![/quote]
Confuso isso, mas entendi o que vc quis dizer.
Não há dúvidas de que vc pode ir colocando seus novos projetos sob as diretrizes de SOA definidas para sua empresa, mas isso não elimina o fato de que
-
SOA é um projeto CORPORATIVO e, portanto, bem maior
-
o objetivo de SOA é organizar a bagunça dos serviços dispersos nos vários sistemas legados. E nesse caso não importa se são novos ou não, são apenas legados.
-
vc NÃO PRECISA e NÃO DEVE reescrever todo seu legado para adequação a SOA.
São dois projetos separados:
1 - O projeto de SOA corporativo que define ferramentas, padrões, diretrizes, modelo canônico, etc
2 - O seu projeto que deve ser SOA-enabled e estar de acordo com os padrões definidos no anterior.
Repito: muitas empresas confundem um projeto simples que envolve algumas integrações com SOA. “They are different beasts”.
Aí vocês estão tentando desvirtuar o significado de SOA com SOA-Ready, SOA “de verdade”, SOA Corporativo, 100% SOA…
SOA é literalmente um arquitetura desenhada com paradigma de orientação a serviços, assim como existe a orientação a objetos, componentes, procedimentos, funções, etc (um não exclui o outro, e uma aplicação pode usar vários desses paradigmas ao mesmo tempo).
Se você tem mais requisitos fortes para gerenciar centenas de aplicações desenvolvidas ou adaptadas para esse paradigma, e precisa de ferramental pesado pra organizar isso, outras soluções mais simples não deixam de ser menos SOA que a sua. Aliás quantificar de SOA não faz nem sentido.
[quote=Bruno Laturner]Aí vocês estão tentando desvirtuar o significado de SOA com SOA-Ready, SOA “de verdade”, SOA Corporativo, 100% SOA…
SOA é literalmente um arquitetura desenhada com paradigma de orientação a serviços, assim como existe a orientação a objetos, componentes, procedimentos, funções, etc (um não exclui o outro, e uma aplicação pode usar vários desses paradigmas ao mesmo tempo).
Se você tem mais requisitos fortes para gerenciar centenas de aplicações desenvolvidas ou adaptadas para esse paradigma, e precisa de ferramental pesado pra organizar isso, outras soluções mais simples não deixam de ser menos SOA que a sua. Aliás quantificar de SOA não faz nem sentido.[/quote]
Não, a idéia não é “quantificar” a coisa. É só distinguir aquelas que são, nas palavras do André, “corporativas”, e aquelas que são orientadas a serviço mas não adotadas pela empresa toda (ou seja, a empresa ainda vai migrar pra SOA, talvez).
Se ficar um pouco mais claro o que estou querendo dizer, dêem uma lida aqui.
[]´s
esqueceu de falar do SOA “google maps”, pelo visto SOA esta evoluindo para tornar compativel com tudo, inclusive o que não é SOA, como REST. :?
Nao confunda rifle de caçar rolinha com bife de cacarolinha…
SOA é um conceito amplo pra cacete… não é um padrão… É plenamente possível desenvolver uma SOA baseada em serviços REST, WS-stack, servlets ou qualquer outra porcaria…
[quote=esmiralha]Nao confunda rifle de caçar rolinha com bife de cacarolinha…
SOA é um conceito amplo pra cacete… não é um padrão… É plenamente possível desenvolver uma SOA baseada em serviços REST, WS-stack, servlets ou qualquer outra porcaria…[/quote]
Concordo. Só não digo que é possível tornar compatível com tudo, é possível tornar SOA compatível com serviços. E o que é um serviço? É uma peça de lógica de negócios composta de uma implementação e um contrato. Ou seja, se o serviço REST tem contrato (o que é perfeitamente possível de se fazer com um WSDL), então, REST é compatível com SOA.
[]´s
esqueceu de falar do SOA “google maps”, pelo visto SOA esta evoluindo para tornar compativel com tudo, inclusive o que não é SOA, como REST. :? [/quote]
Falar que REST não é SOA é como falar que orientação a objetos não é Java, meu caro.
Esse discurso lembra bastante alguns xiitas REST que já vi por aí que acham que REST é uma bala de prata por, (dentre tantos motivos que eles tiram da cartola), e também porque não é SOA. Acontece que SOA não é feito (só) de SOAP, nem o contrário!
Em qual grupo você se encaixa?
[quote=esmiralha][quote=Kenobi]
O mundo do SOA hoje está dividido em :
- Quem ouviu falar e não sabe nada, macacos treinados de produtos
- Pessoas que leram 1 ou 2 livros do Thomas Erl ou blogs e se acham especialistas e vão pelo design “clássico”
- Restafarians que possuem aversão à WS-*, Thomas Erl e afins, e não abrem a mente para analisar outras possibilidades ou ao menos ensinamentos de modelagem, que podem ser úteis no ambiente Rest, como: EntityServices , TaskServices, Document Style etc.
[/quote]
Em qual grupo você se encaixa?[/quote]
1- Não me incluo, pois conheço bastante teoria e não somente produtos.
2- Li a bibliografia completa do Thomas Erl, além de outros excelentes autores, como Sam Ruby, Ian Robson e Jim Webber, Cesare Pautass, logo tenho entendimento dos dois mundos, clássico e restful.
3- Não sou Restafarian, isso vc pode deduzir pelos cursos que ministramos, ementas e vídeos onde deixo isso bem claro, ou até na discussão do Tectura citada - Felipe Oliveira.
Logo, acredito que estou praticando as 10 mil horas de treino intensivo em cima de algo. Não que eu seja melhor que muitos, apenas tenho mais horas de dedicação e estudos, já que a soa|expert me proporciona isso e faz parte do meu trabalho parar todo dia 3-4h somente para estudar conceitos e testar coisas.
[quote=esmiralha]Nao confunda rifle de caçar rolinha com bife de cacarolinha…
SOA é um conceito amplo pra cacete… não é um padrão… É plenamente possível desenvolver uma SOA baseada em serviços REST, WS-stack, servlets ou qualquer outra porcaria…[/quote]
Amplo? Mas tem propriedades arquiteturais conhecidas pela comunidade ou na literatura?
Usar SOA pra implementar “serviços REST” vai resultar em algo que é SOA, não REST. Se quer as propriedades arquiteturais do REST vc usa REST. Não tem porque complicar quanto a isso.
Olá todos, mais uma vez, falta de tempo, bom vamos lá:
[quote]mochuara
esqueceu de falar do SOA “google maps”, pelo visto SOA esta evoluindo para tornar compativel com tudo, inclusive o que não é SOA, como REST.[/quote]
Sim, Restful é SOA e pelo simples fato de SOA não ser aquela encrenca toda que os players pregam, ferramental, COE e tudo mais. SOA é simplesmente e tão simplesmente, fazer uma API que possa expor as funcionalidades à outras plataformas.
[quote]esmiralha
Nao confunda rifle de caçar rolinha com bife de cacarolinha…
SOA é um conceito amplo pra cacete… não é um padrão… É plenamente possível desenvolver uma SOA baseada em serviços REST, WS-stack, servlets ou qualquer outra porcaria…
[/quote]
Não é tão amplo, é simples: Você vai expor sua API à outra plataforma, simples. Não poderia fazer com Servlets, pois está preso à sua plataforma (Java) a não ser que você retorne algo que desconecte, como um xml ou json.
Atualmente temos 3 estilos arquiteturais: Corba ( pois permite o desenvolvimento em muitas plataformas, interoperabilidade), WS-* e Rest.
Quando você vai usar um em detrenimento do outro ? Vale ver o debate no Tectura, não vou ficar replicando aqui.
[quote]alesaudate
Ou seja, se o serviço REST tem contrato (o que é perfeitamente possível de se fazer com um WSDL), então, REST é compatível com SOA.
[/quote]
Na verdade você não precisa do WSDL e nem da porcaria que tentaram trazer WADL, pois o Http já possui o contrato implícito - Uniform Interface 
- Sim, tem contrato, mas você não o vê e é padronizado.
[quote]
Usar SOA pra implementar “serviços REST” vai resultar em algo que é SOA, não REST. Se quer as propriedades arquiteturais do REST vc usa REST. Não tem porque complicar quanto a isso.[/quote]
É quase isso e até mencionei no tectura a modelagem horrível do projeto Bonita BPM - http://www.bonitasoft.org/docs/javadoc/rest/5.3/API/identityAPI/index.html
Isso concordo, não é Rest. O que acontece é que a MODELAGEM muda de um estilo pro outro e o desenvolvedor precisa aprender a pensar de forma diferente, pois está expondo dados/conjuntos com operações implícitas através de vértices e não algorítimos.
[quote=Kenobi][quote]alesaudate
Ou seja, se o serviço REST tem contrato (o que é perfeitamente possível de se fazer com um WSDL), então, REST é compatível com SOA.
[/quote]
Na verdade você não precisa do WSDL e nem da porcaria que tentaram trazer WADL, pois o Http já possui o contrato implícito - Uniform Interface - Sim, tem contrato, mas você não o vê e é padronizado.
[/quote]
Na verdade, mencionei o WSDL pela facilidade de uso em ferramentas que já existem e só aceitam WSDL (porque, no final das contas, você não consegue fazer Oracle BPEL entender REST sem um WSDL). Veja que eu não disse que somente é possível fazer com WSDL 
[]´s!
<IRONIA>
É isso mesmo.
SOA é simples. Qualquer projeto de SOA é trivial. Afinal, SOA não implica em mudanças culturais!!
Quanto aos “players”, como Oracle e IBM, eles só fazem ferramentas para ganhar dinheiro mesmo!!
Quanto aos profissionais que participam de consórcios como OASIS e W3C, eles só fazem isso por autopromoção!!!
Afinal eles nunca gastaram 10000 horas lendo livros, então eles não possuem conhecimento nem EXPERIÊNCIA.
Para que modelar processos de negócios? Para que organizar a bagunça das estruturas de dados e dos serviços?
TI precisa continuar tendo desculpas para a falta de produtividade em projetos.
Vamos continuar usando martelo e talhadeira, vamos fazer integrações ponto-a-ponto com arquivos TXT blocados, do mesmo jeito que se fazia (e ainda se faz) em mainframes.
Pq não descobrimos uma maneira de integrar os ábacos com REST. Seria um grande avanço, não?
Só REST presta. Só REST resta. O resto é lixo tecnológico.
</IRONIA>
[quote=andre_salvati][quote=Kenobi]
Sim, Restful é SOA e pelo simples fato de SOA não ser aquela encrenca toda que os players pregam, ferramental, COE e tudo mais. SOA é simplesmente e tão simplesmente, fazer uma API que possa expor as funcionalidades à outras plataformas.
[/quote]
<IRONIA>
É isso mesmo.
SOA é simples. Qualquer projeto de SOA é trivial. Afinal, SOA não implica em mudanças culturais!!
Quanto aos “players”, como Oracle e IBM, eles só fazem ferramentas para ganhar dinheiro mesmo!!
Quanto aos profissionais que participam de consórcios como OASIS e W3C, eles só fazem isso por autopromoção mesmo!!!
Afinal eles nunca gastaram 10000 horas lendo livros de SOA. Eles nem possuem conhecimento nem EXPERIÊNCIA.
Para que modelar processos de negócios? Para que organizar a bagunça das estruturas de dados e dos serviços?
TI precisa continuar tendo desculpas para a lentidão dos projetos.
Vamos continuar usando martelo e talhadeira, vamos fazer integrações ponto-a-ponto com arquivos TXT blocados, do mesmo jeito que se fazia (e ainda se faz) em mainframes.
Só REST presta. Só REST resta. O resto é lixo tecnológico.
</IRONIA>[/quote]
Também não vamos exagerar.
Em SOA (aliás, em TI) temos que analisar tudo com muita, mas muita parcimônia. Não adianta partir pra um extremo e dizer “vamos usar REST em tudo”, mas também não adianta partir pro lado “as ferramentas estão aí pra serem usadas, então, vamos usar sempre”.
Cada projeto é um projeto. Alguns grandes, outros pequenos, alguns com meia dúzia de serviços, outros com centenas ou até milhares. A probabilidade de um projeto com meia dúzia de serviços precisar usar uma ferramenta estabelecida é bem menor do que a probabilidade do que aquele que usa centenas de serviços.
Precisamos de ferramental para controlar os casos? Precisamos, sempre que houver SOA, é preciso usar governança, sem dúvida. No entanto, esse princípio também deve ser tomado com bastaaaante parcimônia!
[]´s
Isso é óbvio, para um projeto com meia dúzia de serviços eu também NÃO usaria repositório, ESB, modelo canônico, BPM, BPEL…
Só que um projeto com meia dúzia de serviços não é um projeto SOA, é somente mais um projeto que envolve algumas integrações.
10 projetos com meia dúzia de serviços podem ser um bom começo para uma Arquitetura Orientada a Serviços.
Estão batendo em cachorro morto. SOA já era. Que papo é esse que da pra fazer SOA com REST. As pessoas querem fugir de SOA, isso sim!
Uma dica pra quem se interessa por SOA. Desiste.
Procura outra area. Cloud computing por exemplo deve substituir SOA como plataforma para servicos em escala da internet. Mas sinto lhes informar, não tem nada de SOA em cloud computing, é algo completamente diferente, é REST.
Mas é apenas uma sugestão. Ninguém tem nada com a tecnologia que vc usa, nem como prefere gastar seu dinheiro.
Puxa, eu achei que eles poderiam estar relacionados. Será que viajei grandão?
[quote=andre_salvati][quote=asaudate]
Cada projeto é um projeto. Alguns grandes, outros pequenos, alguns com meia dúzia de serviços, outros com centenas ou até milhares. A probabilidade de um projeto com meia dúzia de serviços precisar usar uma ferramenta estabelecida é bem menor do que a probabilidade do que aquele que usa centenas de serviços.
[/quote]
Isso é óbvio, para um projeto com meia dúzia de serviços eu também NÃO usaria repositório, ESB, modelo canônico, BPM, BPEL…
Só que um projeto com meia dúzia de serviços não é um projeto SOA, é somente mais um projeto que envolve algumas integrações.
10 projetos com meia dúzia de serviços podem ser um bom começo para uma Arquitetura Orientada a Serviços.[/quote]
a web parece estar indo muito bem com URI + HTTP + HTML.