Michael Morrison
Em todas as partes deste livro aprendeu muito sobre Java programando o ambiente e como pode usar-se para criar programas Baseados na web interativos. O seu conhecimento de Java até aqui foi inteiramente baseado no que se conhece como Java principal API ou Base de Java API. Até há pouco, este API principal compreendeu o conjunto de Java programando a paisagem. Contudo, JavaSoft recentemente anunciou um largo plano de integrar várias novas tecnologias de software em Java API. Estas novas tecnologias vêm na forma da extensão APIs que integram a Java principal API, e mencionam-se como a extensão padrão APIs. Em algum momento, muitos destes APIs fundirão e vão se tornar a parte do API principal, mas por agora se estão todos apresentando como extensões.
A lição de hoje dá uma olhada nestes novos APIs e discute junto com que têm de oferecer, exatamente como se integrarão com o API principal existente. Os tópicos principais que cobre hoje são
A maioria destas extensões API são muito novas e até não conseguiram a etapa de especificação. Por essa razão, a lição de hoje só a destinam para dar-lhe uma ideia de onde Java se encabeça com a extensão padrão APIs. Em outras palavras, pode querer verificar o Web site de JavaSoft (www.javasoft.com) para adquirir a última pá na posição destes APIs desde que estão em um estado constante do fluxo.
O lançamento 1.02 de Java, que é o último lançamento de Java desde esta escrita, entrega-se agora a por JavaSoft como Java principal API. Java principal API define o jogo mínimo da funcionalidade uma implementação de Java deve apoiar para considerar-se Java complacente. Por exemplo, quando alguém empreende o emprego de apoiar Java em uma determinada plataforma, deve implementar totalmente Java principal API. Este suporte garantido do API principal é o que permite a desenvolvedores de Java o luxo de ser capaz de escrever programas Java uma vez e faça-os correr em qualquer plataforma complacente por Java.
No perto do futuro, JavaSoft planeja estender-se sobre o API principal introduzindo novo APIs endereçamento de necessidades de desenvolvimento mais aplicadas. Os novos APIs cobrem uma ampla variação de áreas e salvarão enfim desenvolvedores muito tempo estabelecendo uma aproximação consistente de certas questões de desenvolvimento, por meio disso reduzindo a necessidade da codificação alfandegária. Alguns destes novos APIs fundirão com o API principal; os outros permanecerão extensões. Apesar da sua relação última ao API principal, a nova extensão APIs mencionam-se como a extensão padrão APIs desde que estendem o API principal atual como o sabemos.
A extensão padrão API rompe-se no grupo de APIs individual apontamento de necessidades de desenvolvimento diferentes. O seguinte é os componentes principais da extensão padrão APIs:
O resto da lição de hoje concentra-se em cada um destes APIs e como afetam a plataforma de software Java.
A computação de empresa ficou cada vez mais importante nos últimos anos como cada vez mais as companhias realizam a importância de integrar as suas operações eletronicamente. As possibilidades únicas permitidas pelo uso aumentado da Internet serviram para ampliar a popularidade da computação de empresa. JavaSoft tomou nota da falta de Java do suporte de sistemas de empresa e anunciou planos de uma Empresa API.
A Empresa de Java API projeta-se para dar a programas Java um mecanismo formal para unir-se a sistemas de informação de empresa. Isto é uma característica muito necessária em Java desde que tantos sistemas de computador corporativos confiam pesadamente em fontes de informação de empresa. Na resposta desta necessidade, a Empresa API ataca o problema em três frentes. Estas frentes vêm na forma de três subconjuntos API:
JavaSoft reconheceu a importância destes três subconjuntos API e planeja-os ao diretamente incorporado em Java principal API em algum momento no futuro.
O primeiro destes subconjunto APIs, JDBC, define uma interface estruturada para SQL (Língua de Pergunta Estruturada) bancos de dados, que é a aproximação de padrão de indústria do acesso de bancos de dados relacional. Apoiando SQL, JDBC permite a desenvolvedores interagir e apoiar uma ampla variação de bancos de dados. Isto significa que a especificação da plataforma de banco de dados subjacente é bastante bem inaplicável quando vem a JDBC, que é muito boas notícias para desenvolvedores de Java.
| Novo termo |
Os bancos de dados de SQL são bancos de dados baseou-se no padrão SQL, que é um padrão largamente aceito que define um protocolo estrito para acessar e manipular dados. |
O JDBC API provê desenvolvedores de Java de uma aproximação consistente do acesso de bancos de dados de SQL que é comparável com técnicas de desenvolvimento de banco de dados existentes, interagir então com um banco de dados SQL usando JDBC não é tudo tão muito diferente do que a interação com um banco de dados SQL usando instrumentos de banco de dados tradicionais. Isto deve dar a programadores de Java que já têm alguma confiança de experiência de banco de dados que podem bater na terra que corre com JDBC. O JDBC API já se endossou largamente por líderes de indústria, inclusive alguns vendedores de instrumento de desenvolvimento que anunciaram o futuro suporte de JDBC nos seus produtos de desenvolvimento.
O JDBC API inclui classes de construtos de banco de dados SQL comuns como conexões com o banco de dados, afirmações de SQL e jogos de resultado. Os programas JDBC Java serão capazes de usar o SQL familiar programação de modelo de emitir afirmações SQL e processar os dados resultantes. O JDBC API é basicamente dependente de um gerente de motorista que apoia múltiplos motoristas que se unem a bancos de dados diferentes. Os drivers de banco de dados de JDBC podem escrever-se inteiramente em Java ou implementaram métodos nativos usam para lançar uma ponte sobre aplicações de Java a bibliotecas de acesso a base de dados existentes.
| Novo termo |
Um jogo de resultado é uns dados de grupo recuperados de um banco de dados depois de um pedido de usuário. |
O subconjunto IDL da Empresa API destina-se para o fornecimento de um modo de unir programas de cliente de Java para transmitir em rede servidores que correm em outras plataformas. IDL é um protocolo de padrão de indústria de comunicações de cliente/servidor através de plataformas diferentes. O uso primário do IDL API deve unir transparentemente programas de cliente de Java a sistemas de legado.
| Novo termo |
Um sistema de legado é um sistema antiquado que ainda tem de reimplementar-se usando tecnologias atuais. |
Java IDL API inclui os seguintes componentes:
O componente RMI da Empresa API define uma interface para invocar métodos de objeto em um ambiente distribuído. O RMI API serve um objetivo crucial na Empresa API acrescentando o suporte cheio de comunicações de objeto remotas. O RMI API fá-lo franco para desenvolvedores de Java para acrescentar o suporte computacional remoto às suas classes.
Enquanto o papel da Internet continua desenvolvendo-se de ser logo uma fonte de informação a ser também um mercado no varejo, a necessidade de um protocolo transacional comercial seguro cresce a novas alturas. Tanto os vendedores de Internet como os compradores igualmente esperam ansiosamente a migração inevitável de compras à Web. JavaSoft forneceu uma resposta ao problema de compras seguro com o Comércio API, que é Java extensão de API que fornece o de cima para programas Java para apoiar a compra segura e a gestão financeira.
O Comércio de Java API aspira a prover desenvolvedores de uma solução elegante para o problema de transações comerciais na Web. A meta é fazer mercadorias de compras um sem costura, ainda segurar, parte da experiência de Web. A este fim, o Comércio API está empurrando-se por JavaSoft como um ambiente aberto, extensível da gestão financeira na Web. O plano de longo prazo do Comércio API é para a integração na plataforma de software Java parcialmente com o API principal e parcialmente como uma extensão padrão. Ainda não é claro que componentes o farão no API principal e que permanecerá separado.
O Comércio API compõe-se dos seguintes componentes primários:
A infraestrutura do Comércio API é basicamente a armação arquitetônica que define as interações entre outros componentes do API. Esta infraestrutura também é o que dá ao API a sua extensibilidade para apoiar futuras extensões de comércio.
O componente de banco de dados serve de um repositório da informação de usuário, como métodos de pagamento e o endereço de expedição do usuário. O componente de banco de dados contém características de encriptação para que a informação de usuário possa guardar-se completamente privada. Alternadamente, os fornecedores de serviços de comércio têm a opção de compartilhar a informação de usuário um com outro.
O API de Comércio utiliza cassetes, que são módulos de software que implementam protocolos financeiros específicos. Os dois tipos diferentes de cassetes apoiadas são cassetes de pagamento e cassetes de serviço. Uma cassete de pagamento define o protocolo para fazer pagamentos eletrônicos. Os exemplos de cassetes de pagamento são cartões de crédito, debitam cartões, e consequentemente dinheiro digital. Um usuário pode ter múltiplas cassetes de pagamento que representam instrumentos de pagamento diferentes, muito como transportamos instrumentos de pagamento diferentes nas nossas carteiras ou bolsas. De fato, uma das classes no Comércio API especificamente modela uma carteira eletrônica.
| Novo termo |
Uma cassete é um módulo de software que implementa um protocolo de pagamento específico. |
As cassetes de serviço são mais gerais, e modelam qualquer tipo de serviços financeiros sobre valor adicionado como análise financeira ou módulos de preparação fiscais. Por exemplo, pode comprar de maneira fatível uma cassete de serviço para ajudar a equilibrar o seu talão de cheques eletrônico ou avaliar o valor da sua pasta de estoque.
O componente último do Comércio API inclui interfaces administrativas, que são caixas de diálogo e outras interfaces gráficas usadas para recuperar a informação do usuário e configurar opções de comércio.
A gestão API projeta-se para responder as necessidades de sistemas de gestão de rede integrados. Inclui uma ampla variação de interfaces, classes e applets para facilitar o desenvolvimento de soluções de gestão integradas. A meta primária da gestão API é fornecer uma aproximação unificada do manejo das complexidades implicadas em desenvolvimento e manutenção de recursos e serviços em uma rede heterogênea. Usando a gestão API, os desenvolvedores de Java serão capazes de desenvolver rapidamente aplicações de gestão de rede que apoiam uma ampla variação de sistemas em redes grandes e muitas vezes complexas. JavaSoft planeja guardar a gestão API como uma extensão separada do API principal.
A gestão API inclui os seguintes componentes principais:
O Módulo de Visão de Admin é uma extensão do Resumo de Java Caixa de ferramentas de Windowing (awt) que se realça para fornecer o suporte específico de criar aplicações de gestão integradas. As classes implementadas no AVM servem de uma base para desenvolver interfaces de usuário gráficas modernas. Por exemplo, o AVM inclui o suporte de mesas gráficas, diagramas, gráficos e metros.
As interfaces de objeto baseadas definem os tipos de objeto principais que se usam para recursos distribuídos e serviços em um sistema de gestão. Usando as interfaces de objeto baseadas, os desenvolvedores podem definir abstrações de vários atributos associados com um ambiente de empresa dirigido.
As interfaces de container dirigidas definem um meio de objetos dirigidos agrupam da melhor organização. Esta organização facilita uma aproximação mais orientada pelo grupo de acompanhar recursos dirigidos, que podem ser um grande benefício em sistemas complexos.
As interfaces de notificação dirigidas definem uma fundação principal de serviços de notificação de evento dirigido. Os desenvolvedores são livres de desenvolver serviços de notificação específicos para a aplicação mais promovidos estendendo estes serviços.
As interfaces de dados dirigidas fornecem um meio de ligar atributos de objeto dirigidos a bancos de dados relacional via JDBC. Na realização assim, as interfaces de dados dirigidas estabelecem uma conexão transparente entre recursos de gestão e bancos de dados externos.
As interfaces de protocolo dirigidas usam a segurança de Java APIs e Java RMI para acrescentar o suporte de objeto distribuído seguro à funcionalidade principal fornecida pelas interfaces de objeto baseadas. À sua vez, as interfaces de SNMP estendem as interfaces de protocolo dirigidas para fornecer o suporte de agentes SNMP. Desde que SNMP é o protocolo de gestão mais popular no uso, o seu suporte via as interfaces de SNMP é uma parte importante da gestão API.
| Novo termo |
SNMP significa o Protocolo de gestão de Rede Simples, que é um protocolo relativamente simples originalmente desenvolvido para resolver problemas de comunicação entre tipos diferentes de redes e reunir a estatística de rede. |
Finalmente, a integração applet inter-relaciona o componente da gestão que API especifica como Java applets pode integrar-se à gestão API para fornecer soluções de gestão. Os desenvolvedores de Applet usam as interfaces de integração applet para incorporar o suporte de gestão no seu applets.
Depois do êxito de Java e o seu uso imediato para desenvolver o lado do cliente applets, JavaSoft decidiu tomar medidas para fazer Java uma alternativa mais viável de aplicações de lado do servidor. O Servidor API é a resposta de JavaSoft à necessidade do suporte orientado ao servidor mais completo em Java. O Servidor API fornece uma ampla variação da funcionalidade de servidor inclusive o suporte de administração, controle de aceitabilidade e manejo de recurso dinâmico. Também incluído no Servidor API é o Servlet API, que fornece uma armação para estender servidores com servlets. JavaSoft planeja guardar o Servidor API uma extensão separada do API principal.
| Novo termo |
Um servlet é um objeto de Java que estende a funcionalidade de um servidor de informação, como um servidor HTTP. Pode pensar em servlets como os equivalentes de servidor do lado do cliente Java applets. |
O Servlet API fornece o necessário de cima para criar servlets e inter-relacioná-los com servidores de informação. O Servlet API equipa-se para tratar a relação servlet/server inteira, com uma ênfase no cuidado de coisas estáveis e simples. Tudo que deve dirigir servlets é um servidor que apoia o Servlet API.
Possivelmente a área mais débil de Java principal API como o sabemos é o seu suporte de meios de comunicação. Atualmente, Java API apoia GIF só estático e imagens JPEG e sons de onda no formato de som de AU. Este suporte de meios de comunicação limitado não o cortará na corrida longa. Com certeza os desenvolvedores podem cortar as suas próprias implementações de meios de comunicação até certo ponto, mas podem fazer isto já em várias outras línguas e plataformas. Supôs-se que Java fizesse coisas mais fáceis, certo?
JavaSoft realizou esta fraqueza e cura coisas com os Meios de comunicação API, que se cobre com ardósia para incluir o suporte de uma tabela que confunde de tipos de mídia que não há dúvida porão Java no mapa como uma plataforma de multimédia séria. Os Meios de comunicação API incluem classes que tipos de mídia modelares como vídeo de movimento cheio, áudio, gráfica 2a e 3D e telefonia. Além disso, a estrutura do API é tal que muitos destes tipos de mídia confiarão nas mesmas facilidades subjacentes. Por exemplo, todos os meios de comunicação baseados no tempo como vídeo e áudio usarão o mesmo mecanismo de regulação de tempo subjacente, significando que a sincronização não será um problema.
O API de Meios de comunicação projeta-se para estar muito aberto e extensível, que é a consideração importante do fato que o mundo da multimédia se modifica alguma vez. JavaSoft planeja integrar os Meios de comunicação API na plataforma de Java tanto como adições de API principais como como extensão padrão APIs.
Os seguintes subconjuntos API compreendem os Meios de comunicação API:
A Armação de Meios de comunicação API trata a funcionalidade de regulação de tempo de baixo nível necessitada por muitos de outros meios de comunicação APIs. Este API inclui o suporte de regulação de tempo e sincronização, ambos os quais são críticos de tipos de mídia que devem funcionar em conjunto na harmonia. Também incluído na Armação de Meios de comunicação API é suporte de escorrimento, compressão e fontes de dados vivas.
| Novo termo |
A sincronização refere-se a como os elementos de meios de comunicação baseados no tempo diferentes concordam um com outro a tempo. Por exemplo, é importante para a pista sólida de um filme permanecer sincronizado com o quadro. |
| Novo termo |
O escorrimento é o processo da interação com dados enquanto ainda se está transferindo. Por exemplo, um tocador de áudio que corre começaria a jogar o áudio logo que certo montante mínimo de dados se tenha transferido. |
O 2o API de Gráficos estende a funcionalidade das classes awt para fornecer o mais largo suporte de 2os primitivos de gráficos e vários dispositivos de saída gráficos diferentes, como impressoras. Outra adição importante ao 2o API de Gráficos é a definição de um modelo gráfico uniforme que traz muitas funções de gráficos em uma estrutura. A Animação API usa o 2o API de Gráficos como uma base da sua implementação de 2os objetos de gráficos animados ou duendes. Também confia na Armação de Meios de comunicação API para manter a regulação de tempo e a sincronização.
O API de Gráficos 3D fornece o necessário de cima para gerar a gráfica 3D de alta performance. Este API implementa a gráfica 3D apoiando um modelo de objetos gráficos 3D que podem dar-se em altas velocidades. O API de Gráficos 3D também inclui o suporte de VRML, que é uma língua de modelagem 3D popular. Para conseguir toda esta funcionalidade, o API de Gráficos 3D confia pesadamente nas funções fornecidas por muitos de outros meios de comunicação APIs.
O API Vídeo traz o vídeo de movimento cheio a Java. O API fornece a armação para dirigir e processar o vídeo em um escorrimento ou em cenário guardado. Semelhante ao API Vídeo de alguns modos, o API Áudio também fornece o suporte tanto de escorrimento como de meios de comunicação guardados. Contudo, os meios de comunicação apoiados pelo API Áudio compõem-se do áudio escolhido ou de sintetizado. O API Áudio até contém classes para implementar o áudio espacial 3D.
O MIDI API traz eventos musicais determinados a Java por meio do padrão de MIDI popular. O MIDI é um modo eficiente de representar ambas as partes musicais bem como recursos de regulação de tempo mais gerais. Espere ouvir a Web muito diferentemente uma vez que este API se torna popular!
| Novo termo |
O MIDI suporta o Instrumento musical a Interface Digital. Define um protocolo para comunicar e guardar eventos baseados no tempo, como os gerados tocando um instrumento musical. |
O API de Ação é provavelmente o mais interessante dos meios de comunicação APIs, simplesmente porque é o menos óbvio. Define um meio pelo qual a comunicação viva, com muitos participantes pode realizar-se sobre uma rede. A Ação API fornece o suporte tanto de sincronização como de gestão de sessão. Não me surpreenderia ver que os jogos de multijogador e "a conversa" applets empreendem uma nova sensação uma vez que este API é fora.
O último dos meios de comunicação APIs é a Telefonia API, que dá a Java a capacidade de interagir com telefones. A maior parte de funções telefônicas importantes, inclusive teleconferência e carteira de identidade de chamador, apoiam-se neste API.
A segurança ansiosamente esperada API curará confiantemente uma das limitações mais grandes de Java applets: a incapacidade de ler ou escrever arquivos localmente. Com o suporte cheio de criptografia, assinaturas digitais e autenticação, os desenvolvedores de Java devem ser capazes de alavancar questões de segurança até certo ponto e afastar-se da solução aparentemente superprotetora atualmente no lugar. A segurança API vai se incorporar consequentemente diretamente em Java principal API.
| Novo termo |
A criptografia abrange os algoritmos e as técnicas costumaram dar dados irreconhecíveis nas mãos de partidos não autorizados, por meio disso forçando o isolamento de informação. |
| Novo termo |
Uma assinatura digital é uma técnica de identificação eletrônica que serve o objetivo quase o mesmo como uma assinatura escrita à mão. |
| Novo termo |
A autenticação é o processo de verificar uma ação baseada em uma verificação da segurança. |
As funções criptográficas incorporadas na segurança API isolam-se da interface de programmatic usada por applets desejo tomar decisões de segurança. Este layering permite às funções criptográficas substituir-se por alternativas da terceira pessoa sem comprimir algo ao nível applet, por meio disso dando a desenvolvedores de Java mais opções quando vem às suas necessidades de segurança.
O API de Feijões de Java define um padrão aberto para implementar componentes de software Java dinâmicos, que são classes justamente empacotadas projetadas para a reutilizabilidade. Como os Feijões de Java API dá-se a cobertura proeminente na lição de amanhã, o dispensarei os detalhes suculentos por agora. Contudo, lhe direi agora que os Feijões de Java API se planejam para fundir com Java principal API em algum momento.
A última da extensão padrão APIs é o API Introduzido, que define um jogo mínimo da funcionalidade de Java especificamente visada para aplicações de sistemas embarcados, como dispositivos de eletrônica de consumo. O API Introduzido é o único API que realmente não acrescenta nada ao núcleo de Java API. De fato, o API Introduzido será provavelmente um subconjunto do API principal desde então só a parte da funcionalidade principal é necessária em aplicações introduzidas. Por exemplo, desde que a maior parte de sistemas embarcados não têm produção gráfica para falar de, o awt inteiro é realmente desnecessário. De mesmo modo, uma conexão de rede é improvável em um sistema embarcado, então não há necessidade de incluir Java que transmite pacote em rede.
| Novo termo |
Um sistema embarcado é um sistema de computador abaixo escalado programado para executar uma determinada função dentro de um dispositivo eletrônico. |
É provável que o API Introduzido se componha dos seguintes pacotes do API principal: língua, utilidade e entrada-saída. Além daqueles, é possível que as extensões API Introduzidas possam desenvolver-se para apoiar exigências de produção e ligação em rede especializadas. Desde que o API Introduzido é um subconjunto do API principal, vai se tratar provavelmente como uma extensão API.
Hoje aprendeu sobre a extensão padrão APIs que se planejam para estender Java em várias direções diferentes. Estes APIs não há dúvida empurrarão a apelação de Java a novos níveis, desde que os desenvolvedores terão muito mais código reutilizável para alavancar construindo aplicações alfandegárias e applets. Embora isto signifique enfim mais aprendizagem da parte de desenvolvedores, também resultará a escrita em menos tempo passada de código que se ajusta melhor a uma extensão padrão. Sabendo isto, muitos desenvolvedores vão se forçar a reconsiderar os seus planos atuais baseados na disponibilidade da extensão padrão APIs, como não há necessidade de reinventar a roda se já estiver nos trabalhos.
Amanhã continuará aprendendo sobre extensões de Java olhando para algumas outras tecnologias que vão afetar Java no perto do futuro.
| Qual exatamente é Java principal API e como se modificará? | |
| O API de Java principal desde a versão 1.02 de Java compõe-se dos oito pacotes que se embarcam com a versão 1.02 do Conjunto de Desenvolvedor de Java. Este API vai se modificar em futuros lançamentos para incorporar algumas tecnologias que emergem como parte da extensão padrão APIs. Contudo, não toda da extensão padrão APIs o fará no API principal; alguns permanecerão como extensões. | |
| Vai o Comércio API ajudar a estandardizar operações financeiras na Web? | |
| Eu esperança segura assim. Considerando o grande montante do desenvolvimento de Java que já se realiza, combinado com o desejo de JavaSoft de fazer o Comércio API extensível a várias tecnologias, suporta para raciocinar que o Comércio API será uma força principal na formação do futuro de operações financeiras na Web. | |
| Como são servlets desenvolvidos? | |
| Servlets desenvolvem-se do modo quase o mesmo como applets, exceto você usam o Servlet API em vez do Applet API. A maior parte de servlets provavelmente não terá interfaces gráficas, mas a aproximação de desenvolver-se servlets baseado em um API ainda é muito semelhante à aproximação atual do desenvolvimento applets. | |
| Como as assinaturas digitais afetarão a segurança de Java? | |
| Ainda não é claro o que o impacto total de assinaturas digitais estará na segurança de Java, mas a modificação mais provável será a remoção da restrição de acesso a arquivos local em applets. Usando assinaturas digitais, será possível validar a criação de um applet para que os usuários possam sentir-se seguros permitindo ao applet mais liberdade no seu sistema. |