Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Menu
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Cerca
Chiudi

Nel numero:

117 aprile
, anno 2007

Jbi4Corba

Integrare CORBA con il Binding Component sviluppato dal GruppoImola

Marco Piraccini e Mirco Casoni

Marco Piraccini

Marco Piraccini è nato a Cesena il 09/10/1975. E‘ laureato in Ingegneria Informatica presso la facoltà di Bologna con una tesi sull‘assessment della maturità del processo di testing e
in Fisica Computazionale presso la facoltà di Udine con una tesi sull‘uso di GRID per le simulazioni Monte Carlo (nell‘ambito di un esperimento di astrofisica).
Attualmente lavora come Software Architect per una società di consulenza. Il suo Blog è disponibile al seguente indirizzo: http://darkav.blogspot.com/

Marco Piraccini e Mirco Casoni

Mirco Casoni

Appassionato di informatica da prima che arrivasse internet, progetta e organizza sistemi informativi di grandi aziende.
https://it.linkedin.com/in/mcasoni

MokaByte

Jbi4Corba

Integrare CORBA con il Binding Component sviluppato dal GruppoImola

Marco Piraccini e Mirco Casoni

Marco Piraccini e Mirco Casoni

  • Questo articolo parla di: Architetture dei sistemi, Java

Seguendo le specifiche JBI, è possibile sviluppare nuovi componenti di integrazione che possono poi essere installati in Enterprise Service Bus compatibili affinché funzionino come “ponti” tra il bus e le vecchie tecnologie di comunicazione. esaminiamo il componente Jbi4Corba, realizzato dal GruppoImola.

Grazie alla diffusa adozione dell‘architettura orientata ai servizi (Service Oriented Architecture), la specifica JBI sta prendendo sempre più piede nelle moderne tecnologie di intergrazione.
Seguendo le specifiche JBI, è possibile sviluppare nuovi componenti di integrazione che possono poi essere installati in Enterprise Service Bus compatibili affinchà© funzionino come “ponti” tra il BUS e le vecchie tecnologie di comunicazione.
Il GruppoImola ha sviluppato il componente Jbi4Corba, un Binding Component JBI open source che può essere utilizzato per connettere un ESB con un sistema CORBA.
GruppoImola contribuisce con questo componente al progetto open-jbi-components e diviene partner strategico di NetBeans. Per tali ragioni, il componente Jbi4Corba viene sviluppato e testato sulla piattaforma OpenESB ed è integrato in NetBeans Enterprise.
In questo articolo viene presentato il componente di collegamento Jbi4Corba, accompagnando tale presentazione con un caso d‘uso di integrazione realizzato con il nuovo NetBeans Enterprise di Sun Microsystem.

Integrazione ed Enterprise Service Bus

Ogni sistema complesso si evolve negli anni utilizzando tecnologie, standard e architetture differenti: tutto ciò ha dei costi in termini di integrazione. Gli scenari degli ultimi dieci anni nel mondo della Information Technology mostrano quanto tali costi possano essere elevati. SOA viene presentata come soluzione di questo problema: se si sviluppa un sistema prevendendo fin dall‘inizio l‘evoluzione e l‘integrazione, questa mentalità  ridurrà  al minimo i costi di integrazione e si garantirà  maggiore reattività  ai cambiamenti del modello di business.

Il middleware Enterprise Service Bus può essere adottato in SOA per integrare le tecnologie vecchie “ereditate” (legacy), con quelle nuove. perché l‘integrazione che usa un ESB è una buona idea?

Ogni volta che si adotta una nuova tecnologia, devono essere prese molte decisioni. Una di queste decisioni è “ha senso mantenere il vecchio software o è meglio sostituirlo con quello nuovo?”. Il software nuovo è probabilmente migliore, da un certo punto di vista (servizi migliori e costi più vantaggiosi) e può essere aperto a nuovi canali di comunicazione. D‘altro canto, il vecchio software ha un grosso vantaggio: funziona e rappresenta un bene economico comunque valido per l‘azienza e che l‘azienda ha già  pagato.

Per risolvere questo problema, una delle opzioni è “inglobare” (wrapping) il vecchio software, accedendo ad esso tramite uno strato di integrazione. Se questo layer di integrazione utilizza per la comunicazione degli standard open (come previsto da SOA), i costi di integrazione vengono ridotti. Inoltre, se questo strato è centralizzato (con un middleware di integrazione), non sono più necessarie delle connessioni punto a punto tra i processi che devono essere integrati: il risultato è un sistema meglio gestibile.

Questa impostazione architetturale può essere realizzata utilizzando gli ESB, ed è inoltre possibile farlo in maniera standardizzata grazie alla nuova specifica JBI (Java Business Integration).

Gli obiettivi principali dell‘Enterprise Service Bus sono:

  • disaccoppiamento e messaggistica utilizzando il BUS
  • condivisione, vendita e acquisto di componenti
  • la filosofia “configurare invece di scrivere codice” (Configure, don‘t code)

Vediamo questi aspetti in maggiore dettaglio.

Disaccoppiamento e messaggi usando il BUS

I componenti JBI non comunicano direttamente uno con l‘altro, ma è il BUS che ha il compito di consegnare i messaggi da un punto a un altro. Connettendo tutti i servizi con il BUS, questa architettura consente di evitare l‘integrazione punto a punto, che può condurre a sistemi complessi con alti costi di manutenzione.

I servizi possono essere implementati utilizzando tecnologie diverse, pertanto diventa possibile connettere il BUS alle nostre “vecchie” soluzioni, che si sono dimostrate valide e affidabilie nel corso degli anni.
Il ponte tra il mondo “esterno” e il BUS è rappresentato dai componenti JBI.

Per esempio, con Jbi4Corba è possibile esporre un servant CORBA all‘interno del bus, o esporre un servizio interno sotto forma di servant CORBA: il componente si incarica della comunicazione (trasformare la request CORBA in messaggi XML) e della pubblicazione del servizio sul BUS (ome definizione standard WSDL).

Condivisione, vendita e acquisto di componenti

L‘architettura ESB è basata su un modello “pluggable”, in cui cui le varie parti da aggiungere devono essere costruite seguendo le specifiche JBI. Questo significa che se si scrive un componente JBI, è possibile condividerlo, e tutti possono installarlo e usarlo in un ESB che aderisca alle specifiche JBI.
Ovviamente questa filosofia favorisce un mercato in cui è possibile trovare componenti di integrazione che facciano al caso nostro. Va anche detto che, dal momento che JBI è uno standard aperto, c‘è molto spazio per soluzioni open source.
Jbi4Corba è un progetto open source pertanto è possibile usarlo ed estenderlo senza particolari limitazioni.

La filosofia “configurare invece di scrivere codice”

ESB favorisce una filosofia della “configurazione piuttosto che la programmazione”, secondo la quale non dovrebbe essere necessaria la conoscenza di un linguaggio di programmazione per usare un componente, ma dobrebbero essere gestiti solamente i dati di configurazione. Il punto interessante è che i dati di configurazione possono essere facilmente gestiti per mezzo di appositi tool.

Per esempio, si può utilizzare il plugin per NetBeasn sviluppato dal GruppoImola per creare soluzioni di integrazione, usando il componente Jbi4Corba, senza alcuna conoscenza di programmazione.

Java Business Integration

Le specifiche JBI definiscono due tipi diversi di componenti adatti al deployment in un ESB: i Binding Components (BC) e i Service Engines (SE).
Mentre i Service Engine sono utili per contenere logica di integrazione pura, i Binding Components rappresentano la “connessione” tra il BUS e le applicazioni esterne.
Ovviamente, mentre dentro il bus viene usata una “lingua franca” (sostanzialmente, messaggi SOAP), fuori dal bus è presente una babele di differenti tecnologie di comunicazione. Questa è la ragione per cui la specifica JBI fornisce il concetto di Binding Component.

 

 

Fig. 1 – Architettura JBI.

 

Fondamentalmente, un BC può avere due funzioni:

  • Provider: dalla prospettiva del bus, si tratta di un componente che può essere usato da altri componenti per invocare un servizio.
  • Consumer: dalla prospettiva del bus, si tratta di un componente che può essere usato da un‘applicazione esterna, per invocare un servizio.

Quando viene ricevuto un messaggio proveniente da un servizio esterno, il compito del Binding Component sta nel normalizzarlo e inviarlo al receiver endpoint, ossia al destinatario (che può essere un Service Engine o un altro Binding Component), usando il Normalized Message Router (NMR).

Viceversa, quando il messaggio deve essere inviato al servizio esterno, esso deve essere “tradotto” dal formato NRM al formato esterno.

 

 

Fig. 2 – Normalizzazione dei messaggi da parte del Binding Component.

Secondo quanto previsto da JBI, il deploy delle soluzioni di integrazione deve avvenire in Service Assemblies (SA), composti usanto BC e SE configurati correttamente per creare un flusso di messaggi coerente all‘interno del BUS.
Le applicazioni sviluppate usando tali concetti sono dette composite (Composite Application).

Il componente Jbi4Corba

Con il supporto di Sun Microsystems, il GruppoImola ha sviluppato Jbi4Corba, un Binding Component open source.

Con questo componente è possibile integrare agevolmente i sistemi CORBA con qualsiasi altra applicazione, perché esso è in grado di gestire la comunicazione tra il bus e un servant o client CORBA esterni.

In effetti, abbiamo sviluppato un plugin per NetBeans che consente una integrazione completa del componente con OpenESB, ossia l‘Enterprise Service Bus open source sviluppato da Sun Microsystems.

Diamo un‘occhiata all‘interno del componente, per comprendere le sue caratteristiche principali e il modo in cui funziona.

Le caratteristiche principali del componente Jbi4Corba sono:

  • rilasciato sotto licenza LGPL v2.1
  • supporto per tipi CORBA primitivi e complessi
  • supporto per entrambe le modalità  consumer e provider
  • supporto per gli IDL contenenti definizioni di più interfacce
  • supporto per più implementazioni di ORB
  • supporto per comunicazioni sincrone (In-Out MEP)

Il componente può fungere da provider (esporre un servant CORBA sul BUS) o da consumer (esporre un service sul BUS come servant CORBA):

Modalità  Provider

Nel primo caso in esame, il componente viene configurato come provider.

 

Fig. 3 – Il componente Jbi4Corba (modalità  provider) e l‘ESB.

Si possono individuare 5 elementi:

  • un Servant CORBA
  • il nome del servizio CORBA
  • l‘ESB
  • il BC Jbi4Corba
  • un endpoint che effettua l‘invocazione del servizio

In questa confgurazione, l‘endpoint che invoca il servizio può inviare un messaggio normalizzato al BC: tale messaggio sarà  trasformato in una request CORBA. Il BC conosce lo specifico servant CORBA (look-up effettuata tramite il name server), pertanto può effettuare chiamate verso di esso. Il risultato della chiamata è normalizzato e inviato all‘endpoint che effettua l‘invocazione.

Durante questo “scambio”, il BC usa 3 informazioni definite quando il provider è stato configurato. Il nome del servant CORBA, lo host e la porta in cui si trova il nome del servizio.

 

 

Fig. 4 – Provider: scambi a runtime.

A questo punto una buona domanda potrebbe essere: “Dobbiamo scrivere un BC specifico per ogni servant CORBAA per “pubblicarlo” sul bus?”. Ovviamente la risposta è no.
Infatti, Jbi4Corba è scritto per un uso generale e per adattarlo a qualsiasi servant CORBA.
Secondo la filosofia “configure, don‘t code”, l‘unico compito a carico dell‘utente è di configurare il modo in cui il BC può individuare il servant, e di specificare il file IDL che rappresenta l‘interfaccia esposta

Modalità  Consumer

Jbi4Corba può anche fungere da consumer, esponendo un endpoint interno sotto forma di servant CORBA.

 

Fig. 5 – Il componente Jbi4Corba (modalità  consumer) e l‘ESB

Gli elementi sono sostanzialmente gli stessi della modalità  provider, ma alcuni di essi cambiano ruolo. Infatti, in questa situazione, il BC di Jbi4Corba deve creare un servant CORBA che possa essere invocato da parte di un Client CORBA esterno.

A runtime, un client CORBA invoca un metodo sul servant CORBA creato tramite il componente Jbi4Corba. La richiesta viene trasformata in un messaggio normalizzato, che è collocato sul bus e poi inviato all‘endpoint che lo deve ricevere.

 

 

Fig. 6 – Consumer: scambi a runtime.

 

In questa situazione, l‘utente deve conoscere solamente alcune informazioni di configurazione per poter effettuare correttamente il deploy di questo componente. Le informazioni, in questo caso, sono rappresentate dall‘interfaccia dell‘endpoint (espressa con WSDL). Questa interfaccia è convertita in interfaccia IDL che è poi registrata sul name server CORBA.

Scenario di integrazione

Per mostrare il modo in cui può essere usato il componente Jbi4Corba, possiamo immaginare un semplice scenario di integrazione. In questo esempio, dobbiamo integrare un semplice servant CORBA (che espone un servizio di saldo di conto corrente) in un processo BPEL. Pertanto dobbiamo configurare il Jbi4Corba in modalità  provider.

L‘interfaccia del servizio è definita usando un file IDL, dove si dichiara un metodo –getBalance()â?. Questo metodo accetta una stringa in input, che rappresenta il nome dell‘utente, e restituisce un numero double (compreso tra 0.00 e 100.00). Ecco di seguito il file IDL usato nell‘esempio:

module it {
	module imolinfo{
		module demo {
			interface BalanceService {
				double getBalance(in string user);
			};
		};
	};
};

Requisiti software

Ci servono alcuni strumenti open source:

NetBeans IDE 5.5.1

NetBeans Enterprise Pack 5.5.1

Jbi4Corba NetBeans plugin

Jbi4Corba Binding Component

Innanzitutto si installa l‘IDE NetBeans e il corrispondente Enterprise Pack. Poi si scompatta il plugin di NetBeans per Jbi4Corba appena scaricato dentro una directory temporanea: dovrebbero essere spacchettati alcuni file .nbm.

A questo punto si avvia NetBeans e si effettuano i seguenti passaggi:

  • dal menu Tools -> Update Center -> Install Manually Downloaded Modules (.nbm files) -> next
  • si selezionano i file .nbm spacchettati precedentemente -> next -> next
  • si accetta l‘accordo di licenza
  • si selezionano tutti i moduli e poi si clicca su finish

 

 

 

Fig. 7 – Installazione dei moduli Jbi4Corba per NetBeans

 

Creare il WSDL del servizio

Il primo passo sta nel creare un nuovo WSDL a partire dall‘interfaccia IDL di CORBA. Con tale WSDL, sarà  possibile aggiungere il servant come partner-link nel processo BPEL. Questa operazione è il compito principale svolto dal plugin Jbi4Corba di NetBeans.

In NetBeans, selezionare:

  • New Project -> Service Oriented Architecture -> BpelModule

 

NetBeans creerà  una cartella dove sarà  possibile aggiungere il file IDL.

 

 

Fig. 8 – Aggiunta del file IDL nel modulo BPEL.

Adesso, fare click con il tasto destro del mouse sul file IDL e selezionare –Create WSDLâ?.

 

 

Fig. 9 – Creare il WSDL dall‘interfaccia CORBA.

 

Dovrebbe apparire il wizard jbi4corba chiedendo di specificare alcuni dati di configurazione. Oltre alle informazioni necessarie per individuare il servant CORBA (le prorietà  ORB e il nome CORBA da ricercare), occorre specificare:

  • il nome dell‘endpoint (che sarà  usato per registrare il servizio all‘interno del BUS)
  • il namespace del servizio

 

 

Fig. 10 – Il wizard del plugin Jbi4Corba.

Realizzare il processo BPEL con NetBeans

Adesso si può realizzare un processo usando il nuovo editor BPEL di NetBeans. Il primo passo sta nel definire il WSDL per l‘intero processo. Poi, secondo quanto previsto da BPEL, deve essere creato il partner link per ciascun servizio coinvolto.
Il processo realizzato è molto semplice: viene ricevuto un messaggio che poi è usato per effettuare una chiamata al servant CORBA. Va notato che con NetBeans è possibile disegnare in maniera visuale tutto il processo, senza alcuna conoscenza dei linguaggi di programmazione.

 

 

 

Fig. 11 – Il processo BPEL

Creare una nuova Composite Application che include il modulo BPEL

Quando il progetto BPEL è protno, si deve creare il progetto CA (Composite Application). L‘applicazione composita includerà  un Binding Component SOAP (che viene aggiunto automaticamente da NetBeans), il processo BPEL appena creato e il Binding Component CORBA.

Una volta creato tale progetto, occorre seguire i seguenti passi:

  • click con il tasto destro sul nodo del progetto CA e scegliere “Add JBI module” (selezionando il modulo BPEL che abbiamo creato in precedenza)
  • click con il tasto destro sul nodo del progetto CA e scegliere “Build Project”
  • click con il tasto destro sul nodo del progetto CA project node e scegliere “Edit Project”

A questo punto, dovrebbe apparire l‘editor CASA (Composite Application Service Assembly).

 

 

Fig. 12 – L‘editor Composite Application Service Assembly (CASA) in NetBeans.

 

Avviare il Sun Java System Application Server ed effettuare il deploy della Composite Application

Adesso siamo pronti per effettuare il deploy della SA.
Innanzitutto occorre avviare il Sun Java System Application Server, nella maniera che segue:

  • aprire la finestra di runtime
  • aggiungere il “Sun Java System Application Server 9â?, se non è già  presente
  • fare click con il tasto destro sul server e avviarlo

 

 

Fig. 13 – Avvio del Sun Java System Application Server

Installare il componente jbi4corba

Per effettuare il depoloy della Composite Application, il componente Jbi4Corba deve essere installato su OpenESB. Occorre seguire i seguenti passaggi:

  • se il server non è già  in funzione, avviarlo
  • aprire la sottodirectory “JBI” del server, fare click con il tasto destro su “Binding Components” e selezionare “Install New Binding Component”
  • selezionare l‘installer di Jbi4Corba scaricato precedentemente (jbi4corba-0.2-installer.zip)
  • adesso apparirà  il componente Jbi4corba. Fare click con il tasto destro su di esso e selezionare “Start”.

 

 

Fig. 14 – Installazione del componente Jbi4Corba.

 

Avviare il name server e il servant CORBA

Prima che si possa effettuare il deploy della Service Assembly, deve essere avviato un name server CORBA. Per esempio, si può avviare il Java runtime ORB, utilizzando:

orbd -ORBInitialPort 1049 -ORBInitialHost localhost

Fatto questo, il servant CORBA si può avviare e registrare sul name server.

Effettuare il deploy della Composite Application

Finalmente si è pronti per il deploy! A questo punto basta fare click con il tasto destro sul progetto Composite Application e scegliere “Deploy Project”. Per vedere sul sever la SA di cui si è appena fatto il deploy, fare click con il tasto destro sulla sottocartella “Service Assemblies” e selezionare “refresh”.

 

 

Fig. 15 – La Composite Application avviata correttamente.

Test del servizio

È possibile usare la funzionalità  di test di NetBeans per effettuare un test diretto della Composite Application con messaggi SOAP.

 

 

Fig. 16 – Test della Composite Application.

 

Roadmap

Jbi4Corba è già  un buon Binding Component, ma lo sviluppo continua.
GruppoImola e Sun Microsystems hanno definito un‘interessante roadmap per le prossime release:

release 0.5

  • più meccanismi di individuazione (corbaloc/corbaname, IOR)
  • comunicazione asincrone (InOnly MEP)
  • supporto per parametri InOut
  • supporto per più tipi di IDL
  • supporto per più tipi di WSDL

release 1.0

  • supporto per caratteristiche di sicurezza avanzate
  • supporto per la gestione delle transazioni
  • support per caratteristiche di gestione avanzate

 

Conclusioni

L‘avvento di SOA e dei Web Service sta spingendo le aziende a riorganizzare il loro portfolio di software sotto forma di servizi riutilizzabili. In questa riorganizzazione, il software viene di solito “inglobato” con il wrapping per salvaguardare gli asset dell‘azienda, e poi viene esposto sotto forma di servizio usando un Enterprise Service Bus.
Ci sono alcune aree business (per esempio nelle infrastrutture delle aziende telefoniche) in cui tali asset sono rappresentati in gran parte da sistemi CORBA: in tali scenari il componente Jbi4Corba component può risultare utile.
Infatti, tramite il componente Jbi4Corba, è possibile consentire l‘integrazione di CORBA in un ambiente ESB in due maniere:

  • Pubblicare un servant CORBA sul bus, dove può esere invocato da qualunque altro software connesso.
  • Esporre, sotto forma di servant CORBA, tutto il software connesso al bus.

 

Riferimenti

Gruppo Imola
http://www.imolinfo.it/index_en.php
http://gruppoimola.wordpress.com/

Jbi4Corba
http://www.glassfishwiki.org/jbiwiki/Wiki.jsp?page=CORBABC

NetBeans
http://www.netbeans.org/

OpenESB
https://open-esb.dev.java.net/

JBI
http://jcp.org/en/jsr/detail?id=208

 

Facebook
Twitter
LinkedIn
Marco Piraccini e Mirco Casoni

Marco Piraccini

Marco Piraccini è nato a Cesena il 09/10/1975. E‘ laureato in Ingegneria Informatica presso la facoltà di Bologna con una tesi sull‘assessment della maturità del processo di testing e
in Fisica Computazionale presso la facoltà di Udine con una tesi sull‘uso di GRID per le simulazioni Monte Carlo (nell‘ambito di un esperimento di astrofisica).
Attualmente lavora come Software Architect per una società di consulenza. Il suo Blog è disponibile al seguente indirizzo: http://darkav.blogspot.com/

Marco Piraccini e Mirco Casoni

Mirco Casoni

Appassionato di informatica da prima che arrivasse internet, progetta e organizza sistemi informativi di grandi aziende.
https://it.linkedin.com/in/mcasoni

Marco Piraccini e Mirco Casoni

Marco Piraccini e Mirco Casoni

Tutti gli articoli
Nello stesso numero
Loading...

Il web 2.0

I parte: principi e tecnologie, una visione introduttiva

Realizzare applicazioni Bluetooth in Java

II parte: Il discovery dei servizi e il protocollo OBEX per il trasferimento dei file

Maven: Best practice applicate al processo di build e rilascio di progetti Java

III parte: POM.xml, un componente centrale

Portlet API

I parte: costruire portali con le portlet

Spring e integrazione

I parte: Integrazione con altri framework

Weka: l‘approccio intelligente all‘esplorazione dei dati

II parte: preprocessamento e classificazione

Flex 2 e Java per sviluppare Rich Internet Application

I parte: introduzione e panoramica

JSF: Il nuovo volto dello sviluppo web

I Parte: Introduzione

Intervista a G.Tummarello

Domande e risposte su semantic web

Nella stessa serie
Loading...

Jbi4Cics

Integrare CICS con il Binding Component sviluppato dal Gruppo Imola

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte