Il presente articolo è stato tradotto automaticamente.

Interoperabilità

Condivisione dei dati di runtime tramite una cache distribuita aziendale

Iqbal Khan

Molte organizzazioni utilizzano una combinazione di applicazioni Microsoft .NET Framework e Java, soprattutto medie a grandi organizzazioni Impossibile eseguire il commit di sola tecnologia per diversi motivi. Spesso, utilizzare le applicazioni Web, servizi Web architettura orientata ai servizi (SOA) e altre applicazioni server che elaborano grandi quantità di transazioni.

Molte applicazioni devono condividere dati con un altro in fase di esecuzione. Spesso, sono tutti lavora sui dati aziendali comuni memorizzati in un database. Sono in genere gestiscono continui flussi di dati (ad esempio finanziari commerciali applicazioni) e necessarie per elaborare e condividere i risultati con altre applicazioni nuovamente tutti in fase di esecuzione.

Il database deve essere l'archivio dati principale per l'archiviazione permanente, ma non sono adatti per la condivisione dei dati di runtime. Un motivo è che le prestazioni non sempre grande durante la lettura dei dati dal database. Inoltre, il database non può essere scala bene in termini di gestione delle transazioni, in modo che può diventare un collo di bottiglia rapidamente e rallentare tutte le applicazioni che si basano su di esso.

Inoltre, non è possibile condividere in modo efficace i dati in tempo reale. Condivisione dei dati in tempo reale richiede come un'applicazione aggiorna alcuni dati, tutte le applicazioni interessate in quanto i dati devono essere informati. Analogamente, alcune applicazioni potrebbero essere in attesa per determinati tipi di dati creati e renderli disponibili e quando questo accade, dovrebbero essere informati immediatamente.

Questi problemi sono comuni se le applicazioni che devono condividere dati si basano su .NET Framework o se alcuni sono .NET e altri Java. Infatti, se le applicazioni sono una combinazione di .NET e Java, i problemi vengono capitalizzati perché non esiste un metodo automatico per le applicazioni di condividere dati a livello di applicazione per l'applicazione in modo nativo.

Soluzione: Enterprise distribuiti nella cache

Per fortuna, la cache aziendali distribuiti può risolvere questi problemi. Questo archivio in memoria si estende su più server, il pool di memoria del server in modo che la capacità di memoria è scalabile. Capacità di transazione diventa inoltre scalabili, in modo che più server aggiunto, il maggiore carico di transazione è possibile gestire.

Cache distribuita Enterprise inoltre forniscono meccanismi di notifica eventi, consentendo alle applicazioni di un altro avviso quando i dati sono aggiornati. Pertanto, è possibile avere un meccanismo di notifica eventi asincrone in cui un'applicazione genera alcuni dati e altri utenti possono utilizzare, creare un modello di relazione producer/consumer o un modello di pubblicazione/sottoscrizione. Più applicazioni sottoscrivere determinati tipi di dati e una notifica quando viene pubblicato.

È inoltre disponibile un meccanismo read-through/write-through, ovvero che la cache di aziendali distribuiti di leggere i dati considerevole l'origine dati e le applicazioni. Indipendentemente se tali applicazioni sono Java o. NET, il codice diventa molto più semplice poiché vengono letti i dati dalla cache aziendali distribuiti. Non devono disporre di tutti i database di codice di accesso incorporate. Vedere Figura 1 per un esempio semplice di un'applicazione .NET Framework utilizzando una cache aziendali distribuiti.

Figura 1 di applicazioni .NET con un'organizzazione distribuita cache

using System;
...
using Alachisoft.NCache.Web.Caching;

namespace Client
{
  class Program
  {
    static string _sCacheName = "myAppCache";
    static Cache _sCache = NCache.InitializeCache(_sCacheName);

    static void Main(string[] args)
    {
      string employeeId = "1000";
      string key = "Employee:EmployeeId:" + employeeId;
            
      // First check the cache for this employee
      Employee emp = _sCache.Get(key);

      // If cache doesn't have it then make database call
      if (emp == null)
      {
        emp = LoadEmployeeFromDb(employeeId);

        // Now add it to the cache for next time
        _sCache.Insert(key, emp);
      }
    }
  }
}

Inoltre, una cache aziendali distribuiti possibile sincronizzare automaticamente con le modifiche ai dati del database da altre applicazioni di terze parti. Dispone di una connessione con il database, consentendo il database di notifica ogni volta che un determinato tipo di modifiche nel database. Figura 2 viene illustrato come le applicazioni .NET e Java possono condividere dati con un altro in fase di esecuzione tramite una cache aziendali distribuiti.

image: .NET and Java Apps Sharing Data Through a Distributed Cache

Figura 2 .NET e applicazioni Java condivisione dei dati tramite una cache distribuita

.NET e applicazioni Java condivisione dati

Con un'azienda distribuiti nella cache più applicazioni, .NET e Java, possono accedere gli stessi dati della cache e condivisione attraverso di esso. Se fosse solo applicazioni .NET (o solo le applicazioni Java) condividere dati attraverso una cache distribuita potrebbe memorizzare gli oggetti in un formato binario nativo e serializzare o deserializzare tali. Ma quando si tentano di entrambi i tipi di condividere i dati tra loro, un formato di dati portabili in cui memorizzare i dati nella cache distribuita.

Ecco perché quando un oggetto di un'applicazione .NET viene memorizzato nella cache distribuita, effettivamente trasforma l'oggetto in un documento XML e contiene codice XML. Da altro lato, quando un'applicazione Java legge i dati dalla cache distribuita trasforma il XML in un oggetto Java. In effetti, il XML viene utilizzato come meccanismo di archiviazione di dati portabili come un oggetto .NET viene trasformato in XML e da XML in Java e viceversa.

Una serie di librerie open source consentono di trasformare gli oggetti .NET o Java in XML e quindi nuovamente nel modulo di oggetto. È possibile sviluppare il proprio, naturalmente, ma è consigliabile che scegliere una libreria open source. Personalmente come oggetti Web WOX (XML), sviluppato da Carlos Jaimez e Simon Lucas (woxserializer.sourceforge.net ). Esempi di trasformazione Java a .NET dal sito Web si utilizzerà in questo articolo (con le autorizzazioni). Figura 3 Mostra Student e Course classi definite sia in Java e C#.

Figura 3 Student e Course classi in Java e C#

// Java classes
public class Student
{
  private String name;
  private int registrationNumber;
  private Course[] courses;
}
public class Course
{
  private int code;
  private String name;
  private int term;
}

// ***************************************************
// .NET classes in C#
public class Student
{
  private String name;
  private Int32 registrationNumber;
  private Course[] courses;
}
public class Course
{
  private Int32 code;
  private String name;
  private Int32 term;
}

Se utilizziamo le applicazioni .NET e Java per memorizzare gli oggetti Student e Course in una cache aziendali distribuiti, possiamo quindi utilizzare la libreria WOX relativa trasformazione in XML. Quindi, quando un'applicazione deve leggere tali oggetti dalla cache aziendali distribuiti, legge la libreria WOX per trasformare il codice XML nel modulo di oggetto Java o. NET. Figura 4 Mostra classi Student e Course trasformate in XML.

Figura 4 Java e classi .NET trasformate in XML

<object type="Student" id="0">
  <field name="name" type="string" value="Carlos Jaimez"/>
  <field name="registrationNumber" type="int" value="76453"/>
  <field name="courses">
    <object type="array" elementType="Course" length="3" id="1">
      <object type="Course" id="2">
        <field name="code" type="int" value="6756"/>
        <field name="name" type="string" 
          value="XML and Related Technologies"/>
        <field name="term" type="int" value="2"/>
      </object>
      <object type="Course" id="3">
        <field name="code" type="int" value="9865"/>
        <field name="name" type="string" 
          value="Object Oriented Programming"/>
        <field name="term" type="int" value="2"/>
      </object>
      <object type="Course" id="4">
        <field name="code" type="int" value="1134"/>
        <field name="name" type="string" value="E-Commerce Programming"/>
        <field name="term" type="int" value="3"/>
      </object>
    </object>
  </field>
</object>

All'interno dell'applicazione, è necessario chiamare WOX il livello di cache o il livello di accesso ai dati.

Notifiche di eventi basati su elemento

Le notifiche degli eventi sono un potente meccanismo che consente a più applicazioni, .NET e Java, per coordinare in modo asincrono la condivisione dei dati. Questo meccanismo consente di evitare il polling del database applicazioni avrebbe se non dispongono di tali funzionalità costoso. È condiviso fra le applicazioni .NET e Java, in modo che può notificare un altro senza problemi.

Un tipo comune di notifica degli eventi è basata sull'elemento notifica. In questo tipo di applicazioni registrano interesse nelle varie chiavi elemento memorizzato nella cache (che possono o non esiste ancora nella cache) e sta notifica separatamente ogni volta che tale elemento viene aggiunto, aggiornato o rimosso dalla cache distribuita da chiunque per qualsiasi motivo. Ad esempio, anche se un elemento viene rimosso a causa di scadenza o eliminazione, la notifica di eventi Rimuovi elemento viene attivata.

Le applicazioni .NET e Java possono registrare l'interesse per gli stessi articoli nella cache e notifiche riguardo. La notifica include in genere interessato elemento della cache, che, come si è visto nella sezione precedente viene trasformato in .NET o Java, a seconda del tipo di applicazione.

Notifiche di eventi personalizzati generati da applicazioni

Una cache aziendale distribuita è anche una piattaforma di propagazione evento potente per le applicazioni .NET e Java. Le applicazioni connesse a una cache aziendali distribuiti possono generare eventi personalizzati nella cache e quindi tutte le altre applicazioni che hanno registrato un interesse per gli eventi personalizzati vengono avvisati dalla cache, indipendentemente da dove si trovano tali applicazioni. Di per sé fornisce un meccanismo di propagazione evento potente linguaggio e indipendente dalla piattaforma in una cache aziendali distribuiti.

Questa funzionalità consente alle applicazioni di collaborare in modo asincrono la condivisione dei dati. Ad esempio, se un'applicazione inserisce alcuni dati nella cache distribuita, può quindi generato un evento personalizzato in modo da altre applicazioni che dovrebbero utilizzare o elaborare ulteriormente tali dati vengono informati immediatamente.

Notifiche di eventi basati su query continua

Notifica eventi basati su elemento potente ma richiede l'applicazione per conoscere la chiave dell'elemento memorizzato nella cache. Se si combinazione la notifica degli eventi basate sull'articolo con altre funzionalità di raggruppamento comunemente fornito in una cache aziendali distribuiti (ad esempio tag, gruppi o sottogruppi e altro ancora), è possibile gestire la maggior parte dei casi in cui le applicazioni devono essere informati praticamente basata su ciò che accade ai vari elementi nella cache.

Tuttavia, esistono due limitazioni con eventi di elemento. Innanzitutto, come indicato, l'applicazione deve conoscere tutte le chiavi degli elementi memorizzati nella cache che si desidera essere avvisati. In secondo luogo, verrà notificato indipendentemente dalla quale viene modificato a questi elementi. L'applicazione non è attivato criteri più dettagliati, in modo che riceve una notifica solo quando vengono apportate modifiche specifiche per i dati.

Per gestire questi casi, una cache aziendali distribuiti fornisce una query continua, ovvero una query di tipo SQL acquisisce le regole business dell'applicazione sui dati in cui è interessato. Una query continua non è una query di ricerca, ma piuttosto un “ criteri ” mantiene la cache aziendali distribuiti;ogni volta che un elemento viene aggiunto o aggiornato nella cache distribuita, l'operazione viene confrontato con i criteri di query continua. Se i criteri di corrispondono, viene generato un evento e viene notificato l'applicazione emette i criteri della query continua.

Query continua consente alle applicazioni di controllo delle modifiche più sofisticate e complesse e notifica solo quando si verificano tali modifiche.

Read-Through e gestori write-through

Molte volte, applicazioni tentano di leggere dati non esistono nell'organizzazione distribuiti nella cache e devono essere letto da un database. In questi casi, potrebbero andare direttamente al database e leggere i dati delle applicazioni, ma che implica che tutte le applicazioni finiscono con lo stesso codice di accesso ai dati duplicato (soprattutto in .NET e Java). In alternativa, è possibile chiedere cache aziendale distribuita per leggere i dati dal database per loro quando sono necessari.

La funzione read-through/write-through consente una cache aziendale distribuita leggere i dati direttamente dall'origine dati. Le applicazioni consentono di semplificare il codice non dispongono di accedere al database. È solo possibile richiesto cache aziendale distribuita per fornire i dati e se la cache non contiene dati, consente di passare e leggere dall'origine dati. Figura 5 Mostra come read-through e adattamento write-through in un'organizzazione distribuita nella cache.

image: How Read-Through/Write-Through Is Used

Figura 5 come Read-Through/write-through utilizzato

Desidero citare un punto di attenzione qui. Anche se è presente un grande vantaggio in presenza della cache distribuita leggere i dati dal database per l'utente, molti tipi di dati più vengono letti direttamente dal database dall'applicazione. Se si stanno leggendo gli insiemi di dati che coinvolgono i join complessi, si consiglia di leggere qualsiasi e quindi inserirlo nella cache distribuita.

Sincronizzazione database

Poiché una grande quantità di dati è da inserire nella cache aziendale distribuita, è solo logico per assicurarsi che i dati viene mantenuti sincronizzati con l'origine dati principale, in genere un database relazionale. Una cache aziendale distribuita offre tale funzionalità.

Questa funzionalità di sincronizzazione database consente alle applicazioni di specificare una relazione (dipendenza) tra gli elementi memorizzati nella cache e righe nelle tabelle del database. Ogni modifica dei dati nel database, il server di database genera un evento .NET se è un database di SQL Server 2005 o 2008 e notifica cache aziendali distribuiti di tale modifica. Per gli altri database non supportano gli eventi .NET, una cache aziendali distribuiti fornisce inoltre polling configurabile, in cui può eseguire il polling del database (ad esempio, ogni 15 secondi) e sincronizzazione se i dati vengono modificati presenti.

Cache distribuita e rimuove i dati dalla cache o legge una copia aggiornata se la funzionalità read-through è stata configurata. Figura 6 viene illustrata la modalità di sincronizzazione della cache un'organizzazione distribuita con SQL Server.

image: Database Synchronization in Distributed Cache

Figura 6 di sincronizzazione del database nella cache distribuita

Disponibilità elevata: Cluster Dynamic self-Healing

Viene utilizzata una cache aziendali distribuite come una piattaforma tra più applicazioni (.NET per. NET, .NET e Java e Java per Java) di condivisione dati di runtime. In molti casi, queste applicazioni sono essenziali per l'azienda.

Ciò significa che una cache aziendale distribuita deve essere altamente disponibile, poiché dipendono molte applicazioni mission-critical. Cache aziendali distribuiti non può scendere o interrompersi e non necessario praticamente nessun tempo di inattività per manutenzione o altre operazioni normali.

Una cache aziendali distribuiti ha raggiunto un'elevata disponibilità dalla presenza di un cluster di server cache dinamico, riparazione automatica. Self-healing qui, significa che è a conoscenza di tutti i membri del cluster e viene modificata in modo dinamico se un membro lascia o join. Assicura inoltre che i dati vengono replicati per affidabilità e se un membro del cluster, i backup dei dati viene resa disponibili per le applicazioni automaticamente. Tutto questo deve essere eseguito rapidamente e senza provocare eventuali interruzioni delle applicazioni tramite l'organizzazione di cache distribuita.

Scalabilità: Partizionamento di cache e replica

Molte applicazioni utilizzano una cache aziendali distribuiti sono applicazioni di transazione elevati. Di conseguenza, il carico sul cluster cache può aumentare rapidamente;Tuttavia, se il tempo di risposta dell'azienda distribuiti cache rilasci, perde il valore. In realtà, questa è un'area in cui una cache aziendali distribuiti è superiore a database relazionali;è possibile gestire molte più transazioni al secondo perché può continuare ad aggiungere più server al cluster dinamico. Ma non è possibile ottenere scalabilità, a meno che i dati nella cache distribuita viene memorizzati in modo intelligente. Questa operazione viene eseguita mediante il partizionamento dei dati, con ogni partizione replicato l'affidabilità.

Grazie alla cache aziendali distribuiti si può sfruttare i vantaggi di una topologia partizionato per la scalabilità. Figura 7 è illustrata una topologia di replica partizionati.

image: Partitioned-Replication Topology for Reliable Scalability

Figura 7 di topologia di replica partizionata per scalabilità affidabile

Una cache aziendali distribuiti automaticamente le partizioni di tutti i dati da memorizzare nella cache. Ogni partizione è memorizzato in un server diverso e un backup per questa partizione viene creato e memorizzato in un altro server. In questo modo, se un server viene interrotto, i dati non vengono persi.

In questo modo, in breve, il partizionamento consente di continuare ad aggiungere ulteriori server di cache al cluster per aumentare la capacità di archiviazione dinamica e aumenta la capacità di transazioni al secondo anche se si aggiungono più server. E replica garantisce l'affidabilità dei dati perché si verifica alcuna perdita di dati se un server si blocca.

In grado e collaborazione

Il wrapping una cache aziendale distribuita è ideale per le applicazioni .NET e Java transazione elevata condividere i dati con altre applicazioni. Assicura che la condivisione dei dati viene eseguita in tempo reale a causa dei relativi meccanismi di propagazione evento potente, tra cui notifica eventi basati su articolo, le notifiche di eventi personalizzati generati dall'applicazione e notifiche di eventi basati su query continua.

Una cache aziendale distribuita è molto veloce e scalabile per impostazione predefinita. È veloce perché è in memoria. È scalabile quanto può crescere in più server. Spazio di archiviazione effettivo di partizioni e ogni partizione viene memorizzato su un server diverso e archivia una copia di backup della partizione in un altro server, quale un disco RAID.

Le applicazioni odierne devono essere molto maggiore capacità rispetto in passato. È necessario lavorare in maniera più collaborativa di condividere dati e interagire tra loro. Devono essere estremamente veloci durante soddisfare le esigenze dei carichi molto elevati per evitare di compromettere le prestazioni e la scalabilità. Devono inoltre eseguire tra piattaforme diverse applicazioni .NET possono funzionare efficacemente e in modo trasparente con applicazioni Java. Una cache aziendale distribuita consente di raggiungere tutti questi obiettivi.

Iqbal Khan è evangelist presidente e tecnologia di Alachisoft ( alachisoft.com ), che fornisce NCache, una cache distribuita .NET per migliorare prestazioni e scalabilità di applicazioni enterprise. Khan ricevuto un grado di ’s master in informatica presso la Indiana University nel 1990. È possibile contattarlo all'indirizzo iqbal@alachisoft.com.

Grazie all'esperto di tecnica seguente per la revisione di questo articolo: Stefan Schackow