[Java] Objecten in sync houden tussen server en client

[Marco1994]

Modbreak:

Dit topic is afgesplitst van MySQL insert meerdere rows in een stored procedure.

Had eigenlijk nog een vraag over hetzelfde project, als het in een nieuw topic moet hoor ik het graag.
De database staat al en is volledig geïmplementeerd, echter zit ik nog met een probleem te dubben namelijk.

De bedoeling is het volgende, de database staat op de server en de gegevens uit de DB moeten via sockets doorgestuurd worden naar de clients, de socket implementatie kom ik wel uit, zit echter nog te twijfelen hoe ik de classes over moet sturen. Neem de volgende Class:

Java:

public class Order implements IOrder{
    private int orderID;
    private int producerID;
    private LinkedList products;
    
    public Order(int orderID, int producerID) throws SQLException {
        this.orderID = orderID;
        this.producerID = producerID;
    }

    public Order(LinkedList products) {
        //insert into the database
    }
    
    @Override
    public int getOrderID() {
        return this.orderID;
    }

    @Override
    public LinkedList getProducts() throws SQLException {
        //return data van de socket of uit de database...
        throw new UnsupportedOperationException("Not supported yet."); //To change body of generated methods, choose Tools | Templates.
    } 

ik wil deze class dus over de socket sturen, echter wil ik op de server deze implementatie hebben op regel 21

Java:

@Override
    public LinkedList getProducts() throws SQLException {
        //return data uit de database
        throw new UnsupportedOperationException("Not supported yet."); //To change body of generated methods, choose Tools | Templates.
    } 

en in de clients

Java:

@Override
    public LinkedList getProducts() throws SQLException {
        //return data van de socket
        throw new UnsupportedOperationException("Not supported yet."); //To change body of generated methods, choose Tools | Templates.
    } 

ik dacht dit wel met een Interface op te lossen en dan met pseudo code het volgende te doen, maar uiteraard werkt dit niet.

code:

Client.Order = new Server.Order();

Hoe kan ik dit nu het beste aanpakken?

Edit:
ik zou in mn constructor alle products al op kunnen halen uiteraard en bij getProducts this.Products kunnen returnen, maar dit wil ik dus vermijden aangezien ik dan in een keer voor alle orders alle producten op moet halen.

[ Voor 7% gewijzigd door NMe op 21-03-2016 19:23 ]

[NMe]

Marco1994 schreef op maandag 21 maart 2016 @ 17:49:
Had eigenlijk nog een vraag over hetzelfde project, als het in een nieuw topic moet hoor ik het graag.

Je vorige topic ging over MySQL, deze vraag gaat over Java. Wat denk je zelf?

Het is bepaald niet mijn specialiteit maar volgens mij zoek je het remote proxy design pattern.

[Marco1994]

NMe schreef op maandag 21 maart 2016 @ 19:24:
[...]

Je vorige topic ging over MySQL, deze vraag gaat over Java. Wat denk je zelf?

Het is bepaald niet mijn specialiteit maar volgens mij zoek je het remote proxy design pattern.

Had het wel verwacht, dankje voor de afsplitsing. Ga er naar kijken
en
Edit: Remote proxy design pattern lijkt niet te doen wat ik wil.
begin mezelf wel af te vragen of wat ik wil wel mogelijk is

[ Voor 15% gewijzigd door Marco1994 op 21-03-2016 23:40 ]

[cytherea]

Is hier niet RMI voor bedacht? Wikipedia: Remote method invocation
Of SOAP zou ook redelijk transparant moeten werken.

Met alleen een socket implementatie ben je er nog niet, het object moet ook verpakt worden in een serieel format (XML, JSON, oid) en aan de ontvangende kant weer uitgepakt moeten worden om er weer java objecten van te maken. Dit proces heet Marshalling (Wikipedia: Marshalling (computer science)) en er zijn wel standaard libraries voor te vinden, vergis je niet in hoe complex dit kan zijn. RMI en SOAP doen dit voor je.

edit: Je hebt natuurlijk ook nog de serializable interface waar je wat mee kan doen.

[ Voor 6% gewijzigd door cytherea op 22-03-2016 13:05 ]

[Marco1994]

Het idee was inderdaad om te serializen, dit is allemaal helder. Vraag me nog steeds af hoe je twee verschillende functies hebt binnen dezelfde class.

[Kwistnix]

Ik snap niet precies waar de eis vandaan komt om client en server APIs op zo'n manier op code niveau in sync te houden, maar daardoor lijkt het dat je opzoek bent naar een CORBA-achtige oplossing. In Java voorziet RMI (remote method invocation) daar van oudsher in (http://www.oracle.com/tec...ech/index-jsp-138781.html). Ik zou daar heden ten dage echter niet snel meer voor kiezen. Het is een vrij complexe opzet, hoewel het in de loop der tijd wel een stuk eenvoudige is geworden met JRMP revisies en dynamische proxies (gerelateerd aan het pattern waar NMe het al over had).
Als je de vrijheid hebt om voor HTTP over een TCP/IP socket verbinding te kiezen - en ik zou niet weten waarom niet - dan kan je naar mijn mening veel beter kiezen voor een (RESTful) web service aanpak.

[Marco1994]

Kwistnix schreef op dinsdag 22 maart 2016 @ 16:06:
Ik snap niet precies waar de eis vandaan komt om client en server APIs op zo'n manier op code niveau in sync te houden, maar daardoor lijkt het dat je opzoek bent naar een CORBA-achtige oplossing. In Java voorziet RMI (remote method invocation) daar van oudsher in (http://www.oracle.com/tec...ech/index-jsp-138781.html). Ik zou daar heden ten dage echter niet snel meer voor kiezen. Het is een vrij complexe opzet, hoewel het in de loop der tijd wel een stuk eenvoudige is geworden met JRMP revisies en dynamische proxies (gerelateerd aan het pattern waar NMe het al over had).
Als je de vrijheid hebt om voor HTTP over een TCP/IP socket verbinding te kiezen - en ik zou niet weten waarom niet - dan kan je naar mijn mening veel beter kiezen voor een (RESTful) web service aanpak.

We zijn redelijk vrij in de technieken die we mogen gebruiken, zolang het grote deel maar in Java is. Ik bedacht mezelf dat het wel handig was om het op deze manier te doen. Echter na jouw uitleg denk ik dat ik voor een socket verbinding ga in combinatie met iets als json. Om een hele webapi te bouwen is een beetje overkill voor deze applicatie, zeker met in het achterhoofd houdend dat een socket verbinding zo opgezet is. Eerst voelde dit aan als een vieze hack opdat het tegen mijn oop principes ingaan, maar dat valt wel mee geloof ik. En RMI heb ik al eens meegewerkt, maar het is niet echt mijn ding, voel me er soms een beetje beperkt in. Dank voor je reactie

[CodeCaster]

Marco1994 schreef op dinsdag 22 maart 2016 @ 23:29:
in het achterhoofd houdend dat een socket verbinding zo opgezet is

Maar TCP ligt een paar lagen onder een bruikbaar applicatieprotocol (message framing, request-response).

Gebruik daar gewoon standaard HTTP voor, dat wiel wil je niet opnieuw uitvinden.

Je kunt ook niet zomaar "klassen" of "objecten" over de lijn sturen: je hebt het hier over objecten die aan beide kanten (client en server) "leven", maar totaal losstaand van elkaar zijn. Je kunt hooguit de geserialiseerde representatie van een object over de lijn sturen, maar wijzigingen die ene applicatie aan dit object doen, worden dan niet zomaar weerspiegeld in de andere applicatie.

Als je dat laatste wil, kom je uit op technieken als RMI of COM, en dat wil je al helemaal niet.

[ Voor 40% gewijzigd door CodeCaster op 22-03-2016 23:35 ]

[Kwistnix]

Marco1994 schreef op dinsdag 22 maart 2016 @ 23:29:
[...]

We zijn redelijk vrij in de technieken die we mogen gebruiken, zolang het grote deel maar in Java is.

Dat is sowieso fijn.

Ik bedacht mezelf dat het wel handig was om het op deze manier te doen. Echter na jouw uitleg denk ik dat ik voor een socket verbinding ga in combinatie met iets als json. Om een hele webapi te bouwen is een beetje overkill voor deze applicatie, zeker met in het achterhoofd houdend dat een socket verbinding zo opgezet is.

Dat wordt snel complexer dan je zou willlen. Ik ken de requirements verder niet, maar zeker als je meerdere clients moet ondersteunen ga je je - al met een relatief eenvoudige thread-per-connection aanpak - snel allerlei narigheid op de hals halen.

Een goede webapi bouwen is ook niet triviaal, maar de onderliggende remoting technieken krijg je in ieder geval al wel gratis. Je server applicatie kan je in een servlet container als Tomcat draaien, of je kan er een servlet container als Jetty in embedden. Aan de client kant kan je er in principe dan al met de standaard HttpURLConnection van Java mee verbinden. De HttpClient van Apache is al snel een betere en handigere optie. Het remoting stuk en alle complexiteit er achter heb je daarmee dan al afgedekt. Enige wat dan nog REST () is marshalling/unmarshalling van de objecten die je heen en weer wil sturen met een HTTP GET/POST/PUT/whatever. Daar zijn ook legio libraries voor te ondersteuning. Je kan JAXB pakken als je XML over de lijn wil sturen of Jackson als JSON of YAML je voorkeur heeft.

[Marco1994]

Kwistnix schreef op woensdag 23 maart 2016 @ 10:31:
[...]

Dat is sowieso fijn.

[...]
Dat wordt snel complexer dan je zou willlen. Ik ken de requirements verder niet, maar zeker als je meerdere clients moet ondersteunen ga je je - al met een relatief eenvoudige thread-per-connection aanpak - snel allerlei narigheid op de hals halen.

Een goede webapi bouwen is ook niet triviaal, maar de onderliggende remoting technieken krijg je in ieder geval al wel gratis. Je server applicatie kan je in een servlet container als Tomcat draaien, of je kan er een servlet container als Jetty in embedden. Aan de client kant kan je er in principe dan al met de standaard HttpURLConnection van Java mee verbinden. De HttpClient van Apache is al snel een betere en handigere optie. Het remoting stuk en alle complexiteit er achter heb je daarmee dan al afgedekt. Enige wat dan nog REST () is marshalling/unmarshalling van de objecten die je heen en weer wil sturen met een HTTP GET/POST/PUT/whatever. Daar zijn ook legio libraries voor te ondersteuning. Je kan JAXB pakken als je XML over de lijn wil sturen of Jackson als JSON of YAML je voorkeur heeft.

Dit zou ook allemaal mijn voorkeur genieten echter zijn er een paar omstandigheden die mij tegenwerken. We werken met scrum, onze eerste sprint duurt 3 weken, ik zit in een projectgroep met 4 slackers (voeren weinig tot niets uit of hebben simpel weg niet de benodigde kennis) het komt er dus op neer dat van de 6 personen, 2 mensen het hele project maken (al aangegeven bij mijn tutor maar die doet er niets mee. En project niet af == onvoldoende == jaar opnieuw

vanwege tijdnood moeten we een paar overwegingen nemen. We hebben het vanmiddag dus op de volgende manier opgezet: een client doet een call naar een multithreaded socket server, deze haalt gegevens uit een database, parsed die gegevens dmv Gson, stuurt het naar de client welke vervolgens converten naar een class. Als ik jullie berichtenn zo doorneem niet de meest ideale oplossing, maar wel de meest reële binnen deze projectgroep

[Kwistnix]

Als 't doet wat het moet doen en je kan het bouwen binnen de beperkte tijd die je hebt, dan is het een prima oplossing

[Marco1994]

Kwistnix schreef op woensdag 23 maart 2016 @ 20:19:
Als 't doet wat het moet doen en je kan het bouwen binnen de beperkte tijd die je hebt, dan is het een prima oplossing

Zekers, ben een stuk wijzer geworden door jullie expertise . Zal dit ook zeker meenemen naar de toekomst, helaas binnen dit project niet (meer) mogelijk