L'architecture SCA est un concept que vous pouvez implémenter de différentes manières. Elle n'exige aucune technologie, langage de programmation, protocole d'appel ou mécanisme de transport particulier. Les composants SCA sont décrits à l'aide du langage SCDL (Service Component Definition Language) qui est un langage basé sur XML.
Un composant SCA dispose des caractéristiques suivantes :
WebSphere ESB | WebSphere Process Server |
---|---|
Flux de médiation | Flux de médiation |
Objets Java™ simples | Objets Java simples |
Processus métier | |
Machines d'état métier | |
Règles métier | |
Tâches utilisateur |
L'architecture SCA distingue la logique métier de l'infrastructure afin que les programmeurs d'application puissent se consacrer à la résolution d'incidents métier. WebSphere Process Server d'IBM se base sur ce même principe. La Figure 1 affiche le modèle architectural de WebSphere Process Server.
Dans l'environnement WebSphere, la structure SCA se base sur l'environnement d'exécution Java 2 Platform, Enterprise Edition (J2EE) de WebSphere Application Server. La structure générale de WebSphere Process Server se compose d'un noyau SOA, de services auxiliaires et de composants de service. La même structure dotée d'un sous-ensemble de cette capacité globale, axée plus spécifiquement sur les besoins de connectivité et d'intégration des applications de l'intégration métier, est disponible dans WebSphere Enterprise Service Bus.
Le concept d'un composant logiciel est à la base du modèle de programmation SCA. Comme nous l'avons mentionné précédemment, un composant est une unité qui implémente une logique et qui la rend disponible aux autres composants via une interface. Un composant peut également exiger les services rendus disponibles par les autres composants. Dans ce cas, le composant affiche une référence pour ces services.
Dans SCA, chaque composant doit afficher au moins une interface. Le diagramme d'assemblage de la Figure 2 dispose de trois composants : C1, C2 et C3. Chacun d'entre eux dispose d'une interface représentée par la lettre I entourée d'un cercle. Un composant peut également se référer à d'autres composants. Les références sont représentées par la lettre R entourée d'un carré. Les références et les interfaces sont ensuite liées dans un diagramme d'assemblage. En règle générale, le développeur d'intégration "résout" les références en les connectant aux interfaces de composants qui implémentent la logique requise.
Pour fournir un accès aux services à appeler, le modèle de programmation SCA contient une classe ServiceManager qui permet aux développeurs de rechercher les services disponibles par nom. Voici un fragment de code Java type illustrant la recherche d'un service. La classe ServiceManager permet d'obtenir une référence au service BOFactory qui est un service fourni par le système :
//Get service manager singleton ServiceManager smgr = new ServiceManager(); //Access BOFactory service BOFactory bof =(BOFactory) smgr.locateService("com/ibm/websphere/bo/BOFactory");
Les développeurs peuvent utiliser un mécanisme similaire pour obtenir les références de leurs propres services en spécifiant le nom du service référence dans la méthode locateService. Après avoir obtenu la référence d'un service à l'aide de la classe ServiceManager, vous pouvez invoquer n'importe quelle opération disponible sur ce service indépendamment du protocole d'appel et du type d'implémentation.
Parfois, les composants ou les fonctions disponibles sur des systèmes externes indiquent la logique métier, comme les applications existantes ou d'autres implémentations externes. Dans ce cas, le développeur d'intégration ne peut pas résoudre la référence en connectant une référence à un composant qui contient l'implémentation dont il/elle a besoin pour connecter la référence à un composant qui "pointe vers" l'implémentation externe. Ce composant est appelé importation. Lors de la définition d'une importation, vous devez spécifier la méthode d'accès à un service externe (emplacement), ainsi que le protocole d'appel.
De même, si l'accès à votre composant s'effectue via des applications externes, ce qui est souvent le cas, vous devez le rendre accessible. Pour cela, utilisez un composant spécial qui affiche votre logique au "monde externe". Ce composant est appelé exportation. Il peut être appelé de façon synchrone ou asynchrone.
Dans WebSphere ESB, un module de service SCA est intégré comme fichier EAR J2EE qui contient plusieurs autres sous-modules J2EE. Les éléments J2EE, comme un fichier WAR, peuvent être intégrés au module SCA. Les artefacts autres que SCA, comme les JSP, peuvent également être intégrés à un module de service SCA. Ce dernier leur permet d'appeler des services SCA à l'aide du modèle de programmation client SCA grâce à un type de composant spécial appelé "référence autonome".
Le modèle de programmation SCA est hautement déclaratif. Les développeurs d'intégration peuvent configurer des aspects, comme le comportement transactionnel des appels, la propagation des données d'identification de sécurité, si un appel doit être synchrone ou asynchrone de façon déclarative, directement dans le diagramme d'assemblage. L'exécution SCA, non pas les développeurs, doit se charger de l'implémentation du comportement spécifié dans ces modificateurs. La flexibilité déclarative de SCA est l'une des fonctions les plus puissantes de ce modèle de programmation. Les développeurs peuvent se consacrer à implémenter la logique métier, au lieu de répondre aux aspects techniques, comme faciliter les mécanismes d'appel asynchrone. Tous ces aspects sont automatiquement gérés par l'exécution SCA.
Les qualificateurs régissent l'interaction entre un client de service et un service cible. Des qualificateurs peuvent être spécifiés dans les références de composant de service, les interfaces et les implémentations. Ils sont généralement externes à une implémentation.
Les différentes catégories de qualificateurs sont les suivantes :
SCA autorise l'application de ces qualificateurs de qualité de service (QoS - Quality of Service) aux composants de façon déclarative (sans aucune programmation ou modification du code d'implémentation des services). Ceci peut être effectué dans WebSphere Integration Developer. En général, les qualificateurs QoS sont appliqués lorsque vous êtes prêt à envisager le déploiement d'une solution. Pour plus d'informations, reportez-vous à la section Référence du qualificateur pour la qualité de service.