1.0 Introdução
2.0 Software Suportados e Especificações
3.0 Alterações do Release Anterior
4.0 Problemas Conhecidos
4.1 Web Services Explorer
4.2 Registro de UDDI Privado
4.3 Interoperabilidade com Tempo de Execução do IBM SOAP
4.4 Gerando um Documento WSDL a partir de um Arquivo DADX
4.5 Gerador JSP de Ferramentas da Web
4.6 Utilizando o Universal Test Client
4.7 Várias Saídas Permitidas em Determinados Casos com Serviços da Web DADX
4.8 Preferência do Driver JDBC Deve Ser Utilizada Apenas no Linux
4.9 Necessário Atualizar Arquivos de Exemplo DAD se o Extensor XML Não Estiver Instalado no Diretório Padrão
4.10 Problemas de DADX dos Serviços da Web
4.11 Suporte à Geração de DADX
4.12 Erros de WSDL Depois de Importar um Arquivo de Serviços da Web do 4.0.x
4.13 Problemas ao Utilizar a Linha de Comandos de Serviços da Web
4.14 Criação de Serviço da Web sem um Servidor Existente
4.15 Gerando Aplicativo de Amostra de Serviços da Web
4.16 Importando Arquivos WSDL com Autenticação Básica HTTP
4.17 Problemas com a Utilização do Tempo de Execução do WebSphere v5.0.2
4.18 Configurando um Grupo DADX com Informações do Datasource
4.19 Carregando o Localizador de Cliente Utilizando o Universal Test Client
4.20 Preferências de Recursos Não Observadas
4.21 Problemas com a Utilização do Tempo de Execução do Apache Axis 1.0
4.22 JSP de Amostra de Serviço da Web Falhou ao Ser Compilado
4.23 Problema com a Linha de Comandos de Serviços da Web em Alemão
4.24 Erro com Host Local Não Definido
4.25 Limitações Permanentes ao Utilizar o Tempo de Execução do IBM SOAP
4.26 Serviço e Cliente da Web Utilizando Tempo de Execução Diferente
4.27 Clicando em Finish no Assistente Web service client
4.28 Folha de Macetes de Serviços da Web
O recurso ferramentas de serviços da Web permite descobrir, criar e publicar Java bean, DADX, bean corporativo e serviços da Web da URL. Esse arquivo readme descreve problemas conhecidos, limitações e soluções alternativas associados às seguintes funções das ferramentas de serviço da Web:
- Gerar um documento WSDL a partir de um Java bean, documento DADX, bean corporativo, arquivo ISD e URL.
- Gerar um proxy Java ou esqueleto de um documento WSDL.
- Criar e implementar um serviço da Web a partir de um Java bean, DADX, bean corporativo ou URL.
- Descobrir e publicar os serviços da Web
- Gerar um aplicativo da Web de amostra a partir de um proxy Java.
- Problemas de interoperabilidade.
O Web Services Explorer suporta os seguintes navegadores da Web:
- Microsoft Internet Explorer 6.0 ou superior
- Mozilla 1.2.1 ou superior
Esse release das ferramentas de serviço da Web gera o código que obedece às seguintes especificações:
- SOAP (Simple Object Access Protocol) Versão 1.1
- Universal Description, Discovery, and Integration (UDDI) Versão 2.0
- WSDL (Web Services Definition Language) Versão 1.1
- WSIL (Web Services Inspection Language) Versão 1.0
Esse release das ferramentas de serviço da Web suporta:
- o tempo de execução de serviços da Web do IBM WebSphere v5.0.2
- os ambientes de tempo de execução do IBM SOAP Versão 2.2 e Versão 2.3.
- o tempo de execução do Apache Axis 1.0
Se você estiver ativando o ambiente de testes WORF fora do workbench utilizando o Mozilla, recomenda-se uma versão do Mozilla de pelo menos 1.3.1. A saída da chamada do serviço da Web, bem como arquivos de descrição, podem não ser apresentados corretamente em versões anteriores do navegador Mozilla.
O tempo de execução do DADX requer fixpack 6 ou superior do DB2 7.2 ou DB2 8.1 ou superior.
Os recursos a seguir são novos nas ferramentas de serviços da Web na v5.1:
- Suportam o tempo de execução de serviços da Web do IBM WebSphere v5.0.2. Esse é o tempo de execução estratégico de serviços da Web da IBM que suporta JSR-109 e JAX-RPC.
- Suportam o tempo de execução do Apache Axis 1.0. Esse tempo de execução suporta JAX-RPC e é destinado a usuários que preferem desenvolver para a plataforma aberta Apache Axis.
- Fornecem uma ferramenta da linha de comandos de serviços da Web que permite aos usuários criar serviços da Web a partir de um arquivo Java bean, EJB ou WSDL e publicar e despublicar negócios e serviços para registros UDDI.
- Integraram totalmente o WSDL Explorer no Web Services Explorer.
- Fornecem ferramentas de montagem de aplicativos de serviços da Web incluindo:
- Editor Web Services e Editor Web Services Client para editar os descritores de implementação JSR-109 e IBM WebSphere v5.0.2.
- A ação pop-up para chamar a função EndpointEnabler.
- A ação pop-up para chamar a função WebServiceDeploy.
- A ajuda que conduz o usuário na criação de serviços da Web compatíveis com WS-I através das preferências. O usuário pode optar para o assistente Web services, requerer, sugerir ou ignorar a conformidade com WS-I ao criar serviços da Web.
- Geram e consomem documentos de referências de serviços da Web do WSIL por proxy.
- Ativam o usuário para atualizar os descritores de implementação do WebSphere v5.0.2 com configurações de segurança de amostra.
- Suportam SOAP sob JMS como transporte para mensagens SOAP ao criar serviços da Web de EJBs.
- Suportam categorias UDDI definidas pelo usuário.
- Suportam Validação de Serviços da Web. Quando essa preferência é definida, a ferramenta valida que um Enterprise Application e/ou os módulos dentro dela estão de acordo com um conjunto de regras comprovando conformidade com JSR-109.
- Ao utilizar o Web Services Explorer com o Private UDDI Registry, o formulário Manage Publisher Assertion de um nó de negócios não será carregado nas seguintes situações:
- Você não efetuou login no nó de registro que contém o nó de negócios.
- Você efetuou login no nó de registro que contém o nó de negócios, mas o nó de negócios não pertence ao ID do Usuário/Senha que é utilizado para efetuar login no registro que o contém.
- Você não poderá utilizar o Web Service Explorer para consultar ou publicar por meio de um registro UDDI ativado para autenticação básica. Um exemplo desse tipo de registro é um registro privado que é implementado em um servidor com a autenticação básica ativada. Observe que os registros públicos (IBM, Microsoft, SAP, NTT e XMethods) não são afetados por esse problema.
- Quando uma pesquisa avançada é utilizada no Web Services Explorer para localizar negócios em um WAS private UDDI registry configurado com um backend do Cloudscape e uma ou mais interfaces de serviço são especificadas como parâmetros, a pesquisa falha e a janela de status mostra:
com.ibm.uddi4j.wsdl.client.UDDIWSDLProxyException: Could not list all service providers. ------------------------------------------------------------------------------ Nested exception is:E_fatalError (10500) Serious technical error has occurred while processing the request. : Fault code=Client Fault string=Client Error Fault actor=null Detail=null DispositionReport: ErrCode=E_fatalError ErrInfoText=E_fatalError (10500) Serious technical error has occurred while processing the request.
- O registro de XMethods possui procedimentos para verificar serviços da Web publicados, excluindo aqueles que não estejam mais acessíveis ou não estejam funcionando. Para evitar que um serviço da Web publicado seja excluído, assegure-se de que as referências de URL nos arquivos WSDL sejam acessíveis na Internet.
O SAP UDDI Business Registry retornará um E_fatalError para uma solicitação localizar negócios por categoria com ofindQualifier igual a "combineCategoryBags" (tModelKey igual a UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2). A mensagem de erro a seguir será exibida na janela de status. Este é um problema exclusivo do SAP UDDI Business Registry.
com.ibm.uddi4j.wsdl.client.UDDIWSDLProxyException: Could not list all service providers. ------------------------------------------------------------------------------ Nested exception is:A serious technical error has occurred while processing the request. : Fault code=Client Fault string=UDDI Error Fault actor=null Detail=null DispositionReport: ErrCode=E_fatalError ErrInfoText=A serious technical error has occurred while processing the request. at com.ibm.uddi4j.wsdl.client.UDDIWSDLProxy.findAllServiceProviders(UDDIWSDLProxy.java:1626) at FindBusWithQualifier.main(FindBusWithQualifier.java:35)
- Os relatórios de declaração do Publisher retornados pelo SAP UDDI Business Registry não contêm status. Como resultado, a coluna de status de declaração do publicador no formulário Manage Publisher Assertion do Web Services Explorer será omitida para relatórios retornados pelo SAP. Este é um problema exclusivo do SAP UDDI Business Registry.
- Ao tentar publicar um negócio, um serviço ou uma interface de serviços no XMethods UDDI Registry, você obterá uma mensagem de erro a respeito de uma "SSL Handshake Failure". Esse é um problema conhecido que a IBM e XMethods estão investigando.
- As declarações do publicador do Private UDDI Registry podem ficar visíveis para todas as empresas no registro. Uma empresa pode ver declarações do publicador que estão associadas à própria empresa, por exemplo, a chave da empresa não é chave de origem nem chave de destino das declarações do servidor.
- Quando o registro Unit Test UDDI for configurado com o backend de banco de dados do Cloudscape, os métodos UDDI para localizar por nome executarão, por padrão, pesquisas com distinção entre maiúsculas e minúsculas. Isso está contra a especificação UDDI e é uma limitação.
- O Private UDDI Registry só deve ser configurado com o backend do Cloudscape para finalidades de teste básicas (isto é, não utilize esse backend para trabalho de produção, uma vez que existem atualmente dificuldades com ações, tais como consultas complexas). Para obter mais informações sobre o private UDDI Registry, consulte a documentação de Network Deployment no InfoCenter do WAS V5.
- Após a criação ou atualização do registro UDDI de Teste da Unidade baseada em Cloudscape no Linux, é possível obter um aviso em vermelho no console do servidor que afirma:
Cloudscape (instância <uuid>) está tentando reinicializar a <localização UDDI DB> do banco de dados, mesmo que o Cloudscape (instância <uuid>) ainda esteja ativo. Apenas uma instância de Cloudscape deve reinicializar um banco de dados por vez. É possível resultar uma danificação severa e irrecuperável e pode já ter ocorrido.
Esse aviso é um alarme falso. Mais detalhes podem ser encontrados em:
http://www-1.ibm.com/support/docview.wss?rs=636&context=SSCVRP&q=&uid=swg21051601&loc=en_US&cs=utf-8&lang=en+en
- Ao utilizar o tempo de execução IBM SOAP, gerar WSDL com parâmetros complexos pode causar problemas com as ferramentas Microsoft que utilizam o WSDL. As ferramentas Microsoft não manipulam instruções XSD include adequadamente, portanto, pode ser necessário colocar os esquemas XSD em linha no WSDL gerado. Isso pode ser feito selecionando
Windows > Preferences > Web Services > Code Generation > use inline schema.Ao utilizar o tempo de execução IBM SOAP, os assistentes para serviços da Web agora estão totalmente ativados para gerar mapeamentos baseados em elementos, além de quaisquer mapeamentos baseados no tipo normal, se a caixa de opções "Enable element-based mapping" estiver marcada. No menu principal do WSAD, esta caixa de opções está localizada na seguinte página de preferências:
Windows > Preferences > Web Services > Code Generation.Se essa preferência não estiver ativada, o que é o padrão, o tempo de execução do Apache/IBM SOAP poderá não interoperar com os tempos de execução de serviços da Web de outros fornecedores que enviam mensagens de elementos que não possuem propriedades "xsi:type". Os tempos de execução de serviços da Web de outros fornecedores seguem diversas políticas na inclusão de propriedades xsi:type. Alguns sempre as incluem. Alguns nunca. Alguns fornecem uma opção de configuração. Alguns omitem xsi:types para determinados tipos, como matrizes.
O erro típico produzido pelo tempo de execução de IBM/Apache SOAP é:
targetException=java.lang.IllegalArgumentException: No Deserializer found to deserialize a ':MyElement' using encoding style 'http://schemas.xmlsoap.org/soap/encoding/'.
Quando ativados, os mapeamentos baseados em elementos são gerados para:
- arquivo do descritor de implementação para cenários Java bean/EJB de cima para baixo e cenários WSDL Skeleton, e
- o Proxy em cenários clientes.
Mapeamentos baseados em elemento têm o formato:
<isd:map
encodingStyle="encoding style"
xmlns:x="some-namespace"
qname="x:some-local-name"
xml2JavaClassName="some-deserializer-class-name"/>Um mapeamento baseado em elementos é gerado para:
- Cada parte definida em cada entrada wsdl:message.
- Cada parte definida em cada saída wsdl:message, apenas para cenários de Skeleton e Proxy.
- Cada elemento raiz ou elemento local em cada tipo complexo referenciado por partes no arquivo WSDL
O assistente WSAD Web services segue as específicações SOAP e XSD para determinar se o nome do elemento em um mapeamento baseado em elementos deve ser completo (isto é, ter um espaço de nomes) ou não-completo.
O WSAD Web services segue essas regras para decidir entre nomes de elementos completos e não-completos:
- Nomes de partes em WSDL admitem nomes não qualificados.
- Elementos raiz em XSD admitem nomes qualificados.
- Elementos locais em XSD admitem nomes não qualificados se o esquema especificar elementFormDefault="unqualified", que também é o padrão se o esquema não tiver nenhum atributo elementFormDefault.
- Elementos locais em XSD admitem nome qualificados se o esquema especificar elementFormDefault="qualified".
Sabe-se que alguns tempos de execução geram elementos não qualificados em mensagens SOAP, apesar de um esquema especificar a utilização de elementos qualificados através do atributo "elementFormDefault" do esquema XSD. Nesses casos, pode ser necessário editar manualmente o WSDL ou XSD de um serviço e alterar elementFormDefault para "unqualified".
Um exemplo de um mapeamento baseado em elemento qualificado sem namespace é:
<isd:map
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:x=""
qname="x:name"
xml2JavaClassName="org.apache.soap.encoding.soapenc.StringDeserializer"/>Um exemplo de um mapeamento baseado em elementos completo com namespace é:
<isd:map
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:x="http://www.ibm.com/"
qname="x:name"
xml2JavaClassName="org.apache.soap.encoding.soapenc.StringDeserializer"/>Observe que apenas um mapeamento baseado em elementos será gerado para um determinado nome de elemento. Ou seja, se o esquema utiliza o mesmo nome de elemento mais de uma vez, mas com tipos diferentes, apenas um dos elementos será selecionado, efetivamente de modo aleatório, como a base para um mapeamento baseado em elementos. Os outros elementos com nomes idênticos, de tipos diferentes, falharão ao desserializar. O mesmo ocorre se o esquema utilizar o mesmo nome para um elemento e para uma parte WSDL.
- Ao iniciar com um bean de serviço que retorna uma matriz de Mapa ou uma matriz de Hashtable e a opção "element-based mapping" estiver ativada, o Proxy SOAP gerado mapeará incorretamente o tipo de retorno para uma java.lang.String[]. Uma ClassCastException ocorrerá durante o tempo de execução. Para solucionar este problema, execute o assistente para cliente de serviço da Web com o novo WSDL criado e regenere o proxySOAP no projeto do cliente.
- Para melhorar a interoperabilidade com os serviços da Web da Microsoft, o tempo de execução do DADX foi atualizado para que eles possam gerar serviços da Web no estilo de documento. Para ativar esse recurso, utilize o assistente para configuração do DADX para abrir a página property para um grupo DADX que deve ser utilizado. Na parte inferior da página de propriedade, assegure que o campo de entrada "Use document style" esteja definido como true.
- Não há suporte para um Java proxy para operação de chamada DADX com vários parâmetros de saída.
- Ao criar um serviço DADX da Web, ocasionalmente a mensagem "IWAB0177E Erro ao gerar WSDL a partir de um arquivo DADX." aparecerá. Na maioria dos casos, essa mensagem é uma indicação de algum problema relacionado ao banco de dados e, para obter detalhes sobre o problema, deve-se consultar o log do console do servidor. Verifique também o seguinte:
- Os arquivos DAD (*.dad) precisam estar localizados no diretório de grupo do DADX. Este é o modo como o tempo de execução do WORF localiza os arquivos DAD.
- Se você estiver tentando gerar um arquivo DAD a partir de um arquivo de Mapeamento RDB para XML (.rmx), certifique-se de que o arquivo DAD esteja localizado na mesma pasta que o arquivo DADX.
- O esquema DADX não utiliza mais a marcação de documento WSDL para documentação. Essa marcação agora faz parte do esquema DADX. Isso pode causar problemas de validação em arquivos DADX antigos que não tenham sido migrados para utilizar o esquema atualizado. Por exemplo, se o arquivo DADX antigo continha o seguinte XML:
<wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
Provides queries for part order information at myco.com.
</wsdl:documentation>a nova entrada do documento seria:
<documentation>
Provides queries for part order information at myco.com.
</documentation>
Ao lançar o Universal Test Client do assistente para Web Services, o URL do Provedor JNDI é definida para a porta padrão do WebSphere v5 2809. Se estiver utilizando um servidor WebSphere v4 ou se tiver alterado o número da porta, não será possível pesquisar o diretório JNDI. Se você tentar acessar o diretório JNDI, você obterá o seguinte erro:
IWAD0403E Could not construct the JNDI tree: Caught CORBA.COMM_FAILURE when resolving initial reference=WsnNameServiceA solução alternativa é:
- Dê um clique duplo no servidor que está utilizando. Isso tornará visível as propriedades do servidor.
- Selecione a guia ports.
- Copie a porta Orb bootstrap.
- Abra a janela de propriedades JNDI no Universal Test Client.
- Cole a porta bootstrap na caixa de entrada de texto Provider URL.
Normalmente, a existência de várias saídas em um serviço da Web não é suportada por nossas ferramentas. Entretanto, no caso dos serviços da Web DADX, várias saídas são permitidas se Use Document Style group property for definida para true. Neste caso, quando document style é true, várias saídas são combinadas em um único documento XML.
Uma nova categoria de Preferências dos serviços da Web (Windows > Preferences > Web Services) denominada JDBC drivers foi incluída. Embora esta preferência esteja disponível em todas as plataformas, ela deve ser utilizada apenas no Linux. No Linux, pode ser difícil determinar a localização do arquivo JAR contendo drivers JDBC. Portanto, esta página de preferência foi incluída para que você possa especificar qual arquivo JAR deve ser utilizado. Atualmente, apenas o código de validação DADX utiliza estas informações de arquivo JAR.
Os arquivos DAD localizados no diretório WSinstall_dir\wstools\eclipse\plugins\com.ibm.etools.webservice_<version>\samples\DADX_examples podem precisar de modificações em dois locais para refletir sua configuração de sistema específica.
Próximo ao início do arquivo há uma linha semelhante a esta:
<!DOCTYPE DAD SYSTEM "c:\dxx\dtd\dad.dtd">
Se o extensor XML tiver sido carregado em uma localização diferente de c:\dxx , esta cadeia precisa ser atualizada para refletir a localização atual. Isto aplica-se a máquinas Linux também, onde a localização é geralmente /usr/IBMdb2xml.
- Na página Web service DADX group property do assistente para Web services, as alterações podem não ser efetivadas imediatamente. Portanto, recomenda-se que as alterações a propriedades do grupo DADX sejam feitas utilizando o Assistente DADX Group Configuration.
- Depois de editar e validar um arquivo DADX, você pode obter uma mensagem na exibição Tasks determinando que o projeto precisa ser reconstruído. Se essa situação surgir, clique com o botão direito do mouse no projeto apropriado e clique em Rebuild project. Pode ser necessário fazer isso uma segunda vez para remover a mensagem da exibição Tasks.
Embora funções definidas pelo usuário sejam listadas no assistente Generate DADX, não existe atualmente suporte para gerar DADX a partir de funções definidas pelo usuário. Somente está disponível suporte para geração de DADX a partir de arquivos DAD, procedimentos armazenados e instruções SQL. A seleção de uma função definida pelo usuário fará com que seja gerado um arquivo de esqueleto DADX simples.
Se você importou um arquivo de serviços da Web do 4.0.x, é possível que você receba as seguintes mensagens de erro:
Error The part 'result' has an invalid value 'anyElement' defined for its type. Type declarations must refer to valid values defined in a schema.
Error The part 'return' has an invalid value 'findPatientResult' defined for its element. Element declarations must refer to valid values defined in a schema.
Error The part 'response' has an invalid value 'findPatientResponse' defined for its element. Element declarations must refer to valid values defined in a schema.A solução alternativa é:
- Excluir os arquivos do WSDL.
- Gerar seus serviços da Web novamente, re-executando o assistente Web Services.
- Opção FileNStoPkg: A opção -fileNStoPkg do WSDL2WebService na linha de comandos atualmente não está funcionando. Utilize -NStoPkg e digite cada mapeamento na linha de comandos. Outra opção será utilizada para o assistente Web Service, se for requerido o espaço de nomes para compactar o mapeamento.
- Diretório com espaço: Evite executar o WSDL2WebService a partir de um diretório que contém um espaço no nome do diretório. Caso contrário, o arquivo compile.bat (ou compile.sh no Linux) gerado não é compilado.
- Descritores de implementação de cliente e arquivos WSDL: Após executar o Bean2WebService, EJB2WebService, WSDL2WebService, os descritores de implementação adicionais do cliente (webservicesclient.xml, ibm-webservicesclient-bnd.xmi, ibm-webservicesclient-ext.xmi e the _mapping.xml) se encontram na parte do cliente/META-INF. Se o usuário pretender criar um aplicativo cliente gerenciado, ele deverá seguir os seguintes procedimentos:
- Para executar o cliente gerenciado no formulário de um EJB ou J2EE Application Client, o usuário deve compactar todos os descritores de implementação em META-INF do archive e copiar o wsdl da parte do serviço (em WEB-INF/wsdl se o serviço estiver no contêiner da Web ou META-INF/wsdl se o serviço estiver no contêiner EJ) para META-INF/wsdl do projeto do cliente.
- Para executar o cliente gerenciado dentro do contêiner da Web, o usuário deve compactar todos os descritores de implementação em WEB-INF do archive do cliente (geralmente, no formulário de um WAR ou um Projeto Web no WebSphere Studio). O arquivo WSDL também deve ser copiado da parte do serviço para WEB-INF/wsdl. O usuário também precisa editar manualmente webservicesclient.xml (utilizando um editor de texto ou se no WebSphere Studio, editor xml), substituindo toda ocorrência de META-INF para WEB-INF.
Nome de Classes em Sublinhado: Ao criar o serviço da Web a partir do Java bean ou EJB, se o nome da classe do bean de serviço tiver um sublinhado nele e o caractere seguinte estiver em letras minúsculas (por exemplo, test.Simple_bean), o serviço não poderá ser iniciado no WebSphere Application Server. A solução alternativa é utilizar um nome de bean de serviço sem sublinhado ou utilizar uma letra maiúscula após o sublinhado (por exemplo, test.Simple_Bean).
- Ao executar um cenário de criação de serviço da Web sem um servidor Web existente no espaço de trabalho, pressionar Back na terceira página fará com que o botão Next seja desativado. A solução alternativa é cancelar a partir do assistente e iniciá-lo novamente. Para evitar esse problema, crie o servidor e a configuração antes de iniciar o cenário de serviço da Web ou evite pressionar Back na terceira página, quando não houver servidor Web existente.
- Quando um usuário clica em um arquivo Java no workbench, a ação pop-up Generate Sample Application no menu Web Services gera JSPs de amostra de serviços da Web para um proxy IBM SOAP. Para gerar os JSPs de amostra de serviços da Web para outros tempos de execução de serviços da Web (IBM WebSphere 5.0.2 e Apache Axis 1.0), clique com o botão direito do mouse em um arquivo WSDL e escolha a ação pop-up Generate Client no menu Web Services. Ao executar esse assistente, selecione Test the generated proxy
Ao gerar esqueletos ou clientes de um arquivo WSDL que possui importações relativas e é protegido por HTTP Basic Authentication, o usuário verá uma mensagem de erro indicando que o arquivo WSDL não pode ser resolvido mesmo se o ID do usuário e a senha corretos forem inseridos. O problema é que o ID do usuário e a senha apenas são utilizados para recuperar o arquivo WSDL original e não os arquivos importados.
Para superar esse problema, o usuário pode fazer download do arquivo WSDL e de todos os arquivos que ele importa primeiro para o workbench e, em seguida, gerar o esqueleto ou o cliente a partir do arquivo WSDL.
- Nenhum Suporte para WSDL: Não é suportada a adição de WSDL ao URL de nó de extremidade de um serviço da Web implementado no WebSphere v5.0.2, sendo executada no Ambiente de Teste ou ambiente do servidor remoto, para obter o arquivo WSDL para o serviço da Web implementado. O arquivo WSDL gerado pode ser encontrado em WebContent/WEB-INF/wsdl do projeto Web para o serviço da Web do Java bean e em ejbModule/META-INF/wsdl do projeto EJB para o serviço da Web EJB. Se for requerido o WSDL que atende um projeto da Web, o usuário poderá fazer referência à cópia do arquivo WSDL em WebContent/wsdl do projeto Web ou criar sua própria localização em WebContent e atender o WSDL do projeto Web.
- Tendo o utilitário JAR ou mais de uma pasta de origem: Ao criar o serviço da Web do Java bean ou EJB, poderão ser gerados arquivos desnecessários no módulo, se houver mais de uma pasta de origem no projeto Web ou se os beans estiverem em um utilitário JAR dentro do arquivo EAR. Desde que esses arquivos gerados já existam no módulo (no utilitário JAR ou em outra pasta de origem), é preciso que eles sejam excluídos do projeto para compilação e do serviço da Web para funcionar corretamente. A outra solução alternativa é mesclar a pasta de origem em uma ou copiar os beans do utilitário JAR na pasta de origem.
- Matriz Não Suportada em RPC/literal: Ao criar um serviço RPC/literal, a assinatura do método não pode conter uma matriz nela. Se contiver, o serviço não poderá ser chamado com o código do cliente gerado. Atualmente, não há soluções alternativas para esse problema. Tente utilizar documento/literal ou RPC/codificado, se possível.
- Sobrecarga de Métodos Não Suportada no Documento/Literal: A sobrecarga de métodos (mesmo nome do método, parâmetros de entrada diferentes) não é suportada na criação de um serviço de documento/literal. Atualmente, não há soluções alternativas para esse problema. Tente utilizar RPC/literal ou RPC/codificado, se possível.
- Importação de WSDL: A instrução de importação de WSDL apenas pode ter URLs absolutos ou URLs relativos no mesmo diretório. Por exemplo, a importação relativa no formulário a seguir não é suportada:
<import namespace="http://someNamespace/" location="../someFile.wsdl"/>- Elemento Binding Antes do Elemento portType: Você irá obter "Error in generating Java files and deployment descriptors from WSDL file (detail: duplicate operation name)" ao gerar o proxy do cliente ou esqueleto a partir de um arquivo WSDL que contém o elemento binding antes do elemento portType.
- Elementos Abstratos: Ao gerar esqueletos a partir de um arquivo WSDL com a operação que utiliza elementos ou tipos abstratos, os JavaBeans gerados não serão compilados.
- Tipos Sem Mapeamentos JAX-RPC Padrão: Ao gerar esqueletos a partir de um arquivo WSDL com operações que têm parâmetros inout de tipos que não possuem nenhum mapeamento JAX-RPC padrão, o bean de implementação gerado não será compilado. O problema é que quando javax.xml.soap.SOAPElement é criado a partir do javax.xml.soap.SOAPFactory, ele emitirá um javax.xml.soap.SOAPException. O bean de implementação não captura ou recaptura essa exceção, portanto, ele não será compilado.
- Mesmo Tipo de Esquema para Entrada e Saída: Ao gerar esqueletos a partir de um arquivo WSDL que utiliza o mesmo tipo de esquema XML para suas mensagens de entrada/saída e mensagens de falha, os artefatos gerados não funcionam no tempo de execução. Para superar esse problema, não compartilhe as definições de tipos de esquemas XML entre mensagens de entrada/saída e mensagens de falha.
- Referências de Elementos XSD com minOccurs e maxOccurs: Ao gerar esqueletos a partir de um arquivo WSDL, não utilize referências de elementos XSD com valores minOccurs e maxOccurs especificados pelo usuário (<element ref="..." minOccurs="0" maxOccurs="unbounded"/>). O uso de tal elemento resultará em um java.util.MissingResourceException durante a inicialização do servidor.
- Bean Emitido Tendo APIs Diferentes do Bean de Serviço: Se os beans gerados pelo emissor tiverem APIs diferentes do bean de serviço, ao criar um serviço da Web de um Java bean ou EJB, você poderá executar no erro de tempo de execução como o seguinte:
O método é indefinido.
Impossível localizar uma operação Java correspondente.
Os exemplos de bean de serviço que possuem APIs diferentes dos beans gerados são:
- beans com campos públicos,
- campos booleanos com getter nomeado obtiveram BooleanValue em vez de BooleanValue,
- nome do método com nome do método em maiúscula
Documento Literal com Quebra de Linha Ativada: Ao criar o serviço da Web de baixo para cima utilizando o documento literal, por padrão, a opção de quebra de linha está ativada. Você pode executar o problema de interoperabilidade, se tiver mais de uma entrada com tipos diferentes ou absolutamente nenhuma entrada. A solução alternativa é utilizar RPC/literal. Java bean com Nome com Letra Minúscula ou Sublinhado: Ao criar o serviço da Web a partir de um Java bean com nome de arquivo com letra minúscula ou sublinhado seguido de uma letra minúscula, você obterá o erro:
Error in generating Java files and deployment descriptors from WSDL file with details of getOutputStream() IOException.Configuração de Segurança Diferente: Não gere serviços da Web com configurações de segurança diferentes no mesmo módulo/projeto. Utilize projetos separados para cada serviço da Web.
Se o WebSphere Application Server V5.0 estiver sendo utilizado para acomodar um serviço da Web DADX, então, o arquivo group.properties para o grupo DADX deverá utilizar a seguinte propriedade initialContextFactory:
initialContextFactory=com.ibm.websphere.naming.WsnInitialContextFactoryAlém disso, o arquivo web.xml do projeto que contém o grupo DADX precisa ter adicionado o seguinte: (Supondo que o nome JNDI do DataSource é jdbc/hospital.)
<resource-ref id="ResourceRef_1058550453092">
<res-ref-name>jdbc/hospital</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>CONTAINER</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
Quando o Universal Test Client não consegue pré-carregar a classe de localizador de cliente gerada pelo tempo de execução do WebSphere v5.0.2 ou Axis, isso ocorre porque o nome da classe do Java bean no projeto Web de serviço é o mesmo que o nome da classe SEI no projeto Web do cliente. Para solucionar esse problema:
- Remova o projeto Web do cliente do espaço de trabalho
- Clique com o botão direito do mouse no projeto Web do cliente e clique em "Delete".
- Localize o application.xml no projeto EAR e dê um clique duplo no arquivo para abrir até o editor Application Deployment Descriptor. Selecione o módulo do projeto Web do cliente e clique em "Remove". Feche o editor e salve as alterações.
- Crie o projeto Web do cliente em um EAR diferente, onde o nome do projeto EAR precisa estar alfabeticamente à frente do nome do projeto EAR de serviço. Por exemplo, se o nome do projeto EAR de serviço chamar "DefaultEAR", crie o novo nome do projeto EAR chamado "ClientEAR".
- Execute novamente o assistente Web Service.
As preferências de sobreposição de arquivos, de criação de pasta e de registro de saída de arquivo automático não são observadas na criação de serviços da Web utilizando o tempo de execução do WebSphere v5.0.2 e Axis. A criação de pasta sempre é permitida e o registro de saída de arquivo automático nunca está ativado.
Ao utilizar o tempo de execução do WebSphere v5.0.2, o arquivo WSDL, o SEI e os artefatos de implementação (serializam e deserializam) são sempre sobrescritos. Os artefatos de desenvolvimento (bean de serviço, beans do tipo complexo, portador e classe do ajudante) nunca são sobrescritos. Entretanto, o usuário receberá um aviso a respeito da sobreposição dos descritores de implementação, se eles já existirem. O usuário pode selecionar OK para sobrescrever os descritores de implementação e continuar com o cenário, ou Cancel para evitar sobrescrever os descritores.
Ao utilizar o tempo de execução do Apache Axis 1.0, os emissores do Axis geram novamente a cada momento todos os arquivos Java do cliente/servidor, deploy.wsdd e undeploy.wsdd. O WSDL2Java para o cenário de geração de serviço gerará apenas o arquivo de implementação de esqueleto, se ele ainda não existir. Se essa implementação já existir, ela não será sobrescrita.
Criar serviços da Web utilizando o tempo de execução do Apache Axis 1.0 conta com os emissores Java2WSDL e WSDL2Java fornecidos no Axis 1.0. O suporte para documento/literal e documento/literal (agrupado) é problemático no Axis 1.0, entretanto, o usuário deve utilizar o RPC/codificado ao criar serviços da Web utilizando o tempo de execução do Apache Axis 1.0.
Ao definir o mapeamento personalizado entre pacote e espaço de nomes, o pacote e espaço de nomes padrão incorretos aparecem na tabela após clicar no botão Add, o usuário deve sobrescrever esses padrões e inserir seu próprio mapeamento de pacote e de espaço de nomes.
Ao gerar esqueletos de serviços da Web ou proxies de WSDL que utiliza o mesmo nome para um de seus elementos <serviço> elemento e <porta>, não utilize JSPs de amostra como o cliente de teste. Os JSPs de amostra gerados contêm erros e não serão compilados. Qualquer tentativa de executar os JSPs de amostra no servidor resultará em um ERRO 500 no navegador, indicando que os JSPs de amostra não podem ser carregados e as exceções no console do servidor indicando que o contêiner do servlet não conseguiu compilar os JSPs de amostra.
Ao executar a ferramenta da linha de comandos no Windows em alemão, determinados caracteres são mostrados como "?" na saída do prompt de comandos. É provável esse caractere seja um trema alemão.
O assistente para criação de Serviço da Web pode falhar durante a geração de WDSL se o nome de host "localhost" não estiver definido no servidor. O UTC também pode não conseguir ativar com êxito se "localhost" não estiver definido.
No Windows, a seguinte entrada deve estar presente no arquivo [INSTALL-DRIVE]\WINNT\system32\drivers\etc\hosts:
127.0.0.1 localhost
No Linux, a seguinte entrada deve estar presente no arquivo /etc/hosts:
127.0.0.1 localhost
O tempo de execução IBM SOAP deve ser utilizado principalmente por motivos de compatibilidade anterior. É fortemente recomendado que você utilize o assistente Web Services com o tempo de execução do IBM WebSphere 5.0.2 para todas as finalidades de produção. Ao utilizar o assistente Web Services com o tempo de execução do IBM SOAP, o usuário pode ser executado nas seguintes limitações permanentes:
- Gerando um documento WSDL a partir de um Java bean
- Os char e java.lang.Character exigem que a entrada de mapeamentos personalizados uma vez que os mapeamentos padrão de char ou java.lang.Character para WSDL XSD não existem.
- Os tipos de wrapper primitivos, java.lang.Boolean, java.lang.Byte, java.lang.Short, java.lang.Integer, java.lang.Long, java.lang.Float e java.lang.Double, não podem coexistir com seus tipos primitivos individuais correspondentes boolean, byte, short, int, long, float e double, em todos os parâmetros de entrada de um bean de serviço. Por exemplo, um bean de serviço no qual java.lang.Integer e int aparecem em qualquer lugar como tipos de parâmetros de entrada não pode ser transformado em um serviço da Web completo. Quando é feita uma tentativa de utilizar o assistente Web Service para criar um serviço da Web a partir desse tipo de bean de serviço, ocorrerá uma mensagem de aviso, a menos que os métodos que contêm os tipos primitivos ou tipos de wrapper não sejam selecionados na Página Web Service Java Bean Methods do assistente. No entanto, é preciso verificar se esses métodos não são selecionados a primeira vez em que a página Web Service Java Bean Methods é encontrada. Voltar a essa página e eliminar os métodos com problemas após ter visto o aviso poderá gerar um serviço da Web incompleto. Nesse caso, o assistente deverá ser reiniciado para que as seleções de método apropriadas possam ser feitas na primeira vez em que a página Web Service Java Bean Methods for encontrada.
- Matrizes Multidimensionais não são suportadas. Uma alternativa no Java é inserir beans Java entre as dimensões. Por exemplo, em vez de MyType[][], o padrão MyArray[] em que MyArray tem uma propriedade do tipo MyType[] servirá.
- Um método com uma lista de argumentos de entrada contendo uma mistura do elemento DOM e tipos de bean simples requer a entrada de um ou mais mapeamentos personalizados. A especificação Web Services Definition Language (WSDL) Versão 1.1 suporta o estilo de codificação para todas as partes de entrada (parâmetros). O tempo de execução do SOAP (Simple Object Access Protocol) Versão 2.2 não tem suporte ao mapeamento padrão para o Elemento DOM com codificação SOAP para tipos primitivos e beans com codificação Literal XML.
- Ao configurar um mapeamento personalizado, se você tentar utilizar a classe do serializador ou do deserializador a partir do tempo de execução SOAP (isto é, classes do pacote org.apache.soap.encoding.soapenc) e receber o erro "the selected serializer/deserializer class cannot be loaded from this project", provavelmente, soap.jar não está no caminho de construção do projeto Web. Para corrigir o problema, cancele o assistente, utilize o diálogo de propriedades do projeto da Web para adicionar WS_installdir\wstools\eclipse\plugins\com.ibm.etools.webservice\runtime\soap.jar ao caminho de construção do projeto da Web e, em seguida, repita o assistente para serviços da Web.
- O mapeamento personalizado não é suportado para tipos complexos aninhados. Embora os tipos aninhados apareçam na página de mapeamento do assistente, os mapeamentos personalizados para esses tipos serão ignorados.
- Ao criar um serviço da Web a partir de uma classe Java cuja interface contém um tipo Java abstrato, a página Web service Java to XML Mappings pode definir incorretamente o campo do deserializador do tipo abstrato como org.apache.soap.encoding.soapenc.BeanSerializer. Esse procedimento falhará em tempo de execução, pois o código deserializer na classe BeanSerializer não poderá construir uma instância do tipo abstrato. Para evitar isso, escolha a opção Custom mapping para o tipo, se necessário e altere o campo deserializer para o nome de uma classe gravada para cancelar a seriação do tipo abstrato.
- As ferramentas de serviços da Web não suportam atualmente a criação de serviços da Web a partir de Java Beans que contenham classes internas aninhadas (isto é, classes internas definidas em uma classe de nível máximo). Para resolver esse problema, você deve mover as classes internas para as classes de nível máximo em arquivos Java separados.
- Ao criar um Serviço da Web a partir de um Java bean que utiliza outros Java Beans com propriedades de tipo Vector, Hashtable ou Map, o XSD será gerado com complexTypes contendo os tipos "Vector" e "Map" do espaço de nomes "http://xml.apache.org/xml-soap". Como atualmente não existe um esquema para esse espaço de nomes, o XSD Validator produzirá erros e avisos como os seguintes:
Esses erros e avisos não interferirão com o processamento correto do WSDL e do XSD pelos assistentes de Serviços da Web. Os tipos "Map" e "Vector" serão mapeados corretamente para seus correspondentes em Java. Observe que outros fornecedores podem ter dificuldades para processar WSDL ou XSD contendo esses tipos porque http://xml.apache.org/xml-soap não é um espaço de nomes reconhecido pelas especificações WSDL 1.1 ou SOAP 1.1. Para melhorar a interoperabilidade, considere adaptar as classes de coleção Java para matrizes e beans e, em seguida, construir Serviços da Web a partir dos adaptadores.
- Error src-resolve: Cannot resolve the name 'xsd2:Vector' to a(n) type definition component.
- Warning src-import.0: Failed to read imported schema document 'null'.
- Gerando um Artifact Java a partir de um Documento WSDL
- O suporte é limitado a uma parte por elemento de entrada ousaída. Não há suporte para múltiplas partes lógicas em uma mensagem de entrada ou saída. A primeira de tais partes será processada e as outras remanescentes serão ignoradas.
- Ao gerar esqueletos ou proxies do serviço da Web a partir do WSDL que utiliza o tipo base64Binary a partir do espaço de nomes xsd (http://www.w3.org/2001/XMLSchema), o tempo de execução do serviço da Web utilizará na verdade xsi:type base64 a partir do espaço de nomes soapenc (http://schemas.xmlsoap.org/soap/encoding/). Em geral, os dois tipos podem ser intercambiados livremente. Contudo, é possível que a diferença entre o tipo na mensagem e o tipo no esquema façam com que alguns tempos de execução de protocolo SOAP rejeitem a mensagem. Se isso ocorrer, você pode criar manualmente um serializer semelhante ao Base64Serializer SOAP da Apache, escrevendo xsd:base64binary no lugar de soapenc:base64.
- Os esqueletos do Java bean não serão compilados se forem criados a partir de documentos WSDL que possuem nomes de operações e partes que não sejam identificadores Java válidos. Os nomes de partes e operações do WSDL devem ser identificadores Java válidos para a criação bem-sucedida de um esqueleto de Java bean.
- Os assistentes para serviços da Web utilizam URIs "http" por padrão quando geram o WSDL, no entanto, alguns documentos WSDL de outras ferramentas poderão implementar ocasionalmente URIs de serviços da Web, de Ação SOAP ou de Espaço de Nome de Destino que implementem esquemas diferentes de "http", como "urn". Ao gerar proxies ou esqueletos a partir do WSDL que contêm URIs não-http, os assistentes de serviços da Web podem mapear os URIs para o pacote Java "com.example" em vez de um pacote mais significativo. Em alguns casos, os assistentes para serviços da Web podem falhar em tratar tais URIs completamente e produzir o erro "IWAB0234E An internal error occured."
- Ao gerar proxies e esqueletos Java a partir do WSDL, agora você tem a opção de mapear os tipos intrínsecos XSD boolean, byte, short, int, long, float e double para os tipos wrapper "java.lang" (por exemplo, java.lang.Integer) em vez das primitivas Java (por exemplo, int). Por padrão, os assistentes de serviços da Web mapeiam para as primitivas Java. Para que, em vez disso, os assistentes mapeiem para as classes wrapper "java.lang", abra Windows -> Preferences -> Web Services -> Code Generation e marque "Map simple XML data types to java.lang wrapper classes".
- Ao especificar um mapeamento personalizado de um tipo Java para um tipo XSD em um cenário Java, o campo Bean class é definido automaticamente como o nome completo do tipo Java e não pode ser editado. Ao fazer um mapeamento personalizado de uma matriz Java, o nome da classe de Bean estará em forma de matriz, por exemplo, "java.lang.String[]" e será emitido como tal nos arquivos descritores da implementação ".isd" e "dds.xml". Essa forma de nome de classe não é processada corretamente pelo tempo de execução do SOAP e resultará em um erro similar ao seguinte:
Deployment error in SOAP service http://tempuri.org/webservice.AddressBook: class name java.lang.String[] could not be resolved: java.lang.String[]
Como resultado, não é possível fazer mapeamento personalizado do serializador para uma classe Java no lado do serviço. Uma solução alternativa parcial é deixar o campo Serializer class vazio para o mapeamento personalizado. Isso suprimirá a geração do nome da classe da matriz no descritor de implementação e permitirá que o serviço funcione. Observe que a Serializer class e a capacidade de fazer mapeamento personalizado do desserializador não são afetadas por este problema e sua solução alternativa.
- Considerações de Tempo de Execução
- Se você selecionar a preferência de geração de código de Serviços da Web "Enable element-based mapping" e tiver selecionado para implementar em um WebSphere Application Server V4, a seguinte entrada poderá ser recebida no arquivo ISD e no dds.xml:
<isd:map
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:x=""
qname="x:some-name"
xml2JavaClassName="some-serializer"/>O editor XML pode sinalizar o seguinte erro:
The value of the attribute "xmlns:x" is invalid. Prefixed namespace bindings may not be empty.
Isso é inofensivo para o WebSphere Application Server V4. No entanto, não tente implementar esse dds.xml em outro servidor que utilize Xerces 2.x (XML4J 4.x) ou superior, como o WebSphere Application Server V5. Caso contrário, você obterá um erro de análise de Xerces similar quando o servidor carregar o arquivo dds.xml. Você deve gerar novamente o dds.xml, indo para o cenário de serviço da Web e selecionando o tipo de servidor correto. Isso gerará o dds.xml correto para o tipo de servidor.
Além disso, você obteria um erro de análise similar do Xerces ao tentar implementar o serviço da Web a partir desse arquivo ISD. A solução alternativa é editar manualmente o arquivo para o seguinte formato:
<isd:map
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
qname="some-name"
xml2JavaClassName="some-serializer"/>
- Ao chamar um serviço da Web criado a partir de um Java bean ou EJB, se você receber um SOAPException com um targetException, tal como:
"java.lang.IllegalArgumentException: Unable to instantiate ..."
pode ser que o método exposto como um serviço da Web contenha um Java bean sem um construtor padrão público como um parâmetro e/ou tipo de retorno. Um construtor público padrão é requerido para o tempo de execução de SOAP para construir o objeto como parte do processo de deserialização.- Os arquivos de segurança, cl-ver-config.xml e sv-ver-config.xml, atualmente implementados no projeto Web são os arquivos do WebSphere versão 4.0 e não correspondem exatamente aos DTDs. Mas os arquivos funcionarão no WebSphere versão 4.0 e WebSphere versão 5.0, apesar dos erros de validação indicando que o "xmlns:ds" ou "xmlns:SOAP-SEC" deve ser declarado.
- Se a Server Configuration for aberta em um editor, o assistente Web service poderá falhar ao iniciar o servidor porque o projeto da Web do Web Service não foi incluído na Server Configuration. Fechar o editor Server Configuration resolverá o problema.
- Serviços ISD da Web
- Depois de preencher um mapeamento personalizado ao criar serviços Java ou EJB da Web, as informações de mapeamento personalizado, exceto a URL de Localização do XSD, são armazenadas no arquivo ISD. As informações são recuperadas ao criar serviços da Web a partir desse arquivo ISD. Portanto, ao criar serviços da Web a partir de um arquivo ISD, na página Web Service Java to XML Mappings do assistente, é preciso preencher o URL de localização de XSD manualmente.
Se você criar o serviço da Web de um Java bean ou EJB, escolhendo o IBM SOAP para o tempo de execução de serviço e Apache Axis 1.0 como o tempo de execução do cliente, poderá obter o erro:
WSDL Not found
Para evitar esse problema, primeiro crie o serviço da Web sem optar por gerar um proxy. Em seguida, crie um cliente de serviço da Web a partir do arquivo WSDL gerado.
Ao executar o assistente Web service client, se o usuário clicar em Finish na página Client Environment Configuration, será obtido o erro:
"null" is not resolvable
A solução alternativa é pressionar Next nessa página e na página seguinte, em seguida, pressionar Finish.
Em Create, test and validate a WS-I compliant Web Service Cheatsheet e Create a Web Service from a WSDL file CheatSheet, se você estiver utilizando o arquivo HelloService.wsdl a partir do wsad_install/wstools/eclipse/plugins/com.ibm.etools.cs.wsdl.content_5.1/examples, modifique a localização da porta de serviço de acordo com o tempo de execução diferente, da seguinte maneira:
Para IBM Soap:
location="http://localhost:9080/HelloWorldSample/servlet/rpcrouter"
Para o tempo de execução do Apache Axis ou WebSphere 5.0.2
location="http://localhost:9080/HelloWorldSample/services/Hello_Port"
Se você estiver importando seu próprio arquivo wsdl, certifique-se de que a localização esteja correta de acordo com o tempo de execução selecionado, como mencionado acima.
Retornar para o arquivo leia-me principal
(C) Copyright IBM Corporation 2000, 2003. Todos os Direitos Reservados.