Learn IT with Shikha Blogs

Les architectures modernes reposent de plus en plus sur la messagerie asynchrone, les microservices, l’Event-Driven Architecture et le traitement des données en temps réel . Trois technologies apparaissent régulièrement lors de la conception de ces plateformes : Apache Kafka, Apache Pulsar et RabbitMQ. À première vue, elles semblent résoudre le même problème : permettre à différentes applications de communiquer de manière asynchrone. Mais leurs architectures et leurs modèles de fonctionnement sont différents. Apache Kafka est principalement une plateforme distribuée d’ event streaming reposant sur des logs persistants. Apache Pulsar combine messaging et streaming avec une architecture séparant les brokers du stockage persistant. RabbitMQ est historiquement un message broker particulièrement adapté aux queues, à la distribution des tâches et au routage flexible des messages. Les versions modernes proposent également les Quorum Queues et RabbitMQ Streams . La vraie question n’est ...

 Modern enterprise applications increasingly depend on asynchronous messaging, event-driven architecture and real-time data processing . Three technologies frequently considered for these requirements are: Apache Kafka, Apache Pulsar and RabbitMQ. Although all three can move messages between distributed applications, their architectures, messaging models and operational characteristics are different. Apache Kafka is fundamentally an event-streaming platform built around durable distributed logs. Apache Pulsar combines messaging and streaming with a cloud-oriented architecture that separates brokers from persistent storage and provides multi-tenancy and geo-replication as major architectural features. RabbitMQ is traditionally a message broker and excels at queue-based messaging and flexible message routing, while modern RabbitMQ also provides replicated quorum queues and persistent streams. So which one should an enterprise architect choose? The answer depends on the pro...

 Les entreprises modernes doivent souvent gérer les documents et contenus de plusieurs départements, filiales, clients, partenaires ou organisations tout en maintenant une séparation claire entre leurs données. Créer une infrastructure Alfresco complètement indépendante pour chaque organisation peut augmenter les coûts d’infrastructure, d’administration et de maintenance. C’est précisément l’un des problèmes auxquels répond l’ architecture Multi-Tenant d’Alfresco . Alfresco Content Services peut fournir une architecture de référentiel multi-tenant dans laquelle plusieurs tenants utilisent une infrastructure Alfresco commune tout en opérant dans leurs propres contextes. Dans l’implémentation classique de la multi-tenancy Alfresco, les stores et plusieurs services associés sont partitionnés logiquement par tenant. Dans ce guide, nous allons comprendre : le fonctionnement de la multi-tenancy dans Alfresco ; l’architecture d’un environnement multi-tenant ; l’isolation des t...

Modern enterprises often need to manage content for multiple departments, business units, customers or organizations while keeping their data logically separated. Creating and maintaining a completely independent content-management platform for every organization can increase infrastructure and administration overhead. This is where Alfresco Multi-Tenancy becomes useful. Alfresco Content Services can provide a multi-tenant repository architecture in which multiple tenants use shared Alfresco infrastructure while tenant-specific users, content and services operate within their respective tenant context. In the classic Alfresco multi-tenancy implementation, tenant stores and several repository services are logically partitioned. In this guide, we will understand: What Alfresco multi-tenancy means Alfresco multi-tenancy architecture Tenant isolation Database and content-store architecture Search and indexing Tenant users and administrators Tenant-aware APIs Security...

 Modern enterprise systems rarely keep all their data in one application. Customer information may reside in PostgreSQL, orders in MySQL, events in Apache Kafka, analytics data in a warehouse, and searchable documents in Elasticsearch. Moving data reliably between all these systems can quickly become complicated. This is exactly the problem Apache Kafka Connect is designed to solve. Kafka Connect provides a standardized framework for moving data into and out of Apache Kafka without requiring every development team to build and maintain custom producers and consumers for common integration scenarios. Kafka Connect supports both standalone and distributed deployment models and provides automatic offset management and a REST interface for connector management. In this guide, we'll explore: Kafka Connect architecture Source Connectors Sink Connectors Connect Workers Connectors and Tasks Converters Single Message Transforms Offset management Standalone vs distr...

 Les architectures modernes d’entreprise stockent rarement toutes leurs données dans une seule application. Les informations clients peuvent se trouver dans PostgreSQL, les commandes dans MySQL, les événements dans Apache Kafka, les données analytiques dans un Data Warehouse et les données de recherche dans Elasticsearch. Déplacer ces données de manière fiable entre tous ces systèmes peut rapidement devenir complexe. C’est précisément le problème que Apache Kafka Connect permet de résoudre. Kafka Connect fournit un framework standardisé permettant de transférer les données vers et depuis Apache Kafka , sans obliger chaque équipe de développement à créer et maintenir ses propres producteurs et consommateurs Kafka pour les scénarios d’intégration courants. Dans ce guide, nous allons découvrir : l’architecture Kafka Connect ; les Source Connectors ; les Sink Connectors ; les Connect Workers ; les Connectors et Tasks ; les Converters ; les Single Message Transforms...

  Alfresco Share fournit une interface web configurable permettant de gérer les documents, sites, workflows, métadonnées, recherches et fonctions collaboratives d’Alfresco Content Services. Dans les implémentations d’entreprise, l’interface Share standard ne suffit cependant pas toujours. Les projets nécessitent souvent des tableaux de bord personnalisés, de nouvelles actions, une identité visuelle propre à l’organisation, des métadonnées supplémentaires, des menus spécifiques, des dashlets métier ou encore des intégrations avec des applications externes. C’est là que la personnalisation d’Alfresco Share devient essentielle. Dans ce guide pratique, nous allons découvrir comment étendre Alfresco Share à l’aide de Surf, des modules d’extension, des dashlets, des widgets, des Web Scripts et de la configuration Share , tout en évitant de modifier directement le code standard d’Alfresco. Ce que vous allez apprendre À la fin de ce guide, vous comprendrez notamment : l’architec...

 Alfresco Share provides a configurable web interface for working with documents, sites, workflows, metadata, searches and collaboration features in Alfresco Content Services. For enterprise implementations, however, the default Share interface is rarely the end of the story. Projects often require custom dashboards, new actions, organization-specific branding, additional metadata, custom menus, specialized dashlets and integration with external business applications. This is where Alfresco Share customization becomes important. In this practical guide, we'll explore how Alfresco Share can be extended using Surf, Share configuration, extension modules, dashlets, widgets and web scripts , while keeping customizations separate from the Alfresco product code. What You Will Learn By the end of this guide, you should understand: Alfresco Share customization architecture Share UI extension points Surf framework fundamentals share-config-custom.xml Surf Extension Module...

 Déployer Apache Kafka sur Kubernetes ne consiste pas simplement à lancer quelques conteneurs Kafka. Une plateforme Kafka destinée à la production doit prendre en compte plusieurs éléments essentiels : la disponibilité des brokers ; la disponibilité des contrôleurs KRaft ; le stockage persistant ; les pannes de pods et de nœuds ; la réplication des partitions ; la scalabilité des brokers ; l'allocation des ressources ; la connectivité réseau ; l'observabilité ; le consumer lag ; la sécurité ; les mises à niveau ; la reprise après sinistre. Kafka est une plateforme distribuée et stateful , tandis que Kubernetes orchestre dynamiquement les workloads et leur infrastructure. Une architecture robuste doit donc combiner les mécanismes de réplication et de quorum de Kafka avec les capacités d'orchestration de Kubernetes . Dans ce tutoriel, nous allons étudier une architecture pratique de déploiement Kafka sur Kubernetes , avec un accent particulie...

Running Apache Kafka on Kubernetes is much more than starting a few Kafka containers. A production Kafka platform must address: broker availability; KRaft controller availability; persistent storage; pod and node failures; partition replication; broker scaling; resource allocation; network connectivity; observability; consumer lag; security; upgrades; disaster recovery. Kafka is a distributed stateful platform, while Kubernetes dynamically schedules and replaces workloads. A successful architecture must therefore combine Kafka's replication and quorum model with Kubernetes orchestration and infrastructure primitives . In this tutorial, we will explore a practical Kafka deployment architecture on Kubernetes , including scaling, high availability, KRaft, storage and monitoring.

 A well-designed content model is one of the foundations of a successful Alfresco Content Services implementation. Organizations rarely manage only generic documents. They manage business objects such as: Contracts Invoices Employee documents Policies Purchase orders Technical documents Customer records Legal documents Each document may require its own metadata, validation rules, lifecycle information and business relationships. This is where Alfresco Content Modeling becomes important. Instead of treating every document simply as a file, Alfresco allows developers and architects to describe the business meaning of content using types, aspects, properties, constraints and associations. Alfresco Content Services stores content together with metadata and associations in its repository, while properties defined by content models can also participate in search. In this tutorial, we will explore: What an Alfresco content model is Custom namespaces Cust...

Une bonne modélisation de contenu Alfresco constitue l'une des bases d'une implémentation réussie d' Alfresco Content Services . Dans une entreprise, on ne gère généralement pas de simples fichiers. On gère de véritables objets métier : contrats ; factures ; documents RH ; politiques et procédures ; bons de commande ; documents techniques ; dossiers clients ; documents juridiques. Chacun de ces documents peut nécessiter ses propres métadonnées, règles de validation, informations de cycle de vie et relations métier. C'est précisément le rôle de la modélisation de contenu dans Alfresco . Au lieu de considérer chaque document comme un simple fichier, Alfresco permet de représenter sa signification métier grâce aux types, aspects, propriétés, contraintes et associations. Dans ce tutoriel, nous allons découvrir : ce qu'est un modèle de contenu Alfresco ; les espaces de noms ( namespaces ) ; les types personnalisés ( custom types ) ; les ...

 Apache Kafka often sits at the center of an enterprise event-driven architecture. Applications may publish and consume sensitive information such as customer events, payment transactions, order updates, audit events, operational telemetry and business data. A production Kafka platform therefore needs more than high throughput and fault tolerance. It also needs a clear security model. A practical Kafka security architecture should answer four fundamental questions: 1. Encryption — Can someone read Kafka traffic in transit? 2. Authentication — Who is connecting to Kafka? 3. Authorization — What is that identity allowed to do? 4. Governance — How is access controlled, reviewed, monitored and audited over time? Apache Kafka supports encrypted communication using SSL/TLS, client authentication using SSL or SASL, and authorization for operations performed against Kafka resources. Current Kafka documentation lists GSSAPI/Kerberos, PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEA...

 Apache Kafka occupe souvent une position centrale dans les architectures modernes orientées événements. Les applications peuvent publier et consommer des données sensibles telles que des événements clients, des transactions de paiement, des commandes, des événements d’audit, des données opérationnelles ou des informations métier. Un cluster Kafka de production doit donc offrir bien plus que de bonnes performances et une haute disponibilité. Il doit également disposer d’une architecture de sécurité robuste . Une stratégie de sécurité Kafka doit répondre à quatre questions fondamentales : 1. Chiffrement — Les données Kafka sont-elles protégées pendant leur transport ? 2. Authentification — Quelle application ou quel utilisateur se connecte à Kafka ? 3. Autorisation — À quelles ressources cette identité peut-elle accéder ? 4. Gouvernance — Comment les identités, droits d’accès, certificats et secrets sont-ils gérés et audités ? Apache Kafka prend en charge le chiffrement rés...