råd vedr. platform til "single sourcing"

Du skal vælge client side teknologi. Mest oplagt er:
  * J2ME
  * .NET CF

Du skal vælge protokol. Mest oplagt er:
  * sockets
  * HTTP
  * web service (SOAP XML over HTTP)

Du skal vælge server side teknologi. Mest oplagt er:
  * J2EE
  * ASP.NET
  * .NET server app (altså ikke hostet i IIS)
  * J2SE server app (altså ikke hostet i JSP/servlet container)
måske ASP eller PHP hvis der er specielle grunde til dette.

Det var ikke et svar, men en uddybning af dit spørgsmål.

Med følgende restriktion:

sockets => .NET eller J2SE server app

HTTP eller web service => J2EE eller ASP.NET (evt. ASP eller PHP)

Valget af teknologi afhænger ikke kun af de tekniske krav i problem stillingen,
men i mindst lige så høj grad af den know how du har i forvejen. Du laver en
bedre løsning hvis du kender sproget & værktøjerne.

--> arne_v: Tak for dine kommentarer.
Mht. programmeringssproget, så er jeg ikke 100 meter-mester i noget sprog, så jeg er under alle omstændigheder indstillet på at skulle lære en del under processen med at udarbejde projektet. Jeg vil bare gerne finde ud af hvad der er den mest gængse metode, og høre om der er nogen der kan give nogle anbefalinger især mht. valg af lagringsmetode og evt. transformeringsværktøjer.

Alle de teknologier jeg nævner er brugt ude i den virkelige verden. Men jeg tør
ikke gætte på procentvis fordeling.

Medmindre data mængderne er rimeligt små, så ville jeg helt klart vælge at gemme
dem i en database.

Hvad mener du med transformerings værktøjer ?

Ang. transformeringsværktøjer: Hvis jeg havde mine data i en xml-fil, hvad ville så være den mest hensigtsmæssige metode til at transformere dem til fx html. Pt. kender jeg kun xslt, men har set eksempler hvor der er brugt java eller asp og DOM.

Hvilke trin vil mine data skulle igennem for at komme fra databasen til browseren? Jeg mener jeg har set eksempler på at man brugte en database og transformerede indholdet til xml, og derfra transformerede dataene videre til andre formater. Er det måden at gøre det på eller hvad?

De to grundliggende metoder er:
* transformering på client
* transformering på server

Ved transformering på client:

      <----(XML/HTTP)----server side script<----(XML)----database
browser
      <----(XSL/HTTP)----static XSL

Ved transformering på server:

                                            <----(XML)----database
browser<----(HTML/HTTP)----server side script
                                            <----XSL file

Ved PDA lyder transformering server side umiddelbart mest tiltalende.

ASP.NET, ASP, JSP, PHP har alle gode muligheder for at arbejde med XML.

Det skal helt klart foregå serverside. Men hvad opnår man ved at opbevare dataene i en traditionel database og derfra transformere dem til xml for at transformere dem endnu en gang til hvad det nu måtte være? Kan man ikke springe xml-stadiet over?

Jo du kan sagtens springe stadiet over og transformere data direkte fra databasen til det format, der ønskes.

XML er ikke de vises sten... MEN hvis din applikation kan levere data i XML format, så har du lavet en pæn snitflade, hvis andre systemer f.eks. skal bruge dine data.

Jeg gik lidt ud fra at data var i XML format d.v.s. at data kun hentes fra
database men ikke konverteres til XML når de hentes fra database. I så fald
er der ikke nogen dobbelt konvertering.

Hvis data ikke originalt er i XML, så er det en afvejning af om
en enkelt konvertering:
  HTML<---relationelle data
eller en dobbelt konvertering:
  HTML<---XML og XML<---relationelle data
er nemmest.

Umiddelbart lyder en konverting nemmere end to. Og der er ingen tvivl om at
den ene konvertering er den hurtigste CPU forbrugs mæssigt.

Men:
  - ved at bruge XSLT undgår man en masse komplex special kode og kan nøjes
    med nogle standard værktøjer
  - flere databaser bl.a. MS SQLServer kan lave konvertingen fra
    relationelle data til XML helt automatisk
så du kan meget nemt opleve at dobbekt konvertingen giver mindst kode
at vedligeholde og dermed også mindst omkostninger.

Aha, now we are talking.

Vil det sige at en mulig løsning kunne være en database der leverer xml på den ene eller den anden måde, hvor xml'en transformeres via xslt til web-brug og via fx j2me til pda'en? Vil den løsning være realistisk?

Jep lige nøjagtig.

Ja

Bortset fra at jeg forstod at du ville bruge browser på PDA'en.

J2ME kører på PDA og er overflødig med browser.

OK, hvis jeg nu insisterer på at bruge en browser på pda'en, er j2me så udelukket og hvad er alternativet?

Ikke udelukket. Men unødvendig.

Hvis du vil skrive en applikation til PDA'en som henter data, så kan du
bruge J2ME eller .NET CF.

Hvis du bruger en browser på PDA'en så skal du jo ikke skrive en applikation
og har ikke noget at bruge J2ME eller .NET CF til.

Tanken med mit projekt er at en læge på en hospital via sin pda hele tiden skal have mulighed for at hente informationer, fx om sygdomme. Så vil det ikke være mest naturligt at lade lægen tilgå de oplysninger via internettet, eller vil det være muligt at gøre det fx via bluetooth eller lignende.

Det skal uden tvivl ske via TCP/IP (om du kalder det internet eller intranet
er ligegyldigt).

Der er en applikation som henter noget data fra server og viser det på display.

Spørgsmålet er om den applikation skal være en browser eller en applikation
som du selv laver.

Så bliver det nok gennem en browser. Men vil det så sige at pda'en bare kan læse en almindelig html-side, der selvfølgelig er tilpasset de begrænsninger den nu en gang har i forhold til en pc? Det gør da det hele en del lettere.

Vil Access være brugbar som backend( det er nemlig den eneste db jeg pt har adgang til) eller vil det være bedre fx med Microsofts gratis udgave af SQL Server?

Jeg har ikke forstand på PDA'er. Men jeg formoder at du har en. Så check
om der er en web browser i den.

Access vil være brugbart til udvikling og lettere load.

MSDE kan klare noget mere.

Og MSDE har supporten for at generere XML.

--> arne_v: Tak for dine mange kommentarer. Du har som sædvanligt været en stor hjælp.
Læg et svar og få points.

Hvis der er andre der måtte have kommentarer, er de stadig velkomne.

ok