WebSphere 8 Intro (pt-BR)

WebSphere Application Server
Introdução Técnica ao WebSphere Application
Server V8.0
SSO Middleware © 2009 IBM Corporation

Agenda
 Família WebSphere
 Middleware
 Tecnologia Java
 JEE
 WAS v8
 IHS (IBM HTTP Server)
 Administração
 Diagnóstico de problemas
© 2009 2 SSO Middleware IBM Corporation

Família WebSphere 8

 A suite de produtos da família WebSphere engloba diversos
produtos diferentes mas que juntos possibilitam a integração das
aplicações e a infra-estrutura necessária para as mesmas.
 Todos os produtos são direcionados para o mercado e-business e
são categorizados em 3 áreas:
– Foundation & Tools: produtos que ajudam o cliente a atingir
escalabilidade e produtividade quando precisam desenvolver ou
aumentar aplicações e-business de forma rápida e confiável.
– Reach & User Experience: produtos que ajudam o cliente a atingir a
lealdade dos seus usuários permitindo extender e personalizar a
experiência de cada um deles.
– Business Integration: produtos que ajudam o cliente a atingir
agilidade nos negócios integrando as aplicações e automatizando os
processos de negócios.

 Foundation & Tools
– WebSphere Application Server
– WebSphere MQ: Troca de informações
entre mais de 35 plataformas diferentes
com garantia de entrega.
– WebSphere Studio:Desenvolvimento de
applicações JEE.
 Reach & User experience
– Websphere Portal: Ajuda a construir
portais escaláveis e portáveis .
– WebSphere Everyplace: Conecta pessoas
em trânsito a informações e aplicações.
– WebSphere Commerce: Ajuda as
empresas a conseguirem que seus clientes
faça negócios on demand.
 Business Integration
– WebSphere Business Integration: BPM.
– WebSphere MQ Integration: BPM.
• BPM: Business Process Management.
WebSphere Application Server é um dos
principais produtos da família WebSphere. Ele
server como base para outros produtos e
ferramentas.
Trata-se de um middleware que provê uma
plataforma baseada nos padrões JEE e Web
Services para que aplicações Java possam rodar.

WebSphere Application Server – Apresentação

Família WebSphere – WAS 8
Plataforma Express v8.0 * Base v8.0 ND v8.0
WebSphere Application Server Sim Sim Sim
Deployment Manager Não Não Sim
IHS Sim Sim Sim
IHS Plugins Sim Sim Sim
Application Client Sim Sim Sim
Application Server Toolkit (ASTK) Sim Sim Sim
DataDirect Technologies JDBC Drivers
Sim Sim Sim
for WebSphere Application Server
Development tools Rational Web
Developer (single use
license)
Rational Application
Developer Trial
Rational Application
Developer Trial
Database IBM DB2 Universal
Database™ Express
V9.7
IBM DB2 Universal
Database Express
V9.7 (development
use only)
IBM DB2 UDB Enterprise
Server Edition V9.7 for
WebSphere Application
Server Network
Deployment
Production ready applications IBM Business
Solutions
Não Não
Tivoli® Directory Server for WebSphere
Application Server
(LDAP server)
Não Não Sim
Tivoli Access Manager Servers for
Não Não Sim
Edge Components Não Não Sim
* Limitada ao máximo de 2 CPUS

Middleware
1. Software que funciona como um conversor ou uma camada de tradução.
Soluções de middleware estão sendo desenvolvidas durante décadas
para possibilitar a comunicação/conectividade entre aplicações que
rodam em diferentes plataformas ou aplicações desenvolvidas por
diferentes fornecedores.
2. Middleware, no campo de computação distribuída, é um programa de
computador que faz a mediação entre outros softwares. É utilizado para
mover informações entre programas ocultando do programador
diferenças de protocolos de comunicação, plataformas e dependências
do sistema operacional. É geralmente constituído por módulos dotados
com APIs de alto nível que proporcionam a sua integração com
aplicações desenvolvidas em diversas linguagens de programação e
interfaces de baixo nível que permitem a sua independência relativamente
ao dispositivo (http://pt.wikipedia.org/wiki/Middleware)
3. Um software de sistema que provê às aplicações um ambiente
padronizado para sua execução, gerenciamento e análise de
performance. Ele encapsula os serviços do sistema operacional e da rede
de forma facilitar a construção de aplicações.

Middleware
Aplicação
Middleware
SO
JEE
LINUX
AIX
JEE
CISC Hardware
RISC Hardware
Aplicação
Middleware
SO

Tecnologia Java

Tecnologia Java – Histórico
 1991 – Inicio do projeto para criação da nova linguagem de programação (Green Project)
 1992 – Surge a linguagem com o nome de Oak.
Primeira máquina virtual implementada.
Tentativas sem sucesso para venda do produto
 1994 – Com o advento da internet a Sun vê uma nova possibilidade e cria uma linguagem
para construção de aplicativos Web baseada no Oak: Java
 1995 – Netscape aposta na idéia e passa a incorporar os interpretadores Java nos seus
navegadores
 1999 – Surgimento da plataforma JEE e JME
 Atualmente a tecnologia Java é amplamente utilizada e serve para o desenvolvimento de
qualquer tipo de aplicação: web, desktop, servidores, mainframes, jogos, celulares, etc..
 Java tem o apoio, a participação e o patrocinio das maiores organizações e empresas de
tecnologia do mundo: IBM, Sun, Oracle, Nokia, HP, Apache, Cisco, dentre outras.

Tecnologia Java – Conceito
 Não é somente uma linguagem de programação mas também
uma plataforma.
 A linguagem de programação Java é uma linguagem de alto nível caracterizada por ser
robusta, simples, de arquitetura neutra, portável, orientada a objetos, de alta performance,
distribuída, dinâmica, segura e com suporte a multithreads.
 Todo código fonte java é primeiro escrito como texto usando a extensão .java no nome do
arquivo. Os arquivos .java são compilados em arquivos .class através do compilador javac.
Um arquivo .class não contém código inteligível pelo processador nativo, ao invés disso,
contém bytecodes. Bytecode é a linguagem binária do Java Virtual Machine (JVM).

 O JVM é disponibilizado em inúmeros sistemas operacionais
diferentes por o mesmo arquivo .class pode rodar no Microsoft
Windows, no Solaris, no Linux ou MacOS.

 Uma plataforma é o ambiente de hardware ou software no qual um programa
roda. Plataformas populares como Microsoft Windows, Solaris, Linux e MacOS
podem ser descritas como uma combinação de sistema operacional e um
hardware por debaixo.
 A plataforma Java possui dois componentes:
 JVM.
 Java Application Programming Interface (API).
 A plataforma Java difere das plataformas mencionadas pois é uma plataforma baseada
somente em software que roda sobre uma outras plataformas.
 Por ser uma plataforma independente do ambiente a plataforma Java pode ser um pouco
mais lenta do que código nativo, mas isso está mudando com os avanços no compilador e
no JVM.

Tecnologia Java
Java se divide em três grandes edições:
 J2SE ou JSE - É a tecnologia Java para computadores pessoais, notebooks e arquiteturas com poder de
processamento e memória consideráveis.
 J2EE ou JEE - É a tecnologia Java para aplicações corporativas que podem estar na internet ou não.
 J2ME ou JME - É a tecnologia Java para dispositivos móveis com limitações de memória ou processamento. Possui
APIs bem simples e leves para economizar espaço, memória e processamento.

JEE

JEE
1. Sigla para “Java platform, Enterprise Edition”
2. A especificação JEE é um padrão para desenvolvimento, instalação e
execução de aplicações comerciais construídas sobre o JSE.
3. O padrão JEE é composto pelos seguintes elementos:
 Modelo de aplicação padronizado para desenvolvimento de aplicações
multi-camadas.
 Plataforma padronizada para hospedar aplicações.
 Um conjunto de testes de compatibilidade para certificar que um
produto é compatível com o protocolo JEE.
 Uma implementação de referência que provê uma definição
operacional do JEE.
4. A especificação JEE descreve um ambiente de execução para uma
aplicação JEE. O ambiente incluí os componentes da aplicação,
containers e gerenciadores de recursos. Os elementos se
comunicam entre si usando um conjunto de serviços especificados.

JEE - Papéis
1. O padrão JEE também define papéis distintos durante o ciclo de vida do
desenvolvimento e implantação de uma aplicação:
 Product Provider: Desenha e oferece a plataforma JEE, APIs e outras
funcionalidades definidas no JEE.
 Tool Provider: Provê ferramentas para o desenvolvimento e empacotamento
dos componentes das aplicações.
 Application Component Provider: Cria componentes WEB, EJBs, Applets e
aplicações clientes para serem usados em aplicações JEE.
 Application Assembler: Empacota os componentes criados pelo Component
Provider para formar uma aplicação JEE.
 Application Deployer: Responsável pela implantação da aplicação JEE na
plataforma JEE.
 System Administrator: Responsável pelo ambiente operacional onde as
aplicações rodam.

JEE - Benefícios
 A especificação JEE oferece aos clientes uma proteção ao seu
investimento quando adquirem ou desenvolvem aplicações. A Sun
certifica os produtos que são compatívies com o protocolo JEE.
 Oferece uma arquitetura simplificada e baseada em componentes,
serviços e programas clientes padrões que se utilizam da vantagem da
tecnologia Java: write-once, run-anywhere.
 Possuí serviços que proveem integração com sistemas legados com
transações confiáveis e com garantia. Exemplos: JDBC, JMS, JCA,
Java IDL, JavaMail API, JTA, JTS.
 Oferece escalabilidade para atender demanda distribuindo os
containers através de vários servidores e usando o conceito de
connnection pooling.
 Soluções padronizadas permitem uma melhor escolha dentre os
produtos disponíveis no mercado.
 Oferece um modelo de segurança bastante flexível que provê SSO,
integração com outros sistemas de segurança e uma maneira unificada
de deixar os componentes da aplicação seguros.

JEE – Serviços padrões
 HTTP and HTTPS
 Remote Method Invocation/Internet Inter-ORB Protocol (RMI/IIOP)
 Java Interface Definition Language (Java IDL)
 Java DataBase Connectivity (JDBC)
 Java Message Service (JMS)
 Java Naming and Directory Interface (JNDI)
 JavaMail API and the JavaBeans Activation Framework (JAF)
 Java Transaction API (JTA and JTS)
 XML
 JEE Connector Architecture
 Resource managers

JEE – Aplicação x Componentes
 Uma aplicação JEE é construída de componentes. Os componentes
são pedaços de código Java com arquitetura, modelo de programação,
funções e empacotamento bem definidos dentro do protocolo JEE.
 Os principais tipos de componentes de uma aplicação JEE são:
– Enterprise JavaBeans (EJB)
– Servlets
– JavaServer Pages (JSP)
– Applets
– Application Clients
 Cada componente é empacotado de uma forma padrão e individual. Os
componentes são montados juntos em um outro pacote para formar
uma aplicação JEE.

JEE – Componentes x Containers x Empacotamento
Componente Container Pacote
EJB – Enterprise JavaBeans EJB Container EJB JAR
Servlet WEB Container WAR
JSP – JavaServer Pages WEB Container WAR
Application clients Application Client Container JAR
Java Applets JVM/BROWSER CLASS
Enterprise Application --------------- EAR
 Os containers JEE oferecem um ambiente de execução para os componentes da aplicação. É
necessário pelo menos um container para cada tipo de componente em uma aplicação dita JEE.
O container oferece APIs para os componentes acessarem os serviços. Ele também gerencia a
segurança dos componentes, os recursos que podem ser usados pelo componente, o estado
dos componentes que estão rodando nele, o serviço de nomes e as transações realizadas pelos
componentes.

JEE – Empacotamento
 WAR (Web ARchive)
– É um arquivo com uma estrutura interna bem definida
que pode ser aberto com a ferramenta JAR. Ele
possuí os JSPs e Servlets de uma aplicação JEE.
 Conteúdo
– JSPs
– Servlets
 Estrutura
+ war-ic.war/
|--- index.jsp
|--+ META-INF/
| |--- MANIFEST.MF
'--+ WEB-INF/
'--- web.xml

 EJB JAR (EJB Java ARchive)
– É um arquivo com uma estrutura interna bem
definida que pode ser aberto com a ferramenta
JAR. Ele possuí os EJBs de uma aplicação
JEE.
 Conteúdo
– EJBs
 Estrutura
+ ejb-jar-ic.jar/
|--- Converter.class
|--- ConverterBean.class
|--- ConverterHome.class
'--+ META-INF/
|--- MANIFEST.MF
'--- ejb-jar.xml

 Application Client JAR (Application Client Java
ARchive)
– É um arquivo com uma estrutura interna bem definida que
pode ser aberto com a ferramenta JAR. Ele possuí o código do
cliente Java para uma aplicação JEE.
 Conteúdo
– Código Java do Cliente
 Estrutura
+ app-client-ic.jar/
|--- ConverterClient.class
'--+ META-INF/
|--- MANIFEST.MF
'--- application-client.xml

JEE - Empacotamento
 EAR (Enterprise ARchive)
– É um arquivo com uma estrutura interna bem definida que pode
ser aberto com a ferramenta JAR. Ele possuí todos os
componentes de uma aplicação JEE.
 Conteúdo
– Web modules (WAR)
– Enterprise JavaBeans modules (EJB JAR)
– Client modules (JAR)
 Estrutura
+ converter.ear/
|--- converterClient.jar
|--+ META-INF/
| |--- MANIFEST.MF
| |--- application.xml
|--- war-ic.war
|--- ejb-jar-ic.jar
'--- app-client-ic.jar

JEE – Aplicação de 3 camadas
 Primeira camada: responsável pela apresentação e pela interação do usuário
com o sistema.
 Segunda camada: responsável pela lógica de negócio da aplicação.
 Terceira camada: responsável pelos sistemas de informação como bancos de
dados e sistemas legados.
 Comunicação entre as camadas: acontece usando protocolos padrões e abertos
e APIs expostas.

JEE – Componentes x 3 camadas

JEE – Níveis no WAS
 O WAS V8.0 continua com a tradição de fornecer suporte para a atual especificação JEE. Nessa
versão, o WAS provê suporte completo para a especificação Java EE 6:
Specifications V6.1 V7.0 V8.0
Java related · Requires JDK 1.4.2
· Supports J2EE 1.4:
o Servlet 2.4
o JSP 2.0
o EJB 3
o JTA 1.0.1B
o JMS 1.1
o JSF 1.1
o JPA 1.0
o JAX-WS 2.0
o JDBC 3.0
· Requires JDK 6
· Supports JEE 6 levels:
o Servlet 2.5
o JSP 2.1
o EJB 3.0
o JTA 1.1
o JMS 1.2
o JSF 1.2
o JPA 2.0
o JAX-WS 2.1
o JDBC 4.0
· Requires JDK 6
· Supports JEE 6 levels:
o Servlet 3.0
o JSP 2.2
o EJB 3.1
o JTA 1.1
o JMS 1.2
o JSF 2.0
o JPA 2.0
o JAX-WS 2.2
o JDBC 4.0
Web Services · Web Services for Java Platform,
Enterprise Edition (Java EE)- JSR 109
1.1
· SOAP with Attachments API for Java
(SAAJ) 1.3 for Feature Pack for Web
Services
· Universal Description, Discovery and
Integration (UDDI) V3
· Web Services for Java Platform, Enterprise Edition
(Java EE)- JSR 109 1.2
· SOAP with Attachments API for Java (SAAJ) 1.3
· Universal Description, Discovery and Integration
(UDDI) V3
· Web Services for Java Platform, Enterprise Edition
(Java EE)- JSR 109 1.3
· SOAP with Attachments API for Java - SAAJ 1.3
· Universal Description, Discovery and Integration
(UDDI) V3

Novidades no WAS 8
Diretório monitorado para o install, uninstall e update de aplicações, formatos
compatíveis são:
EAR (Enterprise Archive)
WAR (Web Application Archive)
JAR (Java Archive)
SAR (SIP Application Resource)
Java EE 6
IBM Assembly & Deploy Tools for WebSphere
Administration - Similar ao antigo Application Client.
IBM Installation Manager
Nova ferramenta, substitui o instalador default do WAS, o ISMP e o
Update Installer.
Ela faz a instalação e update do WebSphere e IHS.
Você pode instalar o WebSphere com o fixpack em um comando.
Possui as seguintes interfaces Gráfica (GUI), Command Line e
Response files que podem ser gerados utilizando a interface GUI.
Suporta Produtos da família WebSphere e Rational

Novidades no WAS 8
Mudanças no CIM (Centralized Installation Manager)
Agora é possível utilizá-lo através do Job Manager e Deploy Manager(Este desde a V7).
Não é mais necessário agentes nos target servers.
High Performance Extensible Logging (or HPEL)
O log do WebSphere torna-se binário nesta opção
Log é 6x e o Trace é 3.8x mais rápido que a v7
É possível fazer filtros e formatações através do comando logviewer.sh(bat)
Criação de células via template
É possível criar uma nova célula baseada
em um backup de uma célula existente.

Novidades no WAS 8
Mudança dos nodes para um novo ambiente
 Nova opção para mover um nó de um ambiente para outro, por exemplo AIX para Windows
 Os nós de zOS não podem serem movidos para ambientes multiplataforma.
 Com este comando também é possível recuperar o nó com problemas, ex. faltando arquivos xml de
configuração.
 Comando "addNode -asExistingNode"
IBM WebSphere Application Server Migration Toolkit
 Migra aplicações de versões anteriores do WebSphere
(5.1, 6.0, 6.1 ou 7.0), Oracle AS/WLS ou JBOSS para WAS v8.
 Compatível com o Eclipse e RAD.

Novidades no WAS 8
Novos Feature Pack

WAS – Arquitetura StandAlone Server

WAS – Arquitetura Network Deployment

WAS – Células, Nós e Servidores
 Não importando a configuração, o WAS é organizado baseado em conceitos
como células, nós e servidores.
 Servidores
– São os elementos que realmente fazem a execução de código. Existem diversos
tipos de servidores e cada um roda em sua própria instância de JVM.
 Nós
– É agrupamento lógico de processos gerenciados de WAS que compartilham uma
configuração e um controle operacional comum. Um nó é geralmente associado a
uma instalação de WAS. As configurações Express e Base do WAS possuem
apenas um nó. As demais configurações de WAS podem conter vários nós
gerenciados de um único servidor administrativo e o conceito de balanceamento de
carga entre os nós é introduzido.
 Células
– É o agrupamento lógico de nós dentro de um domínio administrativo. Nas
configurações Express e Base temos uma célula com um único nó. Esse nó pode
ter vários servidores mas cada servidor tem que ser gerenciado individualmente. As
demais configurações de WAS uma célula pode conter diversos nós, todos
administrados de um único lugar.

WAS - Células, Nós e Servidores

WAS – Servidores
 WAS utiliza servidores para prover as funções necessárias requeridas para hospedar
uma aplicação JEE. Temos 3 tipos distintos de servidores dentro do WAS:
– Servidor de aplicação: executa a aplicação do usuário. Um servidor de aplicação pode
atuar sozinho ou em cooperação com outros servidores de aplicação sendo este
membro de um cluster.
– Servidor JMS: provê suporte a mensageria embarcada. Trata-se um WMQ simplificado.
Express Base ND
Application server Yes Yes Yes
Yes (integrated into Yes
application server)
JMS server No
Application server clustering No No Yes

WAS – Servidor de aplicação
 Servidores de aplicação provêem um ambiente de execução para o código
da aplicação. Eles oferecem containers e serviços específicos para cada
componente da aplicações Java.
 Cada servidor de aplicação roda em seu próprio JVM. No profile de
Application Server um servidor de aplicação chamado server1 é criado
automaticamente. Servidores de aplicação adicionais podem ser criados,
mas a não ser que você esteja usando a configuração ND, os servidores de
aplicação deverão ser configurados independentemente e não suportarão
balanceamento de carga nem tolerância a falhas.

WAS – Servidor JMS
 Suporte a mensageria é conseguida através dos JMS Providers abaixo:
– WebSphere JMS Provider (Embarcado)
– WebSphere MQ JMS Provider
– Generic JMS Provider
 Se você utilizar o WebSphere MQ JMS Provider ou o Generic JMS Provider
as funções do JMS serão providas por um produto externo.
 Já o Websphere JMS Provider está presente em todas as configurações do
WAS. As funções de mensageria providas pelo WebSphere JMS Provider
incluem:
– MDBs (Message-Driven Beans)
– Point-to-Point Publish/Subscribe
– Serviço de gerenciamento de transações

WAS – Clusters
 A configuração ND oferece a opção de montar um cluster de servidores de
aplicação para distribuição de carga. Um cluster é uma coleção de
processos de servidores de aplicação com o único propósito de prover
balanceamento de carga e tolerância à falhas.
 Servidores de aplicação que pertençam a um cluster são considerados
membros deste cluster e precisam ter componentes de aplicações idênticos
instalados nos mesmos. Os membros de um cluster apenas compartilham
as aplicações que foram configuradas para rodarem neles.
 Quando você instala, atualiza ou remove uma aplicação as mudanças são
propagadas por todos os membros do cluster.
 Instalar uma aplicação em um cluster automaticamente habilita o
balanceamento de carga.

WAS – Containers
 A especificação JEE 6 define o conceito de containers para prover
suporte de execução às aplicações. Existem 2 containers na
implementação do servidor de aplicação:
– Web container: processa requisições HTTP, servlets e JSPs
– EJB container: processo Enterprise JavaBeans
 Além disso o Application Client Container pode rodar na máquina
cliente.
Express Base ND
Web container Yes Yes Yes
EJB container Yes Yes Yes
Application client container Yes Yes Yes

WAS – Web Container
 O Web Container processa Servlets, arquivos JSP e outros tipos de
arquivos server-side. Cada servidor de aplicação tem um único Web
Container lógico interno.
 Características:
– Processamento de Servlet
– Servidor HTTP embarcado
– Gerenciamento de sessão
– Web Services engine
 Um único container pode conter vários arquivos WAR instalados.

WAS – Plug-in
 Apesar do Web Container possuir um Servidor Web embutido, num cenário real é
mais provável que um Servidor Web mais complexo e robusto seja usado (IHS,
Apache, IIS).
 Um servidor Web serve requisições de conteúdo estático como figuras e arquivos
HTML. Porém, conteúdo dinâmico como um arquivo JSP ou um Servlet
necessitam de um Web Container/Servidor de aplicação. Para que a requisição
que chega no Servidor Web seja redirecionada para o Servidor de aplicação
quando trata-se de conteúdo dinâmico o WAS disponibiliza o plug-in que é
instalado no Servidor Web.
 O plug-in usa um arquivo de configuração chamado plugin-cfg.xml para
determinar se uma requisição HTTP deve ir ou não para o Servidor de aplicação.

WAS – EJB Container
 O EJB Container provê todos os serviços necessários para instalação, execução
e gerenciamento de Enterprise Beans.
 Os Enterprise Beans (empacotados em EJB modules) instalados em um Servidor
de aplicação não se comunicam diretamente com o Servidor, ao invés disso o
EJB Container provê um interface entre os EJBs e o Servidor de aplicação.
 Um único container pode conter vários arquivos EJB JARs instalados.

WAS – Serviços do Servidor de aplicação
Service Express and Base Network Deployment
Service Integration Bus service yes yes
Transaction service yes yes
Dynamic cache service yes yes
Message listener service yes yes
Object Request Broker service Administrative
service (Java Management Extensions)
yes yes
Diagnostic trace service yes yes
Debugging service yes yes
Name service (Java Naming Directory Interface) yes yes
JEE Connector Architecture services yes yes
Performance Monitoring Interface service
yes yes
Security service (JAAS and Java 2 security)

WAS – Serviço de nomes
 Cada Servidor de aplicação hospeda um serviço de nomes que provê
um diretório de nomes JNDI (Java Naming and Directory Interface). O
serviço é usado para registrar os recursos hospedados pelo Servidor
de aplicação.
 <WAS_HOME>/profiles/<PROFILE_NAME>/bin/dumpNameSpace.sh

WAS – Virtual hosts
 Um Virtual host é uma configuração que possibilita que um simples servidor de
hospedagem de aplicação se pareça com múltiplos servidores de hospedagem
de aplicação.
 Ele permite que uma única máquina física suporte muitas aplicações
administradas e configuradas independentemente.
 Trata-se de uma combinação de endereços IP e/ou nomes no DNS, umas ou
mais portas TCP/IP e protocolo HTTP/HTTPS. Exemplo: localhost:80, no browser
o endereço seria http://localhost:80.
 Um Virtual host pode ser associado a uma ou mais aplicações.
 O WAS instala 2 Virtual hosts padrões:
– default_host: *:80, *:9043, *:9080
– admin_host: *:9060, *:9043

WAS – Resource providers
 Um Resource provider define os recursos necessários para rodar uma
aplicação JEE.
Express Base ND Enterprise
JDBC provider Yes Yes Yes Yes
JavaMail Yes Yes Yes Yes
JMS providers Yes Yes Yes Yes
Resource environment providers Yes Yes Yes Yes
URL providers Yes Yes Yes Yes
Resource adapters Yes Yes Yes Yes

WAS – JDBC provider
 JDBC: Sigla para Java DataBase Connectivity.
 Padrão do J2SE que define os protocolos necessários para que uma aplicação
Java consulte e atualize uma fonte de dados externa, por exemplo um banco de
dados relacional ou um arquivo XML.
 JDBC Provider: É essencialmente um objeto que representa as classes de um
Driver JDBC para o Servidor de aplicação. Esse driver é específico para um certo
fabricante de banco de dados e cada fabricante de banco de dados deve
fornecer o seu Driver JDBC para que aplicações Java possa interagir com seus
produtos.
 Os JDBC providers são pré-requisitos para os Data sources os quais suprem
uma aplicação com conexões físicas a uma banco de dados.

Database type JDBC Provider
DB2 on Windows, UNIX, or workstation-based LINUX
DB2 Universal JDBC Provider
DB2 Universal JDBC Provider (XA)
DB2 legacy CLI-based Type 2 JDBC Provider
DB2 legacy CLI-based Type 2 JDBC Provider (XA)
DB2 on z/OS
DB2 for z/OS Local JDBC Provider (RRS), using the Legacy DB2 for z/OS JDBC
Driver
DB2 Universal JDBC Provider
DB2 Universal JDBC Provider (XA)
DB2 legacy CLI-based Type 2 JDBC Provider
DB2 legacy CLI-based Type 2 JDBC Provider (XA)
Sybase
Sybase jConnect for JDBC Provider
Sybase jConnect for JDBC Provider (XA)
Oracle
Oracle JDBC Provider
Oracle JDBC Provider(XA)
MS SQL Server
DataDirect ConnectJDBC Provider, type 4 driver, for MS SQL Server
DataDirect ConnectJDBC Provider, type 4 driver, for MS SQL Server (XA)
WebSphere embedded ConnectJDBC Provider for MS SQL Server
WebSphere embedded ConnectJDBC Provider for MS SQL Server (XA)

 JDBC API
– API aberta e independente para conectividade entre a linguagem Java e um amplo
conjunto de banco de dados.
– Provê conexão com um banco de dados ou qualquer fonte de dados formatado.
– Envia comandos SQL para o banco de dados.
– Processa os resultados.
 Arquitetura JDBC

 JDBC Driver
– É elemento que traduz as chamadas do API JDBC para chamadas nativas do DBMS
(DataBase Management System).
 Tipos de JDBC Drivers
– 4 tipos possíveis dependendo de como é formado o driver JDBC.
Tipo 1
Tipo 4
Tipo 2
Tipo 3

WAS – Data source
 Um data source representa uma fonte de dados no mundo real como por
exemplo um banco de dados relacional.
 Uma aplicação pode usar um data source para criar uma conexão com os dados
que o mesmo representa.
 As informações sobre como localizar os dados representados pelo data source
tais como nome do servidor e porta são armazenadas em forma de propriedades
no objeto chamado DataSource. Isso torna a aplicação bastante portável,
qualquer mudança na localização dos dados ou na maneira como os dados são
acessados não implica em mudanças no código da aplicação.
 As conexões com os dados são mantidas em pools. Por isso quando uma
aplicação fecha uma conexão com os dados essa conexão volta para o pool ao
invés de ser destruída.

WAS – Data source
Aplicação
Banco de dados
Pool de conexões
Conexões inativas
Conexão em uso

WAS 8.0 - Profiles
 Application server profile – Profile utilizado na criação de um standalone server (Base and
Express). Também utilizado como Aplication Server standalone que irá ser federado em um
Deployment Server.
 Deployment Manager profile – Em um ambiente que utilizará a versão Network Deployment do
WAS, você precisará de um Dmgr (Deployment Manager) rodando para que ele possa gerenciar toda
a configuração da sua célula.
 Custom profile – É um profile “vazio”, você poderá utilizar esse tipo de profile em máquinas que
serão federadas a uma célula. É um profile “enxuto”, com isso, o processo de criação deste profile é
bem mais rápido.
 Administrative Agent – Controla múltiplos ambientes, por exemplo, várias células e nós isolados
com o administrative agent instalado.
 Secure Proxy – Baseado NetWork Dispatcher(Edge) o proxy seguro implementa serviços de cache
dinâmico e roteamento entre os webservers e Application Servers em uma Zona segura.
 Cell Profile – Cria um Deployment manager, um nodeagent e um application server federado na
célula.
 Job Manager - Ele foi criado para enviar jobs para multiplos stand-alone application servers,
administrative agents, e deployment managers.Ex. Criação de um application server, start e stop
servers ou instalar ou fazer update em uma aplicação.
Profile Creator Tool <WAS_HOME>/bin/ProfileManagement:
Windows: pmt.bat – Linux/AIX: pmt.sh

WAS – Estrutura de Diretórios

WAS - Administração
 A partir da versão 5, o WAS ofereceu um novo modelo de administração baseado
no framework JMX (Java Management Extensions). Ele permite que programas
externos possam administrar o WAS de forma distribuída. A versão 8.0
implementa a especificação JMX 1.4
 Cada Servidor de aplicação possui um serviço de administração que provê as
funções necessárias para manipular as configurações do Servidor e de seus
componentes. As configurações são mantidas em um repositório formado por
um conjunto de arquivos XML no disco do servidor.
 O WAS oferece 3 tipos de ferramentas para sua administração:
– Console administrativo
– Comandos
– wsadmin

WAS – Console administrativa
 É uma aplicação JEE (adminconsole.ear) que roda no Servidor de
aplicação do WAS e possibilita a configuração e operação da
instância do WAS.
http://<hostname>:9060/admin

WAS – Comandos administrativos
 O WAS oferece um conjunto de scritps e comandos no diretório
<WAS_ROOT>/profiles/<PROFILE_NAME>/bin que você pode usar para
realizar algumas tarefas administrativas.
 Exemplos:
– startServer.sh: Inicia um Servidor de aplicação.
– stopServer.sh: Para um Servidor de aplicação.
– startNode.sh: Inicia o Node Agent.
– stopNode.sh: Para o Node Agent.
– backupConfig.sh: Faz o backup da configuração do WAS.
– restoreConfig.sh: Restaura o backup da configuração do WAS.
– serverStatus.sh: Lista os application servers disponíveis e o status de
cada um.
– startManager.sh: Inicia o Deployment Manager (DMGR).
– stopManager.sh: Para o Deployment Manager (DMGR).

WAS – wsadmin
 É um programa cliente que permite a administração do WAS através de linha de
comando.
 É possível escrever scripts para realização de tarefas complicadas e rodá-los
dentro do wsadmin.
 Como o wsadmin usa o BSF (Bean Scriptting Framework) várias linguagens pode
ser usadas para configurar ou controlar o WAS
 Exemplo:
– wsadmin> set jvm [$AdminControl completeObjectName
type=JVM,process=server1,*]
– wsadmin>$AdminControl invoke $jvm dumpThreads
– wsadmin> quit

WAS – wsadmin
 O wsadmin possui 5 objetos que são utilizados para gerenciamento do
ambiente WAS:
- $AdminControl
- $AdminConfig
- $AdminApp
- $AdminTask
- $Help

WAS – Administração centralizada
 As configuração ND permite que vários Servidores e Nós sejam
administrados de um local central.
 Para que isso sejá viável existe um processo chamado Deployment
Manager que cuida do processo de administração de uma Célula e
distribui a configuração atualizada entre os Node Agents, há um Node
Agent para cada Nó. O Node Agent por sua vez é responsável por
manter a configuração dos Servidores em cada Nó.

WAS – Administração centralizada

WAS – Processos gerenciados
 Todo processo de sistema operacional que é componente do WAS é
chamado de processo gerenciado ou Servidor gerenciado. O WAS
provê os seguintes processos/servidores gerenciados:
– Deployment Manager: Provê um único ponto de acesso para todas as
configurações e controla uma Célula. O Deployment Manager agrega e se
comunica com todos os processos Node Agent em cada Nó da Célula.
– Node Agent: Agrega e controla todos os processos gerenciados do WAS
dentro de um Nó. Há um Node Agent para cada Nó.
– Administrative agent profile: É uma console que pode conter vários
servidores conectados através de um ou mais deploy manager e/ou um
servidor isolado que tem instalado o administrative agent.
– Job Manager: É um processo que inicializa e controla atividades
relacionadas a administração do ambiente WAS como instalar uma
aplicação em vários servidores ou atualizar o plug-in XML.
– Servidor de aplicação: servidor gerenciado que hospeda aplicações
JEE.
– Servidor JMS: servidor gerenciado que hospeda o serviço de mensageria
embarcado para um Nó. Há somente um Servidor JMS por Nó.

WAS – Fluxo de uma aplicação
1. Um cliente Web requisita uma URL no browser.
2. A requisição é roteada pela Internet até o Servidor
Web.
3. O Servidor Web passa a requisição para o plugin.
Todas as requisições vão para o WAS plugin primeiro.
4. O plugin examina a URL, verifica a lista de hostnames
que ele poderá aceitar tráfego baseado nas
informações do Virtual Hosts, e escolhe um Servidor
de aplicação apropriado.
5. Um stream é criado. Um stream é uma conexão com o
Web container. É possível usar um stream para várias
requisições. O Web Container recebe a requisição e
baseado na URL redireciona a requisição para o
Servlet correto.
6. Se o Servlet não tiver sido carregado ainda, o class
loader dinâmico carrega o Servlet.
7. O JNDI é usado para procurar tanto os datasources
ou EJBs requiridos pelo Servlet.

WAS – Fluxo de uma aplicação
8. Dependendo se é requisitado um datasource ou um
EJB, o JNDI vai redirecionar o Servlet para:
a. o banco de dados correpondente e pegar uma
conexão do pool no caso de um datasource.
b. o EJB Container que por sua vez instância o EJB
quando o mesmo é requisitado.
9. Se o EJB requisitado possui uma transação SQL, ele
vai voltar para o JNDI para procurar um datasource
apropriado.
10. O comando SQL será executado e os dados
recuperados serão enviados de volta para:
a. o Servlet.
b. O EJB.
11. Data beans são criados e entregues aos JSPs no caso
de EJBs.
12. O Servlet envia os dados para o JSPs.
13. O JSP gera o código HTML que é enviado de volta
para o servidor Web através do plugin.
14. O servidor Web envia o HTML para o browser.

Administração

Administração
 As principais características do modelo de administração do WAS são:
– A configuração é armazenada em arquivos XML por isso não é necessário
qualquer tipo de software extra para o repositório administrativo.
– Programas de administração clientes são usados para modificar as
configurações:
• Baseado na Web – Console Administrativo (adminconsole.ear)
• Baseado em scripts – wsadmin
– Cada processo gerenciado, Node Agent, Job Manager, Admin Agent e
Deployment Manager inicia com os seus próprios arquivos de configuração.
– Os processos gerenciados são organizados em grupos. Todos os processos
gerenciados rodando em um mesmo Nó devem se registrar junto ao Node
Agent local. Todos os Node Agents configurados em uma Célula administrativa
devem se registrar junto ao Deployment Manager.

Administração – Pontos de acesso
 A administração da configuração ou dados da aplicação pode ser
realizada em diversos pontos da topologia da Célula:
– Deployment Manager: Gerencia tudo dentro da Célula.
– Node Agent: Gerencia tudo dentro de um determinado Nó.
– Servidor gerenciado: Gerencia somente o Servidor em questão.
– Job Manager: Pode gerenciar mais de uma célula.
– Administrative agent: Gerencia um determinado nó.
 Atenção:
– O wsadmin pode se conectar a qualquer Deployment Manager, Node
Agent, Admin Client, Job Manager ou Servidor gerenciado.
– O Console Administrativo pode somente se conectar ao Servidor que tem a
aplicação adminconsole.ear instalada. Na configuração ND o
adminconsole.ear é instalado no Deployment Manager.
– Qualquer mudança na configuração feita no nível de Servidor ou Nó será
local e não refletirá no repositório da célula. Mudanças locais são sobre-escritas
na próxima sincronização do Nó com a Célula.
– Somente mudanças feitas no nível de Célula (no Deployment Manager) são
permanente e replicadas para todos os Nós e Servidores membros.

Administração – Papeis
 O controle de acesso ao Console Administrativo é bastante
granulado e possui 8 papéis definidos:
• Monitor: Pode ver o estado do sistema e a configuração mas não pode
fazer qualquer mundaça.
• Operator: Tem os mesmoss acessos do Monitor e pode fazer mudanças
operacionais como parar/iniciar um Servidor.
• Configurator: Tem os mesmos acessos do Monitor e pode fazer mudanças
nas configurações.
• Deployer: Os usuários podem fazer configurações e operações run time
nas aplicações (stop/start). Disponível apenas no wsadmin.
• AdminSecurityManager: Pode mapear os usuários as regras
administrativas. Disponível apenas no wsadmin
• Iscadmins: Pode mapear os usuários as regras administrativas na console.
• Administrator: Tem todos os acessos do Operator e do Configurator.
• Auditor: Tem permissão de visualizar e modificar os parâmetros do
subsystem da segurança de auditoria.

Administração – Console Administrativo
 Iniciando o Console Administrativo
– Verifique se o Deployment Manager (DMGR) está rodando:
• Windows: <WAS_ND_HOME>profiles<PROFILE_NAME>binserverStatus –all
• Unix: <WAS_ND_HOME>/profiles/<PROFILE_NAME>/bin/serverStatus.sh –all
– Se o status do DMGR não for STARTED inicie-o com o seguinte comando:
• Windows: <WAS_ND_HOME>profiles<PROFILE_NAME>startManager
• Unix: <WAS_ND_HOME>/profiles/<PROFILE_NAME>/startManager.sh
– Abra um browser e aponte-o para o URL do Console Administrativo:
• http://<DM_hostname>:9060/admin
• https://<DM_hostname>:9043/admin

 Taskbar
 Welcome: Mostra a página principal do Console Administrativo. Nessa página há links outras
informações.
 Logout: Desloga do Console Administrativo e volta para a página de login.
 Support: Direciona você a uma página com links onde buscar suporte para o WAS.
 Help: Abre uma nova janela de browser com informações de ajuda detalhadas para o Console
Administrativo.

 Menu de Navegação
 Guided Activities: Tem acesso rápido a tarefas comuns
administrativas como a criação de um cluster e a conexão ao DB.
 Servers: Permite a configuração de Servidores administrativos,
Servidores de aplicação e clusters.
 Applications: Permite a instalação e gerenciamento das aplicações.
 Jobs: Permite submeter e administrar os jobs no ambiente.
 Services: Gerencia os service provider e clients, JAX-WS, Police
Sets e Trus service.
 Resources: Permite a configuração dos recursos e a visualização
dos recursos existentes na Célula.
 Security: Permite a configuração e gerenciamento da segurança no
WAS e do SSL.
 Environment: Permite a configuração de Virtual Hosts, Servidores
Web, variáveis e outros componentes.
 System Administration: Permite a configuração de Nós, Células e
segurança do Console.
 Users and Groups: Gerencia os usuários e as suas regras.
 Troubleshooting: Permite você checar problemas de configuração e
erros.
 Service integration: Permite a configuração de WebServices e
Enterprise Service BUS
 UDDI: Permite que você trabalhe com as funções UDDI registry

 Workspace
 É o local onde são realizadas as configurações e operações administrativas.
 O conteúdo do workspace dependerá do item escolhido no Menu de Navegação.

 Salvando as alterações feitas no workspace:

IHS – IBM HTTP Server
 Um servidor Web é a base para qualquer
aplicação de e-business;
 O IHS é baseado no servidor Web Apache,
que é o mais popular e seguro WebServer
do mercado;
 O WebServer trabalha em parceria com o
WebServer plugin para fazer com o que as
requisições de conteudo dinâmico
(Servlets, JSPs) sejam direcionadas para
serem atendidas pelo correto/disponível
Application Server.

 Principal arquivo de configuração:
<IHS_HOME>/conf/httpd.conf
 Principais comandos:
<IHS_HOME>/bin/apachectl start – Inicia o Servidor Web
<IHS_HOME>/bin/apachectl stop – Para o Servidor Web
<IHS_HOME>/bin/apachectl restart – Reinicia o Servidor Web
<IHS_HOME>/bin/apachectl -v – Mostra a versão do Servidor Web
 Por padrão o Servidor Web, vem configurado para trabalhar na porta 80, caso o SSL seja habilitado, ele estará rodando por
padrão na porta 443;
 Arquivos de log:
<IHS_HOME>/logs/access_log
<IHS_HOME>/logs/error_log

 A partir da versão 6.0 do WAS, existe a possibilidade da administração de um Servidor Web, ser feita a partir da
console administrativa, para isso possa ocorrer, o WebServer deverá residir em um nó gerenciado (Managed
Node) ou caso ele esteja em um nó não gerenciado (Unmanaged Node), o Servidor Web deverá ser o IHS 6.0.

Diagnóstico de problemas

 Ferramentas disponíveis
– Console Administrativo: As mensagens que aparecem no Console
Administrativo são muito importantes para identificar as causas de problemas
de configuração.
– Arquivos de logs: Muitos tipos de logs podem ser verificados como os logs
padrões do JVM e do processo no SO.
– Traces: Os traces possuem informações mais detalhadas sobre os
componentes do WAS e são usados para determinar o que está errado.
– Log analyzer: Trata-se de uma ferramenta gráfica que permite o usuário
visualizar qualquer mensagem de log no formato IBM. Ele analisa cada
mensagem de erro e mostra as explicações sobre as causas da mesma e as
possíveis ações que podem ser tomadas para corrigir o erro.
– Outras ferramentas IBM: Thread Analyzer, Collector Tool, FFDC (First Failure
Data Capture).

 Os arquivos de log
– Logs do JVM:
<WAS_HOME>/profiles/<PROFILE_NAME>/logs/<nome_do_Servidor>/Syste
mOut.log e
<WAS_HOME>/profiles/<PROFILE_NAME>/logs/<nome_do_Servidor>/Syste
mErr.log. São os streams System.out e System.err do JVM.
– Logs do processo nativo:
<WAS_HOME>/profiles/<PROFILE_NAME>/logs/<nome_do_Servidor>/native
_stdout.log e
<WAS_HOME>/profiles/<PROFILE_NAME>/logs/<nome_do_Servidor>/native
_stderr.log. São os streams stdout e stderr dos módulos do processo nativo
tais como .dlls, .so, blibliotecas UNIX e módulos nativos JNI.
– Logs do serviço IBM:
<WAS_HOME>/profiles/<PROFILE_NAME>/logs/activity.log. São os logs das
atividades do WAS e somente podem ser visualizados com o Log Analyzer.

Diagnóstico de problemas – Logs da JVM
 Usando o Console
Administrativo
1. Clique em Troubleshooting ->
Logs and Traces no painel de
navegação.
2. Selecione um servidor clicando
no nome do Servidor.
3. Clique em JVM Logs.
4. Selecione a aba Configuration.
5. Use a barra de rolagem para
visualizar todas as
propriedades.

 File Name
– Especifica o nome do arquivo para os
streams System.out e System.err. Pode ter
3 valores: Nome do arquivo, console ou
none.
 File formatting
– Especifica o formato das mensagens, pode
ser Basic ou Advanced.
– Basic:
<timestamp><threadID><shortName><eve
ntType>[class][method]<message>
– Advanced:
<timestamp><threadID><eventType><UO
W><source=longName>[class]
[method]<Organization><Product><Compo
nent><message>
 Log file rotation
– Configura a rotação do log através de
vários arquivos para que não exista
arquivos de log muito grandes.

 Maximum number of Historical Log
Files
– Especifica o número de arquivos de
log históricos e que serão usados
para o rodízio do log.
 Installed Application Output
– Show Application print
Statements: Permite que a
aplicação instalada no Servidor
possa logar suas mensagens no
mesmo arquivo de log do WAS.
– Format print statements: Faz com
que as mensagens da aplicação
tenham o mesmo formato do que as
mensagens do WAS.

 Formato das mensagens
– [2/13/06 14:56:43:198 MST] 1f0829b8 SRTServletReq E
SRVE0120E: IO Error java.net.SocketTimeoutException:
Read timed out
Campo Exemplo
Timestamp [2/13/06 14:56:43:198 MST]
ID da Thread 1f0829b8
Componente SRTServletReq
Tipo de evento E (A = Audit, I = Informational, W = Warning, E = Error, F = Fatal, O =
System.out, R = System.err, Z = Unknown)
ID da mensagem SRVE0120E
Mensagem IO Error java.net.SocketTimeoutException: Read timed out

 O ID da Mensagem tem o seguinte formato:
 CCCC1234X
 No nosso exemplo: SRVE0120E
– CCCC é o identificador do componente ou aplicação
– 1234 é o identificador da mensagem para este componente
– X é o indicador de severidade opcional (I = Informational, W = Warning, E
= Error)

Diagnóstico de problemas – Trace
 Por default o trace é desabilitado para todos os componentes do WAS
 Habilitar o trace acarreta um grande impacto na performance do WAS
dependendo da granularidade das informações e da utilização das
aplicações instalados no ambiente
 É recomendado o uso do Trace quando o problema não puder ser
diagnosticado pela verificação dos logs e da configuração. Também é
recomendado que o Trace seja habilitado em ambientes de
desenvolvimento/teste e evitado em ambientes de produção
 O Trace permite que todas as operações em um determinado componente
do WAS sejam evidenciadas em um arquivo texto para análise.

 Usando o Console Administrativo
1. Selecione Troubleshooting -> Logs and
Trace.
2. Selecione o Servidor clicando em seu
nome. Você pode selecionar um
Servidor de aplicação, Node Agent,
Servidor JMS ou o DMGR.
3. Selecione Diagnostic Trace.
4. Selecione a aba Configuration se você
quiser habilitar o Trace de forma perene
ou Runtime se for habilitar
temporariamente.

 Enable Trace
– Habilita o Trace
 Trace specification
– Seleciona os componentes e o nível de Trace
em cada componente através do uso de Trace
Strings.
 Trace Output
– Seleciona onde redirecionar as informações
de Trace, para memória ou para um arquivo.
– Memory buffer: Se selecionado você deve
dizer a quantidade de entradas você deseja
que o buffer armazene. Para visualizar as
informações de Trace você terá que clicar no
botão Dump da aba Runtime para transferir
tudo que estiver no buffer para um arquivo.
– File: Se você selecionar arquivo você deve
espeficicar os outros parâmetros.

 Trace Output Format
– O formato das informações de Trace, pode
ser Basic ou Advanced.
– Basic: Para um mínimo de informações por
entrada.
– Advanced: Para informações mais
detalhadas. Você precisa escolher esta
opção se quiser usar o Log Analyser.

 Trace strings
– São frases que possuem a seguinte regra gramatical:
– COMPONENT_TRACE_STRING =
COMPONENT_NAME=LEVEL=STATE[,LEVEL=STAT
E]*
– COMPONENT_NAME: Nome do componente que se
deseja investigar
– LEVEL: all, entryExit, debug ou event.
– STATE: enabled ou disabled.
 Exemplos
– com.ibm.ejs.ras.ManagerAdmin=debug=enabled
– com.ibm.ejs.ras.ManagerAdmin=all=enabled,event=dis
abled
– com.ibm.ejs.ras.*=all=enabled
– com.ibm.ejs.ras.*=all=enabled:com.ibm.ws.ras=debug=
enabled,entryexit=enabled

 Formato das entradas
– [11/18/05 23:04:32:748 MST] 2430f3cd MCWrapper d Resetting stale, tranFailed, and _transactionErrorOccurred
flags
– [11/18/05 23:04:32:748 MST] 2430f3cd MCWrapper < destroy
– [11/18/05 23:04:32:748 MST] 2430f3cd FreePool < cleanupAndDestroyMCWrapper
– [11/18/05 23:04:32:748 MST] 2430f3cd FreePool < cleanupAndDestroyAllFreeConnections
 Basic
– <timestamp><threadId><shortName><eventType>[className][methodName]<textmessage> [parameter 1] [parameter
2]
 Advanced
– <timestamp><threadId><eventType><UOW><source=longName>[className]
[methodName]<Organization><Product><Component><textMessage>[parameter 1=parameterValue][parameter
2=parameterValue]
 Campo eventType
– > method entry < method exit e event d debug m dump u unconditional Z type was not recognized

Diagnóstico de problemas – Plugin
 O plugin do WAS cria um arquivo de logs com mensagens de erros e informativas.
Você pode alterar a configuração do plugin para gerar informações detalhadas
editando o seu arquivo de configuração.
 O arquivo de configuração do plugin normalmente fica no seguinte diretório:
– <WAS_HOME>/profiles/<PROFILE_NAME>/config/cells/plugin-cfg.xml
 Altere o campo LogLevel de Error para Trace
– <?xml version="1.0" encoding="ISO-8859-1"?>
– <Config >
– <Log LogLevel="Error"
Name="/usr/WebSphere/DeploymentManager/logs/http_plugin.log"/>
– ....
– </Config>
 Lembrem-se, o trace do plugin pode encher um disco facilmente e por isso nunca
deveria ser ligado em produção.
 O plugin-cfg.xml pode ser regerado através do Console Administrativo, quando isso
acontece qualquer alteração manual é desfeita.

Diagnóstico de problemas – IHS
 O IHS gera dois arquivos de logs: um de erros e outro de acessos.
 A configuração dos arquivos de logs do IHS é feita no seguinte
arquivo:
– <IHS_HOME>/conf/httpd.conf
 As diretivas para as mensagens de erros são o ErrorLog e
LogLevel
– # ErrorLog: The location of the error log file. If this does not start
– # with /, ServerRoot is prepended to it.
– ErrorLog /usr/IBMHttpServer/logs/error_log
– # LogLevel: Control the number of messages logged to the
error_log.
– # Possible values include: debug, info, notice, warn, error, crit,
– # alert, emerg.
– LogLevel warn
 Exemplo de mensagens do log de acesso
– 10.82.80.38 - - [25/Apr/2005:10:58:31 -0600] "GET /snoop
HTTP/1.1" 200 13923
LogLevel Significado
emerg Emergências,
sistema
inutilizado
alert Ação precisa ser
tomada
imediatamente
crit Condições
críticas
error Condições de
erro
warn Condições de
alerta
notice Condições
normais mas
importantes
info Informacional
debug Para
debug/trace

Diagnósticos de problemas – Recursos
 WAS - Página de Suporte
– http://www-
947.ibm.com/support/entry/portal/Overview/Software/WebSphere/WebSph
ere_Application_Server/
 IBM developerWorks™
– http://www.ibm.com/developerworks/
 WebSphere User Group
– http://www.websphereusergroup.org/
 Google groups: WAS
– http://groups.google.com/group/ibm.software.websphere.application-server?
lnk=gschg
 Uma introdução ao Java Stack Traces
– http://java.sun.com/developer/technicalArticles/Programming/Stacktrace/
 Arquivos de log do Apache HTTP Server:
– http://httpd.apache.org/docs/2.2/en/logs.html

Class loaders
 No start de uma JVM, temos 3 class loaders:
 Bootstrap class loader (<JAVA_HOME>/lib);
 Extensions class loader (<JAVA_HOME>/lib/ext e propriedade java.ext.dirs);
 System class loader (java.class.path ultimamente lido através da variável de ambiente CLASSPATH);

WebSphere extensions class loader

 Formado pelos jars presentes nos seguintes paths:
– <JAVA_HOME>lib
– <WAS_HOME>classes (Runtime Class Patches directory, or RCP)
– <WAS_HOME>lib (Runtime class path directory, or RP)
– <WAS_HOME>libext (Runtime Extensions directory, or RE)
– <WAS_HOME>installedChannels
 Esse class loader é baseado na system property: ws.ext.dirs, que é inicialmente derivada da
váriavel de ambiente WS_EXT_DIRS (setupCmdLine);
 Para adicionar um novo diretório, basta criar uma nova custom property com o nome de ws.ext.dirs
nas propriedades do seu appserver;

 EJB modules, utility JARs, resource adapters files, and shared libraries = Application class loader;
 Módulos Web possuem o seu próprio classloader, os seguintes diretórios são utilizados para formar o
classloader: WEB-INF/classes e WEB-INF/lib;
 WAR class loader policy: Module (default) ou Application;
 Application server class loader policy: Single ou Multiple (default);
 Delegation mode: Parent_first (default) ou Parent_last

 Preloading files: A primeira vez que o WAS inicia ele insere nos arquivos de preload
informações relacionadas às classes utilizadas e arquivos que contém essas classes.
Nos startups subsequentes, o WAS utilizará os arquivos de preload para acelerar o
startup;
 <WAS_HOME>logspreload
 Caso seja necessário desabilitar: -Dibm.websphere.preload.classes=false

Perguntas ?
??

Obrigado !
 Bibliografia
 WebSphere Application Server V8 Administration and Configuration Guide
– sg247971.pdf
 WAS V8.0 Information Center
– http://publib.boulder.ibm.com/infocenter/wasinfo/v8r0/index.jsp
 Wsadmin sample scripts
– http://www.ibm.com/developerworks/websphere/library/samples/SampleScripts.html
 The Java Tutorial
– http://java.sun.com/docs/books/tutorial/index.html
 IBM WebSphere Application Server Migration Toolkit
– http://www.ibm.com/developerworks/websphere/downloads/migtoolkit/index.html

WebSphere 8 Intro (pt-BR)

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a WebSphere 8 Intro (pt-BR)

Semelhante a WebSphere 8 Intro (pt-BR) (20)

Mais de Juarez Junior

Mais de Juarez Junior (20)

WebSphere 8 Intro (pt-BR)