Versus usado somente por peritos em J2EE
Os produtos de BPM da primeira geração necessitavam competências em J2EE, ou mesmo linguagens de script proprietárias, como se o mundo necessitasse de outra linguagem de programação. Tanto quanto eu gosto de J2EE como um fornecedor do software, isto é uma especificação anormal, complexa, que está fora do alcance para a maioria das pessoas de TI. A programação orientada a objetos é extremamente poderosa, mas como ela ou não, a maioria os programadores não a compreendem, nem pelo menos usariam algo mais simples como PHP ou Visual Basic. Há 2 milhões programadores de Java por aí, e eu conto que somente uma fração deles pode escrever componentes de EJB. Menos ainda sabem combinar EJB com o JMS, o Servlets e os Mensage-Driven Beans. Compare isso aos 3 milhões de desenvolvedores PHP e aos 8 milhões de codificadores em VB para aí, e você começará a ter este cenário. BPM 2.0 não é para os gurus de J2EE, e nem limitado a eles. BPM 2.0 alveja os analistas de processos que podem ler um diagrama em BPMN, para compreender a representação da árvore de um esquema XML, clicar e arrastar formas em uma tela. Se você pensar que pode fazer sem grande esforço, BPM 2.0 trabalhará para você.
Mas o que há de errado com J2EE? Java . e J2EE corporativo . são tecnologias extremamente poderosas. O problema é que poder vem acompanhado de complexidade, e J2EE é um exemplo perfeito para isto. O site do Java Community Process (JCP) possui 320 pedidos de especificação (JSRs), e a especificação Beta da API corporativa da edição 5 tem 1438 classes. De qualquer maneira você percebe que o Java cresceu, ficou grande e do complexo.
J2EE foi supostamente para trazer portabilidade para as aplicações desenvolvidas, mas a realidade é que além das as mais simples que tomam somente a vantagem de um recipiente de Servlet, você não pode mover aplicações de servidor de aplicação para outro, especialmente se empregarem componentes dos Enterprise Java Beans (EJB).
O modelo de componentes EJB 3.0 prometem mudar isto. Infelizmente, quando um problema é reparado aqui, um novo aparece. Nós experimentamos isto recentemente quando nós tentamos mover nosso servidor de processos para o Apache Geronimo. Tudo trabalhou muito bem até que nós tentamos empacotar todos componentes junto . servidor de processos, serviços de workflow, motor de XForms, etc. . então quebrou. De algum modo, um componente desligava um serviço compartilhado de Log4j, e nós não tivemos uma maneira fácil de isolar qual componente estava com falha. Este problema irritante, junto com uma dúzia de similares, manteve uma equipe de três do melhores programadores Java, ocupados a maior parte do último trimestre. Se uma empresa de software como a Intalio, que o negócio é desenvolver o software, estar enfrentando este tipo de desafio, como será para os usuários finais cujo negócio preliminar está vendendo dispositivos ou está processando transações financeiras? Bem, tanto quanto eu posso dizer de muitas discussões com clientes, não é que grande tampouco.
Seu programador médio e não posso tratar neste nível de complexidade. Não que não é esperto o bastante, mas tenho as coisas melhores a fazer, como tomar cuidado do negócio por exemplo. E que é verdadeiro para J2EE é também verdadeiro para tecnologias colaterais, tais como o Eclipse por exemplo, tentado sempre usar EMF e GEF? Para mim, BPM 2.0 é toda sobre oferecer um pulo do quantum de abstração que permitirá seu desenvolvedor médio . pessoal de ABAP, PHP e VB . abstrair esta complexidade e focar em níveis mais elevados, como processos, regras, e relações. Para estender estes desenvolvedores sem a complexidade do J2EE e .NET, a BPM 2.0 dá-lhes as ferramentas para ser produtivos, como vingança. Isso é precisamente porque gostam disto.
http://www.projeler.com.br/artigos_bpm20d.jsp
Nenhum comentário:
Postar um comentário