Existem prós e contras para cada uma das opções de religação do serviço EJB.
A seguinte lista descreve as duas opções e os prós e contras de cada uma:
- A primeira opção provavelmente fornece melhor desempenho no tempo de execução, porque a chamada de um serviço da Web é mais lenta do que a chamada de um EJB.
- A primeira opção pode propagar contexto enquanto uma chamada de serviço da Web não propaga contexto da mesma maneira.
- A segunda opção não envolve a criação de nenhum código customizado.
- A segunda opção não poderá ser possível para algumas definições de interface EJB, porque a geração de um serviço EJB tem limitações. Consulte a documentação do Rational Application Developer aqui: http://publib.boulder.ibm.com/infocenter/rtnl0600/topic/com.ibm.etools.webservice.doc/ref/rlimit.html
- A segunda opção poderá resultar em uma alteração de interface e, então, em uma alteração no cliente SCA.
- A segunda opção requer que um servidor do WebSphere Process Server 6.0 seja instalado
e configurado para funcionar com o WebSphere Integration Developer.
Para ver os tempos de execução instalados que são configurados para trabalhar com o WebSphere Integration Developer, vá para e selecione a entrada WebSphere Process Server v6.0, se ela existir, e certifique-se de que ela aponta para o local onde o produto está instalado.
Certifique-se de que essa entrada esteja marcada se o servidor não existir e desmarcada se esse servidor não estiver realmente instalado. Você também pode clicar no botão Incluir… se desejar incluir outro servidor.
- Se o componente Java foi construído no WebSphere Studio Application Developer
Integration Edition utilizando a abordagem de cima para baixo, na qual o esqueleto do EJB foi gerado a partir de um WSDL, então, os parâmetros dentro e fora dessa classe Java provavelmente serão a subclasse WSIFFormatPartImpl. Se for esse o caso, então, você escolherá a opção 2 para gerar um novo esqueleto EJB genérico (não dependente das APIs WSIF
ou DataObject) a partir da interface WSDL.