[Java] java serverplatform

[2playgames]

Met een groep gaan we een client-server applicatie maken voor het ontvangen van audiostreams op de mobiele telefoon. Een deel van deze applicatie wordt een service die de controle over de verbindingen met clients en andere zaken beheert.

We zitten met een lastige beslissing, namelijk het platform wat we voor deze service gaan gebruiken. We maken hem in principe in Java. We hebben wel ervaring met deze taal, maar niet in het ermee ontwikkelen van een service.

Onze opdrachtgever heeft ons aangeraden om Tomcat + Spring te gaan gebruiken. Hierop heb ik onderzoek gedaan, en ben ik te weten gekomen dat Tomcat een HTTP server is. Dit is een probleem want terwijl bij HTTP steeds een request wordt gemaakt en een antwoord volgt, moeten we een constante verbinding tussen client (in J2ME) en server hebben, waarbij de service zelf ook weleens een actie kan ondernemen.

Een applicatieserver die wel continu draaiende services ondersteunt is JBoss. Deze werkt echter via RMI, wat de mobiele telefoon niet (geheel) ondersteunt.

Verder zouden we de server natuurlijk van scratch kunnen bouwen. Ik weet niet of dit mogelijk is met Java, en met name of de opdrachtgever de applicatie dan makkelijk kan deployen.

Kan iemand ons hierover adviseren?

[Kwistnix]

Ik zou kijken naar SIP voor het beheren van sessies en RTP voor het afhandelen van de media stream. Ik denk dat je op de clients via J2ME wel iets met de JAIN SIP stack kan doen, server-side zal je iets als Bea Weblogic Sip Server of Ubiquity Sip Server moeten inzetten, zodat je gebruik maken van de SIP Servlet API.

[ Voor 5% gewijzigd door Kwistnix op 22-11-2007 13:42 ]

[2playgames]

dat ligt buiten het probleem. het streamen gebeurt via een darwin (of vergelijkbare) server, dat hoeven we verder niet te ontwikkelen.
het gaat hier over de controleserver. clients melden zich hier aan waarna zij een verbinding hebben. over deze verbinding gaat verkeer 2 richtingen op. de controleserver regelt bijvoorbeeld het weergeven van reclame of een chatbox op de client

[Kwistnix]

Ik kan het door jou geschetste scenario niet helemaal volgen.
Is het de bedoeling dat er met een telefoon ingebeld kan worden op een media server en dat die server na het opzetten van de sessie een audio stream begint af te spelen, als een soort IVR?
Of moet de server zich gedragen als back-to-back user agent die per client een sessie bijhoudt en deze koppelt, zodat clients met elkaar communiceren?
In ieder geval, als er gebruik wordt gemaakt van DSS dan heb je het over RTP/RTPS streams en voor het beheer van sessies kom je toch uit op SIP (als je het over IP verkeer hebt tenminste).
Je hebt het ook over reclame e.d., hoe past dat in het plaatje?

[ Voor 6% gewijzigd door Kwistnix op 22-11-2007 14:32 ]

[2playgames]

Ok ik zal het even wat beter uitleggen.

Er is een client. Wij maken deze voor de telefoon, maar in principe zou het ook op een desktop kunnen.
Deze client verbindt met een zelfgemaakte server (die ik vanaf nu Y noem). De client vraagt op Y een audiokanaal op. Y geeft daarop antwoord, in de vorm van een URL naar een RTSP stream.
De client begint deze stream te spelen.

Ondertussen blijft de verbinding tussen de client en Y behouden. Hierdoor kan Y de client reclame weer laten geven, of verschillende aangemeldde clients met elkaar laten chatten. Hierbij zal Y vaak zelf een actie moeten beginnen, de reden dat Tomcat niet geschikt is.

[Alarmnummer]

Je kunt denk ik gerust Tomcat gebruiken. Voor allerlei beheer functionaliteit is het sowieso wel handig om een webinterface erin te kunnen zetten (dus een servlet container is dan wel zo handig). Verder weten de meeste mensen wel hoe het beheerd moet worden.

Je kunt zelf gewoon sockets (tcp/udp) opzetten onder tomcat, dus allerlei hardcore java stuff die je wilt doen, kun je zonder problemen toepassen. En Spring is een prachtig framework om de compontenten die je hebt geschreven in op te lijmen. Tomcat en Spring zullen je hoogst waarschijnlijk niet in de weg zitten.

Spring + Tomcat is mijn favoriete combinatie om dit soort dingen in op te zetten.

[ Voor 13% gewijzigd door Alarmnummer op 22-11-2007 17:09 ]

[2playgames]

Maar hoe kun je dan een 'draaiende service' (ik ken geen betere term) in Tomcat maken? Van wat ik heb gelezen (verschillende boeken) is het een HTTP server, waarbij een servlet steeds aangeroepen en vernietigd word.

[Kwistnix]

Ik denk dat dit voor jou een interessant artikel is:

http://today.java.net/pub...in-streaming-java-me.html

[Alarmnummer]

2playgames schreef op donderdag 22 november 2007 @ 23:18:
Maar hoe kun je dan een 'draaiende service' (ik ken geen betere term) in Tomcat maken? Van wat ik heb gelezen (verschillende boeken) is het een HTTP server, waarbij een servlet steeds aangeroepen en vernietigd word.

Precies zo als je het onder een standaard java applicatie ook doet. De componenten die je maakt voor een webapplicatie zijn niet wezenlijk anders dan onder een standalone applicatie. Dus alle dingen die je gewoon onder java kunt doen, kun je ook doen onder Tomcat.

Je kunt tomcat dus uitbreiden met allerlei functionaliteit, je zou als je in een gekke bui bent er zo een ftp server aan vast kunnen bouwen. Je zit dus helemaal niet vast aan die httpserver functionaliteit van Tomcat.

[2playgames]

Aha, ja het dringt ineens tot me door. De JSP pagina's worden steeds opnieuw aangeroepen, maar de achterliggende servlets blijven altijd aanwezig, toch?
Bedankt voor de hulp, i.i.g.

[Confusion]

2playgames schreef op donderdag 22 november 2007 @ 13:04:
Dit is een probleem want terwijl bij HTTP steeds een request wordt gemaakt en een antwoord volgt, moeten we een constante verbinding tussen client (in J2ME) en server hebben, waarbij de service zelf ook weleens een actie kan ondernemen.

Een service kan ook actie ondernemen doordat de client om de zoveel tijd aan de server vraagt 'is er nog iets?'.

[Alarmnummer]

2playgames schreef op zaterdag 24 november 2007 @ 07:57:
Aha, ja het dringt ineens tot me door. De JSP pagina's worden steeds opnieuw aangeroepen, maar de achterliggende servlets blijven altijd aanwezig, toch?

Je mag servlets en jsp's in principe negeren. Als jij niet over HTTP/TCP (servlets) wilt werken, er is niets dat je let om het niet te doen. Op dit moment zit ik onder WebLogic in combinatie met sockets (TCP/IP) : het protocol de oude legacy systemen gebruiken en waar we mee moeten integreren. Je zit dus echt niet vast aan alleen HTTP/TCP combinatie onder een web (of applicatie) server. Je kunt gewoon 'standaard' java gebruiken in combatie met een heel skala aan technieken en protocollen zoals UDP.

Bedankt voor de hulp, i.i.g.

No problem. Maar lijkt me wel handig dat je de kennis aan boord krijgt om wat onderbouwde keuzes te nemen binnen het J2EE platform. Anders loop je onderandere de kans dat je onnodig werk gaat verzetten en zelf oplossingen loopt uit te vinden die wellicht al aanwezig zijn.

[2playgames]

We zijn hier nog steeds over bezig. We hebben al een echo service in Tomcat gemaakt (in de init() van een Servlet), maar we twijfelen nu aan de toegevoegde waarde van Tomcat, aangezien we die eigenlijk alleen gebruiken om de boel te starten.
In dit topic heeft iemand een vergelijkbaar probleem: http://forum.springframework.org/showthread.php?t=14081

We overwegen om de server gewoon helemaal standalone te maken, en Tomcat+Spring alleen in te zetten voor de webinterface.

[Alarmnummer]

2playgames schreef op maandag 26 november 2007 @ 12:10:
We zijn hier nog steeds over bezig. We hebben al een echo service in Tomcat gemaakt (in de init() van een Servlet), maar we twijfelen nu aan de toegevoegde waarde van Tomcat, aangezien we die eigenlijk alleen gebruiken om de boel te starten.

Leave it be for the moment zou ik zeggen. Vooral de servlet container is handig voor developers, en Tomcat voor het beheer.

En verder hoef je helemaal niet te werken met die servlets. Zet gewoon een java object in elkaar, zorg er voor dat er eventueel threads op staan, en slinger het aan de praat onder Spring.

vb:

code:

 <bean id="sockedBasedbanaanEndpoint"
          class="nl.bla.banaanconverter.server.SocketBasedbanaanServerImpl"
          init-method="init"
          destroy-method="shutdown">

        <constructor-arg index="0"
                         ref="xmlBasedbanaanService"/>

        <constructor-arg index="1"
                         ref="sockedBasedbanaanEndpointExecutor"/>

        <!-- the port the application is listening on (this property needs to be externalized in some prop file)-->
        <constructor-arg index="2"
                         value="9000"/>
    </bean>

    <!-- an executor that belongs to the socketBasedbanaanEndpoint. This Threadpool is responsible for
         executing incomming events from banaan, handeling these events, and sending back the result to banaan. -->
    <bean id="sockedBasedbanaanEndpointExecutor"
          class="java.util.concurrent.ThreadPoolExecutor">
        <!-- minimal poolsize -->
        <constructor-arg index="0"
                         value="10"/>
        <!-- maximum poolsize (the pool can grow and shrink)-->
        <constructor-arg index="1"
                         value="50"/>
        <!-- the timeout (a thread that doesn't do anything and is not needed
        gets removed after a certain timeout) -->
        <constructor-arg index="2"
                         value="2"/>
        <!-- the timeunit that belongs to the timeout argument-->
        <constructor-arg index="3">
            <bean id="java.util.concurrent.TimeUnit.MINUTES"
                  class="org.springframework.beans.factory.config.FieldRetrievingFactoryBean"/>
        </constructor-arg>

        <!-- the workqueue where unprocessed requests from banaan get stored -->
        <constructor-arg index="4">
            <!-- for the moment we don't want any unprocessed work: a worker needs to be available,
         or the task gets rejected. We have to play with the correct configuration but this will
         do for now -->
            <bean class="java.util.concurrent.SynchronousQueue"/>
        </constructor-arg>
    </bean>

    <!-- this thread keeps repeating the socketBasedbanaanEndpoint.helpOneClient method over and over -->
    <bean class="java.lang.Thread"
          init-method="start">
        <constructor-arg index="0">
            <bean class="nl.bla.banaanconverter.server.SocketBasedbanaanServerTask"
                  destroy-method="stop">
                <constructor-arg index="0" ref="sockedBasedbanaanEndpoint"/>
            </bean>
        </constructor-arg>
    </bean>

We overwegen om de server gewoon helemaal standalone te maken, en Tomcat+Spring alleen in te zetten voor de webinterface.

Als het goed is maak je je de componenten zo dat ze niet eens weten of ze in een webapplicatie of standalone applicatie worden gebruikt. Ik zou de keuze nog niet direct nemen maar nog even vooruit schuiven.

[ Voor 62% gewijzigd door Alarmnummer op 26-11-2007 13:43 ]

[2playgames]

We gaan ons maar even inlezen in Spring, want daar snappen we eigenlijk nog geen bal van

[2playgames]

En verder hoef je helemaal niet te werken met die servlets. Zet gewoon een java object in elkaar, zorg er voor dat er eventueel threads op staan, en slinger het aan de praat onder Spring.

maar hoe slinger je dat dan aan de praat zonder servlets. ik heb de "officiele" spring tutorial gedaan en daar worden de beans gemaakt door een DispatcherServlet.

stel ik zou een chatserver maken met sockets, en een webinterface die de geschiedenis van de chat laat zien. zet ik deze twee diensten dan in 1 webapp, of de server apart en de interface in een webapp?

ik heb nu in ieder geval al een simpele klasse (die wat naar de console print) aan het werk gekregen in Spring, zonder Tomcat

[ Voor 10% gewijzigd door 2playgames op 27-11-2007 11:43 ]

[Alarmnummer]

2playgames schreef op dinsdag 27 november 2007 @ 11:20:
[...]
maar hoe slinger je dat dan aan de praat zonder servlets. ik heb de "officiele" spring tutorial gedaan en daar worden de beans gemaakt door een DispatcherServlet.

Die DispatcherServlet zorgt er voor dat je requests aankomen bij je juiste Spring controllers. Voor jou totaal oninteressant.

simpel web.xml

code:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
         version="2.4">

    <display-name>Blabla</display-name>

    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>
            classpath:applicationcontext-main.xml
        </param-value>
    </context-param>

    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>

</web-app>

Nu gebruik je het mechanisme van een war om je applicatiecontext (applicationcontext-main.xml) op te starten. Verder heb je dan nog 0.0 te maken met servlets. Zie verder het vorige spring voorbeeld dat ik heb gegeven en zoek daar eens naar java.lang.Thread.

stel ik zou een chatserver maken met sockets, en een webinterface die de geschiedenis van de chat laat zien. zet ik deze twee diensten dan in 1 webapp, of de server apart en de interface in een webapp?

Ligt aan de complexiteit van het systeem. Ik zou voorlopig opteren voor alles in 1 applicatie te zetten.

[2playgames]

Ja! Ik heb een chatserver gemaakt, inclusief een webinterface die de geschiedenis laat zien, allemaal in 1 webapp.
Ik denk dat ik het doorheb. Bedankt voor de hulp, en als ik nog vragen heb zal ik ze hier zetten

edit: Ik heb nog een korte vraag. M'n service opent dus sockets. Hoe kan ik tomcat een methode aan laten roepen om ze te sluiten, als de app gestopt of gereload word?

[ Voor 28% gewijzigd door 2playgames op 27-11-2007 13:12 ]

[Alarmnummer]

2playgames schreef op dinsdag 27 november 2007 @ 13:10:
Ja! Ik heb een chatserver gemaakt, inclusief een webinterface die de geschiedenis laat zien, allemaal in 1 webapp.
Ik denk dat ik het doorheb. Bedankt voor de hulp, en als ik nog vragen heb zal ik ze hier zetten

edit: Ik heb nog een korte vraag. M'n service opent dus sockets. Hoe kan ik tomcat een methode aan laten roepen om ze te sluiten, als de app gestopt of gereload word?

Via Tomcat -> Servlet container -> Spring -> Jouw bean

See: 3.5. Customizing the nature of a bean
van de Spring documentatie.
http://static.springframe....5.x/reference/beans.html

Je kunt dus gewoon een stop en start methode maken op je service en die aansluiten vanuit Spring. Spring zorg er wel voor dat je objecten aangeroepen worden bij het opstarten/afsluiten.

Zie het voorbeeld met de sockedBasedbanaanEndpoint:

code:

<bean id="sockedBasedbanaanEndpoint"
          class="nl.bla.banaanconverter.server.SocketBasedbanaanServerImpl"
          init-method="init"
          destroy-method="shutdown">.....

Je hoeft dus niet meer te pielen met allerlei lifecycle methodes die de verschillende containers je aanbieden. je kunt gewoon de functionaliteit van Spring hiervoor gebruiken en willekeurige methodes op je objecten aanroepen.

[ Voor 9% gewijzigd door Alarmnummer op 27-11-2007 13:21 ]