- Ter um mecanismo simples mas ainda extensível.
A versão do Java Object Serialization existente no momento é a alpha2. Object Serialization permite criar um stream de bytes que, quando lidos, vão criar objetos equivalentes àqueles que foram escritos na stream. Isto seria tipicamente utilizado para manter cópias de objetos em uma forma constante, ou liberar cópias de objetos para código rodando em outra máquina virtual Java.
Esta capacidade de armazenar e recuperar Objetos Java é essencial na construção de vário tipos de aplicações, mas principalmente as transientes. A chave do armazenamento e da recuperação de objetos é a representação do estado do objeto numa forma serializada o suficiente para permitir a reconstrução do objeto. Para objetos Java, a forma serializada deve ser capaz de identificar e verificar as classes Java das quais os campos foram salvos e para restaurar estes campos em instâncias das mesmas classes. A forma serializada não precisa incluir a definição completa da classe, mas requer que está classe esteja disponível quando preciso.
Objetos para serem armazenados e recuperados frequentemente referem-se a outros objetos. Estes outros objetos devem ser armazenados e recuperados ao mesmo tempo para manter as relações entre os objetos. Quando um objeto é armazenado, tudo dos outros objetos que está acessível daquele objeto é armazenado igualmente.
Os objetivos para serializar objetos Java são:
- Ter um mecanismo simples mas ainda extensível.
- Manter o tipo e as propriedades de segurança do objeto em uma
forma serializada.
- Ser extensível para suportar a disposição para objetos remotos
conforme necessário.
- Ser extensível para suportar persistência de objetos Java.
- Requerer implementação por classe apenas para customização.
Sistemas distribuídos requerem que processamento sendo feito em diferentes espaços de endereços, potencialmente em locais diferentes, sejam capazes de se comunicar. Para um mecanismo básico de comunicação, a linguagem Java suporta sockets, os quais são flexíveis e suficientes para comunicação de um modo geral. Contudo, sockets requerem que o cliente e o servidor estejam engajados em protocolos a nível de aplicação de forma a codificar e decodificar mensagens para troca, e o desenvolvimento destes protocolos é duvidoso estando exposto a erros.
Uma alternativa para sockets é Remote Procedure Call(RPC), o qual abstrai a interface de comunicação até o nível de chamada de procedimento. Ao invés de trabalhar diretamente com sockets, o programador tem a ilusão de estar chamando um procedimento local, enquanto que de fato, os argumentos do procedimento são empacotados e passados para o alvo remoto da chamada. Os Sistemas RPC codificam os argumentos e retornam valores usando uma representação externa de dados, tal como XDR.
RPC, de qualquer forma, não se comporta bem dentro de sistemas distribuídos de objetos, onde a comunicação entre objetos no nível do programa residindo em diferentes espaços é necessária. De forma a casar a semântica da invocação de objetos, sistemas distribuídos de objetos requerem Remote Method Invocation ou RMI. Em tais sistemas, um objeto substituto local gerencia a invocação no objeto remoto.
Enquanto outros sistemas RMI podem ser adaptados para manipular objetos Java, estes sistemas não possuem uma integração sólida com o sistema Java devido aos seus requerimentos de inter-operabilidade com outras linguagens. Por exemplo, CORBA presume um ambiente heterogêneo e multilingüe, e portanto deve ter um modelo de objetos neutro com relação a linguagem. Em contraste, o sistema RMI da linguagem Java assume o ambiente homogêneo da máquina virtual do Java, e o sistema pode por consequência seguir o modelo de objetos do Java sempre que possível.