BPEL Java Embedded : retourner du XML vers BPEL

La plupart du temps, l'output généré par une méthode java embarquée dans du code BPEL se résume à un setVariableData d'une string vers une variable BPEL.

Je ne connais pas de méthode simple pour renvoyer un document XML directement (voir plus bas).

Cependant, il suffit de convertir votre variable bpel string en document XML. Simple, concis et efficace :

<from expression="ora:parseEscapedXML(bpws:getVariableData('myStringVariable'))"/>

== La méthode suivante ne fonctionne pas (mais il me semble qu'elle le devrait) ==

Au début du document BPEL, réaliser les imports suivants:

<!-- Import for building XML document to string -->

<bpelx:exec import="javax.xml.parsers.DocumentBuilderFactory" />
<bpelx:exec import="org.xml.sax.InputSource" />
<bpelx:exec import="org.w3c.dom.Document" />
<bpelx:exec import="java.io.StringReader" />

Dans la fonction java, voici comment construire un document XML à partir d'une string :

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();

InputSource source = new InputSource( new StringReader(xmlStr));

Document document = factory.newDocumentBuilder().parse(source);

// Copy the file in the BPEL variable

setVariableData("myVariable","parameters", "/xpath:myxpath",document);

Commandes SQL pour base de données Oracle

Lister toutes les tables

SELECT * FROM cat;

Emissions Co² modes de productions

Stockage en ligne

Deux bonnes offres de stockage en ligne:

http://www.humyo.fr (10Go)

htt://www.ADrive.com (50 Go)

Le Grid sur Amazon EC2

Je ne peux m'empêcher d'immédiatement imaginer des scénarios relatifs à l'utilisation du Grid Computing, dans le cadre d'orchestration de tâches/jobs de type bash.

D'une part, si nous utilisons l'infrastructure Amazon EC2 de façon statique (un ensemble de noeuds définis, comme n'importe quel système on-demand), nous pourrions simplement utiliser un scheduler pour ordonnancer et organiser les jobs. Pas besoin de Grid dans ce cas, il me semble.

Au contraire, si l'on considère l'utilisation de l'auto-scaling, l'utilisation de middleware permettrait de mettre en oeuvre facilement la découverte et mise à jour de la topologie des noeuds disponibles.

Mais l'Elastic Load Balancing ne permet-elle pas de se passer de découvrir les ressources, le Cloud d'Amazon EC2 se chargeant lui même de balancer les tâches "là où il y a de la place" et d'augmenter le Cloud si besoin. Les noeuds reçoivent donc les jobs, les exécutent et envoient les résultats au workflow ou à l'application sensées collecter les résultats.

Premières impressions sur Amazon EC2

Vous avez dit Grid ?

Amazon EC2 est avant-tout un service de fourniture de ressources à la demande (on-demand computing, ou utility computing). C'est à dire un grand parc informatique dont on loue les ressources à la demande.

Amazon EC2 utilise des techniques de virtualisation permettant de créer facilement des instances de ressources utilisables très rapidemment.

En outre, Amazon EC2 offre également quelques fonctions avancées bien pratique :

• Auto-scaling : selon des critères quantitatif relatif par exemple au traffic ou à la charge CPU, Amazon peut dynamiquement créer des instances de ressources supplémentaires (basées sur une configuration définie par l'utilisateur)
• Elastic Load Balancing: Amazon EC2 est capable de distribuer le traffic sur plusieurs machines et d'augmenter le nombre de machine

Par contre, Amazon EC2 ne fait en rien du scheduling, ni de la parallélisation d'application, il offre uniquement une infrastructure utile pour le faire.

Cloud Computing: informatique dans les nuages

Les clés du cloud computing (en construction) dit "informatique dans les nuages"

La mission du GRID était de proposer une solution de virtualisation de ressources mutualisées délocalisées et hétérogènes.

L'objectif du Cloud Computing est de proposer, reposant sur une infrastructure virtuelle, des services d'utilisation des ressources selon différent niveau d'abstraction (infrastructure, plateforme, application).

- Similitudes avec l'utility computing: les ressources/l'infrastucture est gérée par un fournisseur de ressources (provider). Ainsi, plutôt que de virtualiser en un tout des ressources de plusieurs organisations (GRID), le Cloud Computing Provider mutualise son grand parc de ressources gigantesques pour fournir un grand nombre d'utilisateurs. "Le Cloud Computing nécessite d'énormes data centers, Tous les fournisseurs qui se lancent dans le Cloud Computing nécessitent des infrastructures gigantesques. C'est le cas de Google, Yahoo, Amazon et bien d'autres..." (ITR Manager)

- XaaS (x as a service) : fournir les ressources/applications/plateforme comme on fournit un service (service de stockage, service de calcul, service de gestion de documents, ...). Cela inclut souvent un modèle économique de paiement d'application à la demande plutôt que par licence. Ainsi on pourrait commande une application et commande l'espace disque nécessaire pour l'application, ainsi que de la puissance de calcul pour faire tourner l'application.

- Similitude avec le GRID : l'infrastructure sous-jacente est un nuage (Cloud) composé d'un certain nombre de serveurs distants interconnectés au moyen d'une excellente bande passante indispensable à la fluidité du système

Divergences :

- La philosophie du Cloud n'est plus de proposer une solution middleware pour virtualiser un parc de ressources disponibles dans les entreprises. Il s'agit de proposer directement un service de ressources/plateformes/applications disponible directement. Economiquement, on imagine qu'actuellement ce n'est pas plus cher car le parc est mutualisé (ce qui est très rentable) et d'autres part les ressources en elle-même sont bcp moins chères qu'avant.

- Le Cloud veut rompre avec la notion de scheduling et de file d'attente. Le parc (pool) de ressources doit pouvoir supporter tout pic de demande. Finalement, le Cloud s'affranchit de ces questions...

- Le Cloud ne s'attaque pas à la fédération inter-infrastructure sous l'API. Ceci pouvant conduire à des comportements non déterministes et des instabilités. C'est directement intégré dans l'API (---> euh voir ce qu'il veut exactement dire par là)

La philosophie du Cloud Computing est-elle la suivante: plutôt que de réserver X To de données d'espace, l'utilisateur souscrit à un espace disque infini. Il paie ce qu'il utilise. Abstraction donc totale de la taille d'espace disque.

Victime de piratage

Pour les victimes de pirate, où porter plainte ?

Si votre email, votre compte facebook ou votre comptes et mots de passe ont été détournés pour vous nuire, vous pouvez porter plainte (gratuitement bien sûr) au service de police de l'internet.

Fournissez bien toutes les informations nécessaires :

- adresse email

- noms des comptes

- dates et heures des activités "illicites"

Il est bien sûr inutile de fournir vos mots de passe.

==>
https://www.ecops.be