Différences between.NET serveurs d'applications vs serveurs d'applications Java
J'aimerais mieux comprendre les raisons du modèle de serveur d'applications.NET par rapport à celui utilisé par la plupart des serveurs d'applications Java.
Dans la plupart des cas, j'ai vu avec ASP.NET applications web, la logique métier est hébergée dans le serveur web asp.net processus hôtes. Une autre approche courante consiste à avoir un niveau physiquement ou logiquement différent qui héberge vos objets métier et qui est ensuite exposé en tant que services Web ou accessible via des mécanismes tels que WCF. Cette dernière approche généralement mais ne semble pas toujours être utilisé lorsque l'échelle plus élevée est nécessaire. À l'époque des objets COM, j'ai vu Microsoft Transaction Server (MTS) et plus tard COM+ hosting utilisé pour héberger des objets COM contenant de la logique métier, avec MTS (théoriquement) gérant la durée de vie des objets, les transactions, la concurrence yada yada. Ce modèle semble en grande partie avoir disparu dans ASP.NET terre.
Dans le monde Java, vous pourriez avoir Apache avec Tomcat comme conteneur de servlet et vos objets métier hébergés dans Tomcat. Dans ce cas, Tomcat fournit des fonctionnalités similaires à celles fournies par MTS dans le monde.NET.
Plusieurs questions:
- Pourquoi la différence fondamentale entre les approches Microsoft et Java pour les serveurs d'applications? Cela devait être un choix d'architecture / de conception lorsque ces frameworks ont été créés.
- Quels sont les avantages et les inconvénients de chaque approche?
- Pourquoi Microsoft s'est-il éloigné du modèle d'hébergement MTS (qui est similaire au modèle d'hébergement de servlet Tomcast) au approche actuelle plus courante qui consiste simplement à avoir des objets métier dans le cadre du serveur Web ASP.NET processus?
- Si vous souhaitez implémenter l'approche de type MTS ou l'approche de type Tomcat dans ASP.NET applications aujourd'hui, je suppose qu'un modèle commun serait d'héberger des objets métier dans certains processus IIS (éventuellement sur un niveau physique ou logique différent) et d'accéder via WCF (ou des services Web asmx standard, peu importe). Est-ce correct?
1 answers
Pour ma façon de penser, la principale différence réside dans l'approche "ouverte" par rapport à l'approche "à pile intégrée". Microsoft aime fournir tout comme une pile intégrée qui partage tous une saveur et une approche communes. Java est plus convivial pour le modèle" bring your own x", où vous pouvez brancher votre serveur d'applications préféré, gestionnaire de transactions, etc. Les deux piles technologiques permettent l'invocation en cours de processus ainsi que l'invocation à distance avec différents niveaux de transaction soutien.
Vraiment, WCF n'est pas une nouvelle pile technologique, mais une réorganisation et un rebranding des éléments existants de la pile.NET. Plus précisément, WCF a pris en charge les fonctions de.NET Remoting, de services Web et de transactions distribuées.
Vous faites référence à "l'approche actuelle la plus courante qui consiste simplement à avoir des objets métier dans le cadre du serveur Web ASP.NET processus."Cela n'est courant que pour les applications non distribuées. C'est un modèle simple qui fonctionne bien lorsque tous vos objets résident sur le même serveur. Cela suit le modèle de déploiement "Scale Out" de Microsoft. Plutôt que de séparer les niveaux d'objets entre les serveurs, rassemblez tout sauf la base de données sur les serveurs Web, puis ajoutez progressivement des serveurs redondants identiques pour mettre à l'échelle la couche de serveur Web.
Microsoft a poussé dur ces derniers temps sur l'architecture orientée Service, qui repose plus fortement sur WCF et l'invocation à distance. Ceci est considéré comme une clé de la stratégie de cloud qui aurait des gens déplacer des parties ou toutes leurs applications vers des ressources flexibles dans le cloud (que MS aimerait héberger avec Azure, etc.).