J'ai une décision de conception à faire. J'ai besoin de vos conseils.
Exigences:
En ce moment, je n'ai pas d'expérience avec les services Web, mais si elle est Fondamentalement, je veux la vitesse et l'efficacité de l'option 1 avec une façon standard de faire des choses.
9 Réponses :
Go pour option 1 et utilisez des tampons de protocole Google pour autogénérer votre code à partir de la définition du protocole (c'est-à-dire que cela vous donne une consistance / une standardisation tout en étant encore efficace).
Ou Apache Thrift (a été développé sur Facebook)
Utiliser l'option 1, utilisez ASN.1 en tant que protocole! (Parfois appelé XML binaire.) Cela se traduit par de petits messages structurés pouvant être compris par d'autres. C'est une norme populaire et lorsque vous lisez ce message, vous venez de l'utiliser. : -)
ASN.1 fait partie de plusieurs protocoles Internet.
Comme je le comprends, ASN.1 est coûteux à analyser. Ce n'est pas auto-décrivant, de sorte que l'analyseur doit reconnaître tout objet codé possible, ce qui rend la migration difficile. Avec des formats auto-décrivants, le code plus ancien peut facilement reconnaître et ignorer la nouvelle syntaxe.
Il n'y a pas beaucoup d'asn.1 bibliothèques d'analyseurs et ceux qui existent ont tendance à être un peu chers. Mais c'est une norme ouverte et génère très peu de frais généraux. Je l'ai utilisé dans le passé dans le cadre d'un système de communication avec un système PBX, où le matériel PBX est nécessaire pour recevoir les commandes du format ASN.1. Il existe des lecteurs de base disponibles qui peuvent lire n'importe quel message ASN.1 et combinés à une description supplémentaire de protocole, il est facile d'utiliser ces lecteurs pour analyser le message complet.
On dirait que vous seriez mieux servi par le protocole HTTP. Il a une forte surcharge, déjà bien acceptée. Utilise TCP [qui est une exigence de communication mobile], il dispose de négociations de session [Connexion de puits, pas l'état actuel de la session]
Utilisez un protocole différent pour le partage de vidéos et audio, mais définissez la connexion avec le HTTP.
L'utilisation des services de savon / Web ne serait pas optimale, en raison du traitement requis. Depuis que les clients de l'expérience personnelle desservices sur des machines mobiles sont plus faciles, mais le traitement requis est considérable et peut créer un goulot d'étranglement dans votre application. [Les machines mobiles ne manipulent pas trop bien les fils]
Aussi: Comme vous envoyez des données sur le sans fil, vous devez également rendre compte des problèmes supplémentaires traitant des supports non guidés.
En outre, j'ai oublié de mentionner le savon / Webservices est XML sur http.
J'utiliserais invariablement une structure de données aux deux extrémités pour envoyer les données. Maintenant, il semble que je dois encapsuler le contenu de la structure de données dans une demande HTTP. Je devrais analyser la structure de données aux deux extrémités. Que dites-vous sur les tampons de protocole de Google comme suggéré Adamski.
Dépend des exigences du périphérique mobile ... avec des spécifications Hautes PPC + Utilisez autrement GPB B / C Ses appareils les plus faciles mobiles sont des périphériques de performance de manière générale, B / C L'objectif principal étant la durée de vie de la batterie autant que possible. RÈGLE OFFRE: Si l'appareil dispose d'un modem GSM / CDMA, il aura une CPU à bas niveau pour économiser de l'énergie. CODE.GOOGE.COM/P/ProTOBUF Problèmes avec ceci: 1. Il étend son protocole HTTP [Pas une mauvaise chose mais pas barebones] 2. Ajoute des caractères supplémentaires [Ceci peut retarder la transmission] 3. Le composant tiers est utilisé (cela rendra votre exécutable plus gros)
Eh bien, je viens de regarder, j'ai pensé que la tâche principale de Google tout ce qu'ils ont fait était à peu près http. Après un coup d'œil à travers leur tutoriel: les tampons de protocole de Google ne sont qu'un nouveau moyen de sérialiser les données. Cela signifie donc que vous pouvez utiliser n'importe quel protocole (y compris HTTP) avec GBP. Dans un environnement mobile, vous ne pouvez pas vous permettre d'accoupler des articles que vous pouvez sur les environnements de bureau. Dans un environnement mobile, vous avez besoin d'une vitesse (avec un environnement de développement raisonnable) et d'une efficacité (puissance des déchets de code non efficaces).
Je recommanderais Option 3 et ne vous inquiétez pas des problèmes de threading. Si vous l'hébergez dans un conteneur de servlet, le conteneur utilisera presque certainement les piscines de fil pour optimiser le traitement des demandes entrantes et contrôlera le nombre de threads dans l'application.
Aussi http / 1.1 prend en charge le pipeline et la réutilisation des connexions pour les demandes suivantes. Cela réduit le fardeau du serveur pour la mise en place et la déchirure des connexions.
Pour commencer, évitez le savon si vous souhaitez mettre le client sur un téléphone mobile et avoir une solution lumineuse. Le savon est un cochon sur la gaspillage de la CPU et de la bande passante. Ce n'est pas la solution la plus simple non plus.
Si vous envisagez d'avoir des clients implémentés sur le navigateur (à l'aide de JavaScript), une solution basée sur JSON est la voie évidente à suivre et c'est simple aussi. Pour un acipé de ce que ce serait, veuillez lire cet article:
Vous pouvez trouver plus de ressources à json.org
Vous pouvez probablement utiliser un jax-rs tout comme une implémentation de servlet glorifiée. (Beaucoup d'entre nous disent que JSR 311 de JAX-RS ressemble à ce que le Spec Spec devrait être dès le début ... ce qui n'est pas exactement si simple, mais ...)
À propos du "Un fil de fil par post" - qui est un problème, car toutes les technologies que vous mentionnez se comportent de la même manière sur la plupart des serveurs d'applications / moteurs de servlets - chaque demande étant traitée à un moment donné prendra son propre thread.
(Vous ne parlez pas de comète ici - une tecnhologie qui a tendance à prendre un fil
NON Typiquement, il y aura une application sur le mobile et non un navigateur. Je vais regarder la comète et commenter plus tard.
Que diriez-vous de la comète comme le comportement du serveur?
Que diriez-vous de la comète comme un comportement?
mais si vous ne devez que transférer du texte, vous pouvez utiliser votre
Le besoin en temps réel (si pris littéralement ) coupe beaucoup de choix : Le protocole HTTP n'est pas en temps réel et donc quelque chose au-dessus de celui-ci (y compris le savon et le repos) partage la même faiblesse. S'il s'agit d'une forte exigence, vous devriez examiner le protocole RTP ou autre chose qui ( au moins) ne fait pas la main.
C'est une standard
Il permet aux messages dans les deux directions.
Vous pouvez utiliser une infrastructure XMPP existante (les clients peuvent se connecter à l'aide de leurs comptes Google Talk, par exemple), ou construisez facilement votre propre utilisation de serveurs XMPP open source
J'aime aussi le fait que vous n'écrivez essentiellement que le code client (comme le serveur est également un client XMPP) - supposer que le serveur et le client sont tous deux écrits dans la même langue, vous pouvez même utiliser exactement le même code.
Les transferts de fichiers sont pris en charge.
facilement extensible à vos besoins
Il buzzing (Google Wave);)
La seule chose que les gens pourraient discuter de son efficacité - ou de l'efficacité de XML en général. Je ne pense pas que ce soit un problème cependant.
+1 J'étais sur le point d'ajouter XMPP comme une réponse, mais vous m'avez battu. C'est la façon évidente d'y aller. Pubsubhubbub est l'autre possibilité qui pourrait avoir beaucoup de sens.
Nous ne savons pas quel type d'appareils mobiles qu'il ciblent, mais le traitement XML n'est pas exactement rapide sur les processeurs mobiles.
@steven: C'est vrai, mais les documents XML de XMPP sont assez courts de toute façon. rendant ainsi XMPP adapté à la plupart des processeurs mobiles.
Hesse est un protocole binaire LightwieGht sur http. Il existe de nombreuses implémentations hessiales différentes afin que vous puissiez servir un certain nombre de clients différents.
Étant donné que vous êtes préoccupé par l'efficacité, vous pouvez trouver des métriques sur différents protocoles Java Remoting ici: http://daniel.gredler.net/2008/01/07/java-remoting-protocol-benchmarks/
S'il s'agit d'un vote / vote, pourriez-vous le rendre communautaire wiki?
(a) Pouvez-vous élaborer des exigences en temps réel? (b) Existe-t-il des exigences de sécurité?
@Jeremy C'est une décision de conception encore, n'est-ce pas liée à la programmation.
@Michael - question de client, réponse du serveur. La réponse pourrait également être du contenu multimédia. Ainsi, l'interaction doit être faite en temps réel. Je pense que les servlets sont bons pour la navigation. Oui, il existe des exigences de sécurité. Mais pour le prototype no.
Les données doivent-elles être sécurisées, c'est-à-dire cryptées?
Vos commentaires sur l'option 2 sont quelque peu invalides. Le savon et le repos sont mis en œuvre sur HTTP, de sorte que le "nouveau thread par demande" s'applique également à eux. Je considérerais cela comme une caractéristique: elle améliore les performances globales en ne tenant pas de ressources entre les demandes et active l'évolutivité, l'équilibrage de la charge et la disponibilité élevée.
@James, le savon ne doit pas nécessairement être sur http! SMTP est également utilisé comme couche d'application pour le savon, bien que la plupart des gens n'utilisent plus cela.