La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

ARCHITETTURE Architetture N-Tier COM (Component Object Model) e DCOM (Distributed COM) SOA (Service Oriented Architecture) Enterprise Java Beans Microsoft.NET.

Presentazioni simili


Presentazione sul tema: "ARCHITETTURE Architetture N-Tier COM (Component Object Model) e DCOM (Distributed COM) SOA (Service Oriented Architecture) Enterprise Java Beans Microsoft.NET."— Transcript della presentazione:

1

2 ARCHITETTURE Architetture N-Tier COM (Component Object Model) e DCOM (Distributed COM) SOA (Service Oriented Architecture) Enterprise Java Beans Microsoft.NET Web Services

3 Applicazioni Web-based e non Elementi di base di un’applicazione I dati da trattare (dati sugli utenti, sul servizio offerto, etc.) Logica applicativa (business logic), ovvero le funzionalità che l’applicazione deve offrire, il tipo di trattamento dei dati previsto (quali operazioni si possono fare), etc. Interfaccia utente –interfaccia web (e.g., per browser, o testuale) –stand-alone (applicazione locale alla macchina su cui gira)

4 Architetture delle applicazioni Monoliti Client/server (two-tier) Three-tier N-tier

5 Monoliti (IT stovepipe) - I Popolari ai tempi dei mainframe Monoliti: –pezzi di codice indivisibili –controllavano l’intera logica dell’applicazione, dalla gestione (e memorizzazione) dei dati, fino all’interfaccia utente –gestivano applicazioni stand-alone Popolarità dovuta a: –mainframe adatti ad eseguire pochi processi stand-alone, anzichè diversi processi comunicanti –non c’erano ancora i database

6 Monoliti (IT stovepipe) - II Enterprise User interface Logic Data Management

7 Architetture client/server - I Dalla fine degli anni ‘70 alla metà degli anni ‘80 –Diffusione di server più piccoli ed economici dei mainframe, e di workstations e PC –Diffusione di RDBMS Suddivisione delle applicazioni in due parti: –backend (server): gestione di database (+ o – complessi) e dei compiti di manipolazione dei dati –frontend (client): gestione interfaccia utente  maggiore scalabilità, rispetto a monoliti (carico computazionale distrbuito sui client)  sviluppo più veloce di applicazioni che accedono agli (stessi) dati

8 Architetture client/server - III Enterprise User interface Logic Data Management Client Server

9 Architetture client/server - II Svantaggi: Traffico di messaggi intenso (frontend comunica continuamente con server dati) Logica di business non gestita in componente separata dell’architettura: suddivisa tra frontend e backend  client e server di applicazione dipendono l’uno dall’altro –difficile riutilizzare interfaccia in servizio che accede a dati diversi –difficile utilizzare DB da frontend diversi –tendenza a cablare la business logic nell’interfaccia utente  cambio di logica significa cambiare anche interfaccia

10 Architetture client/server - IV Problema: mancato riconoscimento dell’importanza della business logic –Es: servizio accessibile da più device (telefonino, desktop)  stessa logica, interfaccia diversa Enterprise User interface Logic Data Management Client Nuovo Client Server Adapter

11 Architetture three-tier - I Introdotte all’inizio degli anni ‘90 Business logic trattata in modo esplicito: –livello 1: gestione dei dati (DBMS, file XML, …..) –livello 2: business logic (processamento dati, …) –livello 3: interfaccia utente (presentazione dati, servizi) Ogni livello ha obiettivi e vincoli di design propri Nessun livello fa assunzioni sulla struttura o implementazione degli altri: –livello 2 non fa assunzioni su rappresentazione dei dati, né sull’implementazione dell’interfaccia utente –livello 3 non fa assunzioni su come opera la business logic..

12 Architetture three-tier - II Non c’è comunicazione diretta tra livello 1 e livello 3 –Interfaccia utente non riceve, né inserisce direttamente dati nel livello di data management –Tutti i passaggi di informazione nei due sensi vengono filtrati dalla business logic I livelli operano senza assumere di essere parte di una specifica applicazione –  applicazioni viste come collezioni di componenti cooperanti –  ogni componente può essere contemporaneamente parte di applicazioni diverse (e.g., database, o componente logica di configurazione di oggetti complessi)

13 Architetture three-tier - III Business Rules Enterprise User interface Presentation layer Logic Business layer Data Management Data layer Data Service Data Service Data Service Business Rules Business Rules Motif Client Windows Client Telephony Client Mac Client

14 Architetture three-tier - IV User Interface Application Logic DB XML Documents Data providers Service provider Service consumer Directory service

15 Vantaggi di architetture three-tier - I Flessibilità e modificabilità di sistemi formati da componenti separate –componenti utilizzabili in sistemi diversi –modifica di una componente non impatta sul resto del sistema (a meno di cambiamenti negli API) –ricerca di bug più focalizzata (separazione ed isolamento delle funzionalità del sistema) –aggiunta di funzionalità all’applicazione implica estensione delle sole componenti coinvolte (o aggiunta di nuove componenti)

16 Vantaggi di architetture three-tier - II Interconnettività –API delle componenti superano il problema degli adattatori del modello client server  N interfacce diverse possono essere connesse allo stesso servizio etc. – Facilitato l’accesso a dati comuni da parte di applicazioni diverse (uso dello stesso gestore dei dati da parte di business logics diverse) Gestione di sistemi distribuiti –Business logic di applicazioni distribuite (e.g., sistemi informativi con alcuni server replicati e client remoti) aggiornabile senza richiedere aggiornamento dei client –Aggiornamento dei client comunque costoso

17 Vantaggi di architetture three-tier - III Applicazioni distribuite geograficamente –Data server centrale –Business logic gestita da server logici regionali –Client remoti (ev. con business logic per maggior scalabilità) Per ridurre traffico di rete e latency del servizio, anche il data server centrale può essere replicato (ma, gestione consistenza dati)

18 Svantaggi di architetture three-tier - I Dimensioni delle applicazioni ed efficienza –Pesante uso della comunicazione in rete  latenza del servizio –Comunicazione tra componenti richiede uso di librerie SW per scambio di informazioni  codice voluminoso Legacy software –Molte imprese usano software vecchio (basato su modello monolitico) per gestire i propri dati  difficile applicare il modello three-tier per nuove applicazioni introduzione di adapters per interfacciare il legacy SW

19 Three-tier è concettuale, non fisico Si possono implementare architetture three-tier su due livelli di macchine, o anche su uno solo... Data and Logic Server Clients User Interface User Interface Data Components Logic Rules

20 Architetture n-Tier - I Permettono configurazioni diverse. Elementi fondamentali: Interfaccia utente (UI) –gestisce interazione con utente –può essere un web browser, WAP minibrowser, interfaccia grafica, … Presentation logic –definisce cosa UI presenta e come gestire le richieste utente Business logic –gestisce regole di business dell’applicazione

21 Architetture n-Tier - II Infrastructure services –forniscono funzionalità supplementari alle componenti dell’applicazione (messaging, supporto alle transazioni, …) Data layer: –livello dei dati dell’applicazione

22 Architetture n-Tier - III Browser DB XML Documents Presentation Logic Business Logic Services Application client Firewall

23 Applicazione Web-based tipica - I Interfaccia utente: gestita sul browser utente Logica applicativa: gestita sul server, che si interfaccia al web attraverso Web Server Livello dei dati: su database, eventualmente localizzato su macchina diversa da quella del Web Server, per questioni di sicurezza Web Server Business logic Browser utente HTTP

24 Applicazione Web-based tipica - II Richiesta di pagina HTML statica (pagina HTML memorizzata nel file system dell’applicazione – il codice della pagina non viene generato eseguendo programmi applicativi sul server) Web Server Local File System /htdocs/hello.html Request: Response: HTML code Browser utente

25 Applicazione Web-based tipica - III Richiesta di pagina dinamica (pagina HTML generata dinamicamente, sulla base della richiesta del client – codice della pagina generato eseguendo programmi applicativi sul server) Web Server Business logic Request: Response: pagina HTML di risposta, con eventuali link e bottoni per continuare interazione Browser utente

26 Browser Web Può essere visto come interfaccia utente universale –Invoca Web Server per richiedere pagine statiche o dinamiche –Riceve contenuti web da Web Server invocato e li presenta sulla macchina dell’utente Browser moderni (MS Explorer, Netscape Navigator, …) interpretano codice HTML Alcuni browser interpretano codice XML –Può eseguire script (e.g., javascript) localmente, per effettuare semplici computazioni (e.g., controllo correttezza input utente) –Può scaricare plug-in da Web Server per eseguire programmi localmente (e.g., animazioni Flash o altro)

27 Web Server Programma che –gira su una macchina server accessibile da internet –resta in ascolto di richieste (da parte di client web) su porta HTTP. E.g., –gestisce le richieste che arrivano (recupera pagina html richiesta, esegue programmi, invoca programmi associati a servizi richiesti, etc.) –restituisce a client una risposta (risultato della richiesta, messaggio di errore)

28 La Piattaforma J2EE J2SE: Java 2 Platform, Standard Edition. –Ambiente runtime per esecuzione di applicazioni Java e insieme di API (Application Programming Interface) per sviluppare applicazioni di vario tipo (applets, applicazioni stand-alone, …) J2EE: Java 2 Platform, Enterprise Edition: –framework per lo sviluppo di applicazioni server-side complesse J2ME: Java 2 Platform, Micro Edition: –framework per lo sviluppo di applicazioni su micro device (PDA, telefonini Java-enabled, etc.)

29 Proprietà J2EE: adatta allo sviluppo di applicazioni Web-based a livello di impresa, e.g., per commercio elettronico Il suo competitor è Microsoft.net Impresa (enterprise): organizzazione di business Enterprise software applications: applicazioni SW che facilitano la gestione delle attività di impresa –interagire con clienti e partners via Internet –facilitare l’interazione tra le varie parti di un’impresa, eventualmente distribuite geograficamente –gestione del business: resource planning, gestione inventari,...

30 Caratteristiche di applicazioni “enterprise” Necessità informative: spesso le stesse informazioni sono utilizzate sotto forma diversa dai consumatori  attività di business diverse processano le stesse informazioni, ma utilizzando formati diversi Complessità dei processi di business: necessità di raccogliere, gestire e condividere informazioni, basandosi su una logica complessa Eterogeneità delle applicazioni: un’impresa utilizza molte applicazioni basate su architetture e tecnologie diverse (legacy software)

31 Requisiti di gestione del software d’impresa Velocizzazione del processo di sviluppo delle applicazioni: cambiano gli standard, le tecnologie, le applicazioni devono entrare in uso velocemente Affidabilità e disponibilità: il SW deve essere sempre accessibile (Web) ed essere affidabile (e.g., transazioni) Sicurezza: protezione delle informazioni dell’azienda Scalabilità: accesso efficiente a risorse, tolleranza al carico di milioni di utenti (Web) Integrazione: le applicazioni vanno integrate nei sistemi informativi già esistenti

32 J2EE Si sono sviluppate soluzioni diverse per affrontare i vari problemi J2EE: permette di integrare tali soluzioni e facilita lo sviluppo del SW –Modello di programmazione con approccio alla costruzione di applicazioni basato su API –Infrastruttura che permette di eseguire le applicazioni in modo efficiente e scalabile basato su Java  portabile basato sul concetto di Contenitore  servizi di gestione di base (messaggi, transazioni, ciclo di vita delle componenti, …) forniti dall’infrastruttura Modulare, componenti riusabili

33 L’evoluzione del Client/Server CLIENT SERVER PC stand alone PC networking End User HOST solution MINI solution Enterprise

34 Allocazione Delle Componenti Data Management Logic/ Control Presentation SERVER CLIENT NETWORK

35 Classificazione delle soluzioni Client/Server

36 Le “ere” del Client/Server Da: Byte Aprile 95

37 HTML Dinamico????? Interne t (htpp) WebServer HTML JSP servlet BusinessObjects DATI servlet browser 1. richiesta.jsp 4. ritorna html 2. richiesta dati 3. generazione html Tier 1 Tier 2 Tier 3 Application server

38 Architetture Two-Tiers e Three-Tiers Market Share DB Market Share DB minore uso delle risorse suddivisione più razionale dei compiti livello intermedio

39 Architetture Multi-Tier Database Servers NC. NetPC PC Client Mobile Mail/GroupwareServers MainframeSystems Interfaccia Utente Logica Applicativa Dati

40 LogicaApplicativa Web+ActiveX o applet Java Web+script lato server (ASP, JSP o servlet) Visual Basic, C++, Delphi Client/Server Lotus Notes, Exchange Groupware Applicazioni real-time batch, OLTP, M&Q Persistenza dei dati Architetture Three-Tier: molti tipi di interfacce utente, la stessa applicazione

41 Componenti Possiedono interfacce standard (almeno un per l’introspezione) Applicazioni non complete Distribuibili separatamente Utilizzabili in combinazioni non predicibili Indipendenti dalle caratteristiche tecnologiche del sistema finale Sono oggetti (nel senso canonico)

42 Componenti (2) Gruppi di programmi gestiti come unità di codice eseguibile, connettibili dinamicamente e accedibili attraverso interfacce documentate che possono essere identificate a run-time

43 Come realizzare una componente Data Ext. method …. Ext. method Int. Method... Int. Method Proxy / Wrapper Traditional OO Data Code Obj. Data Code

44 Java Beans Integrati nel layout grafico che li contiene Generano eventi per il mondo esterno Possiedono proprietà leggibili e modificabili Supportano l’introspezione Sono persistenti Sono personalizzabili

45 COM e DCOM: le origini Microsoft DCOM (Distributed COM) ActiveXOLECOM= COM OLE OLE1 OLE2 Pre 1996 Post 1996 OLE = Object Linking and Embedding COM = Component Object Model COM+ = Estensione della tecnologia COM OLE = Object Linking and Embedding COM = Component Object Model COM+ = Estensione della tecnologia COM COM+

46 COM e DCOM IUnknown Interfaccia 1 Interfaccia n Oggetto COM QueryInterface AddRef Release

47 COM e DCOM Client Oggetto Nello stesso processo Client Oggetto COM Client Process Server Process Sulla stessa macchina Tra due macchine (DCOM) COM DCE RPC Client Server Machine Client Machine COM Oggetto “Marshalling”

48 Ereditarietà in DCOM Ereditarietà dell’interfaccia: SI Ereditarieta dell’implementazione: NO Polimorfismo degli oggetti DCOM: SI

49 Ereditarietà per Contenimento (o delegazione)

50 Ereditarietà per Aggregazione

51 Service Oriented Architectures (SOA) Infrastruttura integrazione

52 Enter Order Composite Services/ Process Objects Batch Client Customer Inventory Billing Call Center Browser B2C Retail B2B Sales A/R Get Inventory Update Inventory Get Balance Update Billing Elemental Services/ Business Objects Open Account Orders Inquire Balance Get Orders Update Orders Inquire Orders Get ID No. Get Address Change Address Client Applications SOA: il sistema informativo organizzato a Servizi

53 Service-oriented Architecture Interaction Uses interface metadata One-to-one connections Client directs flow Linear path of execution Closed to unforeseen input once a flow is started Interface stub Interface proxy Client Server Service-oriented or Event-driven SourceSink Event-driven Notification Uses event descriptor metadata Many-to-many connections Sink (recipient) determines flow Dynamic, parallel, asynchronous flows Can react to new external input while process is in flight Event

54 Module 4 Module 3 Module 2 Module 5 Event 1 Module 1 Event Driven Event 2 Event 3 Fork Join Client 1 Server 1 Server 2/Client 2 Server 3Server 4 Service Oriented Flussi di esecuzione

55 Java 2 Enterprise Edition (1) Standard Sun per le soluzioni “enterprise”, prevede le seguenti librerie: –Enterprise Java Beans (EJB): modello delle componenti sul lato server –Java Naming and Directory Interface (JNDI) –Remote Method Invocation (RMI): accesso distribuito in rete agli oggetti Java –Servlets: presentazione dinamica e gestione sessioni per i client web

56 Java 2 Enterprise Edition (2) –Java Server Pages (JSP): facilitano la creazione di pagine HTML, DHTML e XML –Java Messaging Service (JMS): comunicazione via message & queuing o publish & subscribe –Java Transaction Service (JTA): gestione delle transizioni distribuite (XA o CORBA OTS) –Java DataBase Connection (JDBC) accesso uniforme agli RDBMS –Java Autentication and Authorization Service –JavaMail: accesso ai server di posta elettronica * Costruiti “sopra” i servizi CORBA

57 Enterprise Java Beans Entity EJB –supportano accessi condivisi –rappresentano dati persistenti su DB –identificati da una chiave univoca (primary key) Session EJB –eseguono le richieste di un singolo client –vita per il tempo della connessione –implementano la logica di business Message-Driven EJB (v. 2.0) –in ricezione di messaggi asincroni (JMS o altri) –vita breve per l’elaborazione di un singolo messaggio

58 CICS JSP Servlet Session Bean JCA Resource Manager Message- Driven Bean Entity Bean Applet Browser DBMS Q Q ERP J2ME Server Desktop Applicazioni J2EE

59 Elementi di un ambiente EJB EJB Container Home Object (Remote) Crea, distrugge, cerca Sicurezza - accesso ai dati - transazioni,... EJB Server

60 Fornisce la Java Virtual Machine e le classi di supporto agli EJB Fornisce le funzioni di base di ORB e TP monitor Fornisce le funzioni di accesso ai DB Realizza il bilanciamento del carico e l’alta disponibilità

61 EJB Container fornisce l’ambiente in cui gli EJB di una classe vengono eseguiti fornisce ai client l’accesso a EJB Home e Object realizza, insieme all’EJB server, i servizi di base: sicurezza, transazioni, naming, persistenza (dello stato) può gestire pool di oggetti della stessa classe

62 EJB Object (Remote) Rappresenta l’interfaccia dell’EJB verso il mondo esterno Filtra ed integra i messaggi verso le istanze di EJB Coordina le transazioni Nome:

63 EJB Home Permette di creare istanze di oggetti di una classe e di cercarle Nome: Home Metodi: –create () –destroy () –interfaccia finder (solo per entity EJB)

64 Sviluppo di un EJB Si veda...

65 Formati di deployment J2EE –Ogni prodotto richiede file “deployment descriptor” proprietari per descrivere le caratteristiche non standard (load balancing, gestione guasti, risorse…)

66 Interazioni fra le classi J2EE

67 EJB Container Client EJB Jar Deployment Descriptor Deployment Descriptor Istanza del bean Naming Service Naming Service EJB Home EJB Context EJB Object lookup interfaccia home con JNDI findByPrimaryKey(..) create(..) new o activate EJB Objects Pool ejbActivate(..) ejbPassivate(..) isCallerInRole(..) contesto di esecuzione fornito in automatico dal container ad ogni chiamata metodi del bean es. ejbRemove() metodi di business es. addPrestito(..) Architettura Enterprise JavaBeans

68 Persistenza ed EJB Bean-managed persistence (BMP) –i dati sono acceduti direttamente dal codice attraverso librerie quali JDBC o SQLJ. Container-managed persistence (CMP) –il container gestisce la persistenza in modo automatico. –Container-managed relationships (CMR) –EJB Query Language (EJB QL)

69 Mapping fra Entity Beans e DB

70 COM DNA MTS.NET DNA2000 COM+ DCOM ……. 1990s 2000s Distributed Components Components Transactional Components Three-Tier Architecture Enterprise Quality of Service Loose Coupling Internet Network Computing Evoluzione delle soluzioni Microsoft

71 Microsoft.NET (1) CLR (Common Language Runtime) –interprete di IL (Intermediate Language) derivabile da molti linguaggi di programmazione: VB, C++, C#, Cobol –tutti i linguaggi supportati diventano object oriented (ereditarietà, costruttori parametrici) superando i limiti di COM –garbage collection della memoria –gestione delle eccezioni –sicurezza durante l’interpretazione –compilatore just-in-time –gestione delle versioni Spazi di nomi gerarchici (namespace)

72 Microsoft.NET (2) Intercomunicazione fra oggetti COM e.NET ASP.NET: –sviluppo di pagine HTML dinamiche con gestione degli eventi sui controlli visuali (Web Forms) –sviluppo facilitato di Web Services

73 System System.DataSystem.Xml System.Web Globalization Diagnostics Configuration Collections Resources Reflection Net IO Threading Text ServiceProcess Security Design ADO SQLTypes SQL XPath XSLT Runtime InteropServices Remoting Serialization Serialization ConfigurationSessionState CachingSecurity Services Description Discovery Protocols UI HtmlControls WebControls System.Drawing Imaging Drawing2D Text Printing System.Windows.Forms DesignComponentModel Il Framework.Net

74 JVM e CLR

75 Running Process’ Memory SomeSources.exe IL Metadata JIT Compiler Native Machine Language The CPU executes the JIT- compiled machine code directly At execution time the IL and Metadata are JIT compiled Executing a Managed Application

76 Altre caratteristiche di.NET Librerie XML e web services Tutti i linguaggi sono completamente OO (ereditarietà) ed interoperabili (stesso MSIL) Assembly (unità autodescrittive di deployment) Versioning delle interfacce (fine del “DLL hell”) Remoting ADO.NET: vista dei dati basata su XML

77 Enterprise Services ASP.NET ADO.NET { Gli Enterprise Services forniscono i servizi di MTS/COM+ (transazioni, pooling risorse...)

78 eXtensible Markup Language (XML) Standard del W3C Deriva dallo Standard Generalized Markup Language (SGML) come l’HTML Orientato alla rappresentazione dei dati Il formato di un documento XML è definito in un DTD (Data Type Definition) L’eXtensible Stylesheet Language (XSL) descrive le regole di trasformazione di documenti XML in altri documenti XML o HTML

79 Esempio di documento XML “http://www.miodtdserv.com/richiesta_pagamenti.dtd")> LIVELLO="Urgente" FIRMATA_DA="Mario Rossi"> Burlini Costruzioni spa Burlini Costruzioni spa OA1234X99 OA1234X99 LIT LIT

80 Esempio di DTD

81 I Web Services Composizione di applicazioni attraverso componenti distribuite sul WWW Standard, tutti basati sull’XML: –SOAP (Simple Object Access Protocol) il protocollo di richiamo di procedure remote come web services –WSDL (Web Services Description Language): il linguaggio di definizione dei web services –UDDI (Universal Description, Discovery and Integration) il protocollo per ricercare i web services, una sorta di "elenco telefonico" o "pagine gialle" dei web services

82 Formato dei messaggi SOAP SOAP Header –dati opzionali sulla chiamata stessa (autenticazione, pagamento, dove sono dichiarati i tipi usati, …) SOAP Body –contiene i dati delle chiamate e/o i risultati di ritorno

83 WSDL WSDL allows Web services to be self-describing. A WSDL document includes nine basic XML elements: Five abstract elements — port type, operation, message, part and type Three concrete elements — service, port and binding One definition element — provides definitions relating to the service. Abstract Implementation Port Type Operation Messages … … Binding End Point Maps To Protocol Associated With Port

84 WSDL Document Elements

85 UDDI Registry Data Structures

86 Service Interface Import Types Message PortType Binding Business Service BindingTemplate Finds Port Points To Import Service Business Entity Points To Imports Service Implementation UDDI Registration File WSDL File Mapping WSDL to UDDI tModel

87 Soluzione Java per i Web Services OS Web Container EJB Container JVM Application Server SOAP Processor Local UDDI WSDL Servlets JSPs EJBs Connectors Internet Router Firewall Load Balancer Web Servers Integration Brokers RDBMS Legacy Middle Tier Front-End Tier Back-End Tier Application Server Subtier

88 Simple API for XML (SAX).

89 Document Object Model (DOM)

90 Trasformazioni XSLT XSLT (eXtensible Stylesheet Language for Transformations)

91 Network Managed Process ASP.Net ISAPI DLL Hosting the.NET Framework CLR XML Web Service objects SOAP Method Request SOAP Method Response Web Server Service-Client ASP.Net

92 Esempio di Web Service con ASP.NET using System; using System.Web.Services; public class DateService:WebService{ [WebMethod] public String GetDateString() { return DateTime.Now.ToString("D"); } DateService.asmx Servizi implementati in file.ASMX

93 Esempio di richiamo di un Web Service in.NET using System; class App{ public static void Main(){ DateService webObj = new DateService(); webObj.Url = "http://www.miaazienda.com/Services/DateService.asmx"; String dateString = webObj.GetDateString(); Console.WriteLine(dateString); } DateClient.cs Simple model for network communication –Object Instantiation –Method Call DateService type is a proxy object

94 Gli standard XML Transports XML, XML Schemas, Encoding SOAP (WS Routing, WS Attachment, DIME) WSDL, UDDI, WS-Introspection WS-Coordination WS-Transaction WS-Security Reliable Messaging BPEL (Business Process Automation) IBM’s and Microsoft’s “Web Services Architecture” (as of September 2002) TBD Implemented Standards Proposed Standards Pre-Web Services Standards

95 Web Services Services Components Granularity Scope B2B Market, Global Enterprise Coarse Objects HTTP+SOAP MOM ORB Typical Access via Small Enterprise, Complex Application Homogeneous Application Program Tighter Looser Coupling Procedural Call Dalle procedure ai servizi


Scaricare ppt "ARCHITETTURE Architetture N-Tier COM (Component Object Model) e DCOM (Distributed COM) SOA (Service Oriented Architecture) Enterprise Java Beans Microsoft.NET."

Presentazioni simili


Annunci Google