[JAVA]Objecten over Sockets

[CyBoB]

Ik ben bezig met een client/server applicatie dat via sockets werkt. De communicatie wordt tot nu toe via een eigen message based protocol('tje) gedaan. Ik vind dit niet lekker werken en nog moeilijker te onderhouden. Ik had liever de mogelijkheid gehad om met Objecten te werken.

Voor deze client/server applicatie heb ik alleen de beschikking over een kleine subset van de Java API waardoor ik niet met RMI/CORBA kan werken en heb ook geen mogelijkheid voor serialisatie. Ik kan dus niet ObjectInputStream/ObjectOutputStream gebruiken. Mijn vraag is nu ook of het mogelijk om een Object naar een byte[] te "converteren" deze over de socket te sturen en dan aan de andere kant deze weer naar een Object te "converteren" zonder het gebruik van de bovengenoemde classes?


Zo ja, hoe?

[Gerco]

Aangezien het niet automagisch gaat, prog het dan zelf

Prog in al je Objecten een toString() en een fromString(), dan kun je de strings oversturen. Het is niet zo handig als een ObjectStream, maar het werkt wel.

[CyBoB]

Op donderdag 11 april 2002 15:18 schreef Gerco het volgende:
Aangezien het niet automagisch gaat, prog het dan zelf

Prog in al je Objecten een toString() en een fromString(), dan kun je de strings oversturen. Het is niet zo handig als een ObjectStream, maar het werkt wel.

Dit is eigenlijk niet wat ik bedoel. Het gaat er nou namelijk om dat ik object wil oversturen die veel meer data bevat. Deze is daardoor lastig textueel over te sturen. dit is mijn huidige situatie:

1. Ik heb een ActionObject deze bevat een ID en een value (ook een Object)
2. deze gaat ik versturen over een socket door eerst het ID op te vragen en te versturen. Hierdoor weet de andere kant dat er daarna een value van de ID wordt verstuurd. Daarna stuur ik een (netzoals jij voorstelde) een string die de waarde van het Object representateerd.
3. Aan de andere kant (client) wordt er eenzelfde ActionObject geinstantieerd met de ontvangen ID en value.
4. waarna deze op de client kan worden gebruikt.
5. en omgekeerd. server --> client && client --> server

dit alles gaat met een handshake mechanisme.

Nu wil ik eigenlijk meer data in dat ActionObject gaan stoppen waardoor het moeilijk word om er een string van te maken. vandaar dat ik dat ActionObject in zijn geheel van de eene naar de andere kant wil sturen

[Gerco]

Dan zul je dus zelf een soort Objectstream moeten proggen. Misschien een idee om gewoon de source van de ObjectStream klasses proberen te compilen op je platform (misschien werkt het, in dat geval scheelt het enorm veel werk)

[Verwijderd]

ik heb niet zoveel verstand van java, maar het lijkt me niet de beste taal om dit soort dingen in te maken. Je weet immers nooit erg goed wat er in een object/variabele staat.

Je kan dus niet (zoals in c) gewoon een pointer (byte *)naar het object hebben, en met sizeof(hetObject). Dan heb je namelijk de stream die direct kan versturen.

Dit word in java waarschijnlijk een stuk lastiger.

(sorry dat dit niet echt een antwoord is)

[Gerco]

Op donderdag 11 april 2002 15:43 schreef unteraarsch het volgende:
Je kan dus niet (zoals in c) gewoon een pointer (byte *)naar het object hebben, en met sizeof(hetObject). Dan heb je namelijk de stream die direct kan versturen.

In C(++) kan dat ook niet, stel dat er in je datastructuur/object pointers naar andere structuren/objects zitten. Dan ben je met jouw methode ook helemaal nergens.

De enige (goede), mij bekende, manier is om een soort Serializable "interface" te maken en al je objecten die interface te laten implementeren (zoals het in Java geregeld is). Je moet dan voor je eigen objecten natuurlijk WEL even de Serialize() methode implementeren om je objectstate (andere objecten/pointers) te serializen enzovoort.

[CyBoB]

Op donderdag 11 april 2002 15:43 schreef unteraarsch het volgende:
ik heb niet zoveel verstand van java, maar het lijkt me niet de beste taal om dit soort dingen in te maken. Je weet immers nooit erg goed wat er in een object/variabele staat.

[...]
Dit word in java waarschijnlijk een stuk lastiger.

(sorry dat dit niet echt een antwoord is)

Ik ben bezig met een realtime embedded java controler.

het gaat een beetje moeilijk worden om hier in C(++) te gaan proggen

[Verwijderd]

Op donderdag 11 april 2002 15:47 schreef Gerco het volgende:
In C(++) kan dat ook niet, stel dat er in je datastructuur/object pointers naar andere structuren/objects zitten. Dan ben je met jouw methode ook helemaal nergens.

dan implementeer je toch een int deClass->sizeof() functie die zijn eigen sizeof optelt bij de sizeof's van de child-objecten, die hetzelfde doen..

[CyBoB]

Ik heb geprobeert om de losse classes ObjectInputStream/ObjectOutputStream te compilen. Dit is gelukt (hij krijgt alleen 1 deprecation warning). Als ik nu deze classes in mijn eigen stukje code wil gebruiken dan krijg ik de volgende compile error:

code:

ObjectTest.java:8: cannot access ObjectOutputStream
bad class file: .\ObjectOutputStream.class
class file contains wrong class: java.io.ObjectOutputStream
Please remove or make sure it appears in the correct subdirectory of the classpath.
      ObjectOutputStream out = new ObjectOutputStream(fis);

Hoe kan ik er voor zorgen dat de compiler nu mijn eigen classes gebruikt en niet die van Java.io.ObjectOutputStream ?

[Gerco]

Op donderdag 11 april 2002 16:00 schreef unteraarsch het volgende:dan implementeer je toch een int deClass->sizeof() functie die zijn eigen sizeof optelt bij de sizeof's van de child-objecten, die hetzelfde doen..

Wie zegt dat al die objecten/structuren in een opeenvolgend blok geheugen staan dan? Het zijn pointers he, dus die kunnen overal rondhangen.

[.oisyn]

Op donderdag 11 april 2002 15:43 schreef unteraarsch het volgende:
ik heb niet zoveel verstand van java, maar het lijkt me niet de beste taal om dit soort dingen in te maken. Je weet immers nooit erg goed wat er in een object/variabele staat.

java is juist wel de beste taal want in java heb je zoiets als reflectie. Je kunt dus van een klasse opvragen welke methoden en attributen hij bevat. Zo doen ObjectInputStream en ObjectOutputStream het ook.

Op donderdag 11 april 2002 16:21 schreef CyBoB het volgende:
Ik heb geprobeert om de losse classes ObjectInputStream/ObjectOutputStream te compilen. Dit is gelukt (hij krijgt alleen 1 deprecation warning). Als ik nu deze classes in mijn eigen stukje code wil gebruiken dan krijg ik de volgende compile error:

code:

..knip..

Hoe kan ik er voor zorgen dat de compiler nu mijn eigen classes gebruikt en niet die van Java.io.ObjectOutputStream ?

bovenaan in de source files staat de regel

code:

package java.io;

Je moet ze dus of in de directory java/io zetten, of die regel weghalen zodat ze in de 'root' package staan

[Verwijderd]

Hey CyBoB, ik weet niet wat je aan het proberen bent maar de objectInputStream/OutputStream maken intern natuurlijk gebruik van serializable objects (probeer maar eens een object te versturen dat niet serializable is; ik geloof dat bv een XMLDocument niet serializable is) dus als je geen serializable objects wilt gebruiken dan gaat het met een copietje van deze classes natuurlijk ook niet lukken.

Maar zeg nou eerst eens wat je precies wilt en waarom je bepaalde zaken niet mag gebruiken (en wat dan wel), dan kunnen de lezers hier misschien ook wat nuttiger reageren...

Als je zelf een willekeurige class wilt kunnen checken om on-the-fly in een ander formaat om te bouwen moet je eens kijken naar de reflection classes.

[.oisyn]

Op donderdag 11 april 2002 16:34 schreef Bunny het volgende:
Hey CyBoB, ik weet niet wat je aan het proberen bent maar de objectInputStream/OutputStream maken intern natuurlijk gebruik van serializable objects (probeer maar eens een object te versturen dat niet serializable is; ik geloof dat bv een XMLDocument niet serializable is) dus als je geen serializable objects wilt gebruiken dan gaat het met een copietje van deze classes natuurlijk ook niet lukken.

De serializable interface is er alleen maar om aan te geven dat een object geserializeert kan worden, niet meer en niet minder (het is dus niet zo dat er speciale methoden nodig zijn die in Serializable gedefinieerd zijn). Als je de volgende check gewoon verwijderd, dan kan het in principe met elk object (let wel dat lang niet alle objecten hierop zijn berekend, dus de kans is groot dat je vage errors krijgt):

code:

if (!(object instanceof Serializable))
    throw new NotSerializableException ("Object is not Serializable");

(of iets in die trand)

Maar verder neem ik aan dat CyBoB weet hoe de object input en outputstreams werken, anders was ie er niet eens over begonnen

Maar zeg nou eerst eens wat je precies wilt en waarom je bepaalde zaken niet mag gebruiken (en wat dan wel), dan kunnen de lezers hier misschien ook wat nuttiger reageren...

het zal wel aan mij liggen, maar het is mij vrij duidelijk

[CyBoB]

Op donderdag 11 april 2002 16:34 schreef Bunny het volgende:
[...] objectInputStream/OutputStream maken intern natuurlijk gebruik van serializable objects (probeer maar eens een object te versturen dat niet serializable is;

Dit had ik ook al in mijn achterhoofd zitten, maar ik moest toch wat proberen, dus daarom...

Op donderdag 11 april 2002 16:34 schreef Bunny het volgende:
Maar zeg nou eerst eens wat je precies wilt en waarom je bepaalde zaken niet mag gebruiken (en wat dan wel), dan kunnen de lezers hier misschien ook wat nuttiger reageren...

zie een vorige post: ik ben bezig met embedded java. deze ondersteund maar een kleine subset van de java api. Tevens wordt geen reflectie ondersteund vandaar ook niet de classes die het mogelijk maken om een object te serialiseren.


Ik zag laatst wat over SOAP voorbij vliegen op GoT. Ik denk dat ik daar maar eens meer over ga lezen.