Nouveau séminaire en ligne : ILOG Rules for .NET et Microsoft BizTalk Server

François Merand [MS] — Mon, 23 Oct 2006 07:09:00 GMT

Après le lancement réussi de CodeFluent, voici un séminaire en ligne présenté par SOFTFLUENT le mardi 24/11 à 11h00 GMT+1 (en anglais)

Pour vous inscrire, c'est ici !

ILOG Rules for .NET and Microsoft BizTalk Server combined, complementary provide the best value in business process and business rules management in the following areas:

Business processes that include complex applications such as pricing, welfare administration, claims processing, eligibility, etc.
Policy-intensive processes including loan or insurance underwriting, loyalty management and more
BPM and business policy management across systems

Pour vous inscrire, c'est ici !

Un dit GO ! L’autre dit… GENIAL !

François Merand — Sat, 02 Apr 2005 15:28:00 GMT

L’arrivée de LongHorn marquera une version majeure dans l’histoire des OS chez Microsoft.

Constitué 3 piliers, dont deux sont dès à présent expérimentables : AVALON, et INDIGO et un troisième en phase de conception : WinFS, LongHorn contient aussi une brique de base essentielle : LES FONDAMENTAUX.

Microsoft à beaucoup communiqué à ce jour à destination de la communauté des développeurs à travers AVALON/XAML et INDIGO, et il convient de ne pas oublier ces fondamentaux qui sont très importants : ils caractérisent l’essentiel des nouveautés qui font de LongHorn réellement un nouvel OS.

Sans oublier bien sûr la nouvelle « expérience utilisateur » : AERO

Le thème de majeur de LongHorn est l’unification. Coté développement, unification de la couche de présentation avec AVALON et XAML, unification des données avec le futur WinFS et unification des modèles de programmation distribuées avec INDIGO.

Cette unification se retrouve à travers Win FX, un framework « managé » (code .NET) exposant l’intégralité des APIs du futur OS.

Intéressons nous de plus près à INDIGO.

A ce jour, nous connaissons 4 principaux modèles de programmation distribuée sur la plat-forme .NET :

Les services web, le modèle à couplage faible et interopérable. Ce modèle est complété par WSE (Web Services Enhancements) un sur-ensemble au framewotk .NET permettant de prendre en compte des critères tels que la sécurité, la fiabilité, les pièces jointes, en s’appuyant sur les recommandations du WS-I.
MSMQ et son namespace associé System.Messaging qui permet de s’appuyer sur un modèle de messagerie asynchrone et de files d’attente fiable.
COM+ le serveur d’applications, accessible à travers Enterprise Services.
Et enfin le .NET remoting.

Chacun de ces modèles suit une logique de conception, de programmation et de déploiement qui lui est propre. On sait quand utiliser tel ou tel modèle, mais une fois le choix fait, on ne peut passer simplement d’un modèle à l’autre.

L’idée d’INDIGO et de vous permettre d’écrire des solutions fédérant ces 4 modèles. Vous écrivez votre application (ce sera un service en terminologie INDIGO) et ensuite, vous déciderez comment exposer ce service sur un des 4 modèles, en précisant en plus les moyens (techniques) d’accéder à votre service.

Tout se résume donc à :

Un client qui consomme…
… un service et ce…
…à travers un réseau

Le dialogue se fait via des messages (qui adhèrent au formalisme SOAP, ce qui permet de s’appuyer sur tous les standards WS-*)

Le service (mais aussi le client) possède des points d’entrée, appelés « EndPoint » (les boîtes ABC sur le schéma).

Ces « EndPoints » contiennent et exposent 3 types d’information qui permettent de répondre à 3 questions classiques de l’informatique distribuée :

OU : où trouver le service que je dois consommer ? (Ex : http://..., net.tcp://…, xxx://…)
COMMENT : techniquement, comment me connecter au service, avec la notion de « binding ». (Ex : TCP transport + Duplex Channel + WS-Security)
QUOI : un contrat définissant ce que me propose le service. (ex : request/response, one way, etc.)

L’ensemble de ces informations (OU, COMMENT et QUOI) est formalisé dans des méta-données propres au service.

Ces 3 caractéristiques sont paramétrables et elles sont complétées par une 4^èmecaractéristique qui expose des comportements lors de l’appel au service (transaction, concurrence, sécurité, etc.)

Enfin, dans INDIGO un service doit être hébergé, et là, on le verra dans un autre article, l’environnement propose plusieurs solutions.

Dans un prochain article je détaillerai ces différentes notions en les illustrant avec des exemples simples.