Architetture parte II a.a parte 2 a.a. 2004/05

Presentazione sul tema: "Architetture parte II a.a parte 2 a.a. 2004/05"— Transcript della presentazione:

1 Architetture parte II a.a. 2004-2005 parte 2 a.a. 2004/05
Tecnologie Web

2 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) a.a. 2004/05 Tecnologie Web

3 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 a.a. 2004/05 Tecnologie Web

4 Come realizzare una componente
Strategic Planning Assumption: Through 2002, the majority of IS organizations successfully implementing CBD applications will use non-OO components, especially “wrapped” legacy and package programs/modules, as a major part of their application portfolio (0.8 probability). Come realizzare una componente Data Code Proxy / Wrapper Data Ext. method …. Data Int. Method ... Code Traditional Obj. Obj. Obj. Obj. Source: Gartner Research Components can be created in many ways, but all share some common characteristics. A component will typically expose external methods or services which can be bound dynamically (i.e., at runtime rather than only at compile time). Many components will also have internal methods that are available only to code residing inside the component. Some (but not all) components contain data. Most components encapsulate both data and code, meaning that these cannot be accessed directly and may only be accessed by invoking external methods. Components may be true objects, but this is not a requirement. Components are often not true objects because they do not necessarily support inheritance, where a new class of objects is defined in terms of an existing class using inheritance. Components may be implemented in many ways. One of the most common (and valuable) is when a component on one platform acts as a proxy to access services defined on another. A common example of this approach is wrapping legacy code and data that might be located on a mainframe. Although components may not always be true objects, they may be implemented using objects and will often be a convenient way to package object code for delivery. Action Item: When building new CBD applications or evaluating CBD technologies, enterprises should ensure that legacy-wrapping capabilities and services are part of the solution. OO a.a. 2004/05 Tecnologie Web

5 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 a.a. 2004/05 Tecnologie Web

6 COM e DCOM: le origini Microsoft OLE COM = ActiveX COM DCOM OLE1 OLE2
Pre 1996 Post 1996 COM OLE1 DCOM (Distributed COM) OLE2 OLE COM+ OLE = Object Linking and Embedding COM = Component Object Model COM+ = Estensione della tecnologia COM a.a. 2004/05 Tecnologie Web

7 COM e DCOM QueryInterface IUnknown AddRef Release Interfaccia 1
Oggetto COM Interfaccia n a.a. 2004/05 Tecnologie Web

8 COM e DCOM Nello stesso processo Sulla stessa macchina
Oggetto Client Client Process Server Process Sulla stessa macchina Oggetto COM Client Tra due macchine (DCOM) Client Machine Server Machine Oggetto DCE RPC COM COM Client a.a. 2004/05 Tecnologie Web “Marshalling”

9 Ereditarietà in DCOM Ereditarietà dell’interfaccia: SI
Ereditarieta dell’implementazione: NO Polimorfismo degli oggetti DCOM: SI a.a. 2004/05 Tecnologie Web

10 Ereditarietà per Contenimento (o delegazione)
a.a. 2004/05 Tecnologie Web

11 Ereditarietà per Aggregazione
a.a. 2004/05 Tecnologie Web

12 Interfacce In COM/DCOM le interfacce sono immutabili
Globally Unique IDentifiers (GUID) di 16 byte per definire univocamente e immutabilmente le interfacce Le interfacce risolvono il problema del versioning a.a. 2004/05 Tecnologie Web

13 Esempio Visual Basic (VBA)
Sub ControlloOrtografico() Dim Obj as Object Set Obj = CreateObject(“Excel.Application”) Parola = InputBox(“Scrivi una parola”) If Obj.CheckSpelling(Parola) then MsgBox(“Parola valida”) Else MsgBox(“Parola errata”) End if End Sub a.a. 2004/05 Tecnologie Web

14 Architettura Three-Tier (DNA)
Active Controls Active Scripting Visual Basic form- based application MFC/SDK application Java applet or application Logic and abstractions Durable state a.a. 2004/05 Tecnologie Web

15 Business Objects Rappresentano oggetti dell’applicazione (cliente, conto corrente, fattura, automobile, …) Realizzano le “business rules” Saranno utilizzati in combinazioni non predicibili a priori (connessioni dinamiche ritardate) Sono realizzati come componenti installate sul secondo livello di un’architettura three-tier a.a. 2004/05 Tecnologie Web

16 Ambiente di esecuzione evoluto
Object Transaction Monitors (OTM) Object Request Broker Market Share Ambiente di esecuzione evoluto a.a. 2004/05 Tecnologie Web

17 Microsoft COM+: costruire applicazioni scalabili
Clients Network Receiver Queue Connections Context Security Management Configuration Thread Pool Service Logic Synchronisation Shared Data Server a.a. 2004/05 Tecnologie Web

18 COM+: i servizi integrati nella piattaforma
Clients Windows NT Server 4.0 Network Thread Pool Queue Connections Context Security Shared Data Receiver Synchronisation Service Logic Configuration Management a.a. 2004/05 Tecnologie Web

19 Programmazione con MTS/COM+
Set ctxObject = GetObjectContext() YOUR CODE YOUR CODE Set objfoo = ctxObject.CreateInstance() YOUR CODE YOUR CODE ctxObject.SetComplete ctxObject.SetAbort An MTS Application “Voglio accedere al mio contesto” “Chiama un altro oggetto” No TX code No Thread code No Locking code Etc. “Bene: riusa, fà commit, fà pulizia” “Ci sono problemi: aiutami!” a.a. 2004/05 Tecnologie Web

20 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.) a.a. 2004/05 Tecnologie Web

21 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, ... a.a. 2004/05 Tecnologie Web

22 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) a.a. 2004/05 Tecnologie Web

23 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 a.a. 2004/05 Tecnologie Web

24 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 a.a. 2004/05 Tecnologie Web

25 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 a.a. 2004/05 Tecnologie Web

26 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 a.a. 2004/05 Tecnologie Web

27 Enterprise Java Beans Entity EJB Session 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 a.a. 2004/05 Tecnologie Web

28 Applicazioni J2EE Entity Bean Applet JSP Session Servlet Bean Message-
Key Issue: What will be the technology evolution and business case for J2EE and .NET? Applicazioni J2EE Entity Bean DBMS Applet JSP Servlet Session Bean Message- Driven Bean Q Browser J2ME JCA Resource Manager ERP J2EE was first introduced in It was initially designed by Sun with substantial input from IBM and additional influential input from BEA and other enterprise infrastructure vendors. J2EE architecture reflects the advanced enterprise expertise of its designers. The architecture places most of the application on the server (a break from the fat-client architecture of the past). J2EE separates various styles of business logic into separate styles of software. Java Server Pages and Servlets are intended to be used for user-interface logic of the application. Enterprise Java Beans (EJBs) are intended to be used for reusable back-end business logic of the application. Entity EJBs are designed to represent encapsulation of data and sessions and to control the overall process of a transaction. J2EE Connectors Architecture components are intended to be used for building adapters to external applications (packages or legacy). Message-driven Beans are intended for reusable business logic that is designed to operate in an event-driven mode, responding not to synchronous request/reply clients, but to asynchronous posting of events. The rich architecture of J2EE is also complex and requires advanced technical skills to take full advantage of its technical features. The majority of J2EE applications use only a small subset of all available features. Action Item: J2EE is a rich architecture. Evaluate its features and match your project skills and requirements to an appropriate subset of J2EE. CICS a.a. 2004/05 Desktop Tecnologie Web Server

29 Elementi di un ambiente EJB
EJB Server EJB Container Home Crea, distrugge, cerca Object (Remote) Sicurezza - accesso ai dati - transazioni, ... a.a. 2004/05 Tecnologie Web

30 EJB Server 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à a.a. 2004/05 Tecnologie Web

31 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 a.a. 2004/05 Tecnologie Web

32 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: <classe> a.a. 2004/05 Tecnologie Web

33 EJB Home Permette di creare istanze di oggetti di una classe e di cercarle Nome: <classe>Home Metodi: create () destroy () interfaccia finder (solo per entity EJB) a.a. 2004/05 Tecnologie Web

34 Sviluppo di un EJB a.a. 2004/05 Tecnologie Web Si veda ...

35 Formati di deployment J2EE
J2EE components can be deployed in various types of JAR files, as depicted in figure When you roll your components into production, you might archive your EJB JAR files and WAR files into a single Enterprise Application Archive (EAR) file and deploy it. However, there is a large amount of vendor specific configuration to be done for each component before it is deployed. Creating the individual components and then integrating them into an application archive is more complicated than it appears. Current J2EE server implementations require a vendor-specific deployment descriptor file to be included with your EJB and web components. These files handle the deployment specifics that are not addressed by the generic J2EE descriptors. These specifics include nonfunctional characteristics like load balancing and failover information and resource mappings for references made in the standard deployment descriptors. Ogni prodotto richiede file “deployment descriptor” proprietari per descrivere le caratteristiche non standard (load balancing, gestione guasti, risorse…) a.a. 2004/05 Tecnologie Web

36 Dichiarazione di un’interfaccia remota (Object)
import javax.ejb.EJBObject; import java.rmi.RemoteException; import java.math.*; public interface Converter extends EJBObject { public BigDecimal dollarToYen(BigDecimal dollars) throws RemoteException; public BigDecimal yenToEuro(BigDecimal yen) } a.a. 2004/05 Tecnologie Web

37 Esempio: creazione dell’interfaccia Home
import java.io.Serializable; import java.rmi.RemoteException; import javax.ejb.CreateException; import javax.ejb.EJBHome; public interface ConverterHome extends EJBHome { Converter create() throws RemoteException, CreateException; } (si veda per l’esempio completo) a.a. 2004/05 Tecnologie Web

38 Esempio: implementazione dei metodi esposti
import java.rmi.RemoteException; import javax.ejb.SessionBean; import javax.ejb.SessionContext; import java.math.*; public class ConverterBean implements SessionBean { public BigDecimal dollarToYen(BigDecimal dollars) { … implementazione ... } public BigDecimal yenToEuro(BigDecimal yen) { … implementazione ... public ConverterBean() {} public void ejbCreate() {} public void ejbRemove() {} public void ejbActivate() {} public void ejbPassivate() {} public void setSessionContext(SessionContext sc) {} a.a. 2004/05 Tecnologie Web

39 Esempio: il client import javax.naming.Context; import javax.naming.InitialContext; import javax.rmi.PortableRemoteObject; import java.math.BigDecimal; public class ConverterClient { public static void main(String[] args) { try { Context initial = new InitialContext(); Object objref = initial.lookup ("java:comp/env/ejb/SimpleConverter"); ConverterHome home = (ConverterHome)PortableRemoteObject.narrow(objref, ConverterHome.class); Converter currencyConverter = home.create(); BigDecimal param = new BigDecimal ("100.00"); BigDecimal amount = currencyConverter.dollarToYen(param); System.exit(0); } catch (Exception ex) {System.err.println(”!!!"); ex.printStackTrace(); } } a.a. 2004/05 Tecnologie Web

40 Interazioni fra le classi J2EE
a.a. 2004/05 Tecnologie Web

41 Architettura Enterprise JavaBeans
EJB Container Client EJB Jar Deployment Descriptor Istanza del bean 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(..) a.a. 2004/05 Tecnologie Web

42 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) a.a. 2004/05 Tecnologie Web

43 Mapping fra Entity Beans e DB
a.a. 2004/05 Tecnologie Web

44 Dichiarazione di dati CMP
public class OrderBean implements EntityBean { public Integer orderId; public String customerName; public Address customerAddress; // some code } <entity> <description>CMP Entity Bean</description> <display-name>Order</display-name> <ejb-name>Order</ejb-name> <home>order.OrderHome</home> <remote>order.Order</remote> <ejb-class>order.OrderBean</ejb-class> <persistence-type>Container</persistence-type> <primkey-field>orderId</primkey-field> <prim-key-class>java.lang.Integer</prim-key-class> <reentrant>False</reentrant> <cmp-field> <field-name>orderId</field-name> </cmp-field> <field-name>customerName</field-name> <field-name>customerAddress</field-name> </entity> deployment descriptor: a.a. 2004/05 Tecnologie Web

45 Service Oriented Architecture
Perché nasce la SOA Web Services .NET Java a.a. 2004/05 Tecnologie Web

46 Esempio di E-business workflow I
Prima: Acme manufacturing utilizza software proprietario per organizzare prese della Federal Express Adesso Acme utilizza il sito della Federal Express per seguire il percorso del pacco a.a. 2004/05 Tecnologie Web

47 Esempio di E-business workflow II
Prima: Acme manufacturing ordina un computer dalla Dell e ne segue il procedimento con telefonate Adesso Acme utilizza il sito della Dell per seguire le fasi di processamento dell’ordine, preproduzione, produzione, preparazione alla consegna e spedizione a.a. 2004/05 Tecnologie Web

48 Service Oriented Architecture
Business to Business integration Integrazione di applicazioni sviluppate su piattaforme eterogenee Evoluzione middleware E-business workflow a.a. 2004/05 Tecnologie Web

49 Service Oriented Architecture
Utilità nel descrivere i processi aziendali in forma leggibile su Web dai clienti Utilità nel descrivere i processi aziendali in forma leggibile da macchine a.a. 2004/05 Tecnologie Web

50 Service-oriented or Event-driven
Decision Framework: SOA interactions have interface “contracts” that describe the sequence and contents of a two-way communication process spanning two or more messages. By contrast, event-driven notification is a one-way, non-interactive form of communication that is documented by event descriptors that hold message schema. 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 Client Server Interface proxy Interface stub 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 Source Event Sink SOA and event-driven architecture have many similarities. Both are ways of combining multiple software modules into large, distributed applications. They go beyond conventional application design by separating the interface definition (or event descriptors) from the software implementation. Either may be enabled through Web services, although neither requires Web services. However, they differ in the way they organize the relationships among the modules. At the risk of oversimplification, SOA uses directed, generally bi-directional, request/response communication to delegate work to a subordinate procedure, whereas event-driven architecture uses unidirectional messaging to communicate among two or more, largely independent peer procedures. In a SOA, a client application will find, then bind to and invoke a service. In an event-driven relationship (notification), sources do not find, bind or invoke sinks. The only communication is through the data in a software event. An event source does not need to know who or what is supposed to receive the event or what the sink will do with it. Just as object-oriented developers think about and define objects, event-oriented developers think about and define events as a primary focus of attention. Applications often intermingle service and event relationships in the same set of applications. Action Item: IS architects and developers must understand the local business requirements and process models to determine if SOA, event-driven architecture or some combination of them is the best solution. a.a. 2004/05 Tecnologie Web

51 Dalle procedure ai servizi
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 Source: Gartner Research E-business demands continue to be the overriding driver of application change in most enterprises. These demands are often best met with packaged solutions. Yet, the old business expectations continue to exist. AD organizations should not randomly dismiss restructuring existing systems to introduce flexibility — particularly where the quality of service, performance and data volume characteristics are high. Leverage your skills and infrastructure, while you move toward a more-complex mix of platforms, applications and technologies. Training has never been more important than now; recognize that not all your staff can make the transition to some of the new technologies (e.g., Unix servers, Java, OO, modeling, Internet, components, distributed computing). While many organizations first want to hire programmers with the right skills, more should train their skilled programmers in the technologies of tomorrow. The talents of your people do not solely reside in their technology skills. Evolve your development organization to a component/assembly mentality where reuse is rewarded — even on existing mainframe environments! Flexibility is possible, even on mainframe-based, COBOL legacy systems. a.a. 2004/05 Tecnologie Web

52 La complessità dei sistemi informativi aziendali nasce dalla sovrapposizione nel tempo delle soluzioni Strategic Planning Assumptions: Through 2006, more than two-thirds of vital business information in midsize and large enterprises will be managed by systems originally designed without provisions for integration (0.8 probability). By 2006, more than 60 percent of interapplication communications in midsize and large enterprises will be accomplished through point-to-point custom software bridges (0.8 probability), down from more than 80 percent in 2001. Trans- action file FTP ORBl Message Gateway APPC CICS gateway ORB queue Down- load HTTP/XML Screen scrape Sockets RPC Source: Gartner Research a.a. 2004/05 Tecnologie Web

53 Soluzione: un’infrastruttura aziendale di intercomunicazione fra le applicazioni
Strategic Planning Assumption: By 2006, the strength of the application-level semantic networks (enterprise nervous systems) will be a key differentiator of the business leaders in most vertical industries (0.8 probability). Virtual Enterprise Enterprise Shop Floor Data Center Sales Branch Business Customers & Dealers ASPs and Outsourcers ERP HR Subsidiary Billing Infrastruttura aziendale di Intercomunicazione Suppliers Purchasing Marketing Shipping Dept Service Web-Based Intermediaries Web-Based Intermediaries Business Customers Source: Gartner Research Suppliers Consumers a.a. 2004/05 Tecnologie Web

54 Service Oriented Architectures (SOA)
Tactical Guideline: The fundamental principle of successful IS city planning (application integration) is to manage the connections between the applications as if each system were in an opaque “black box.” Infrastruttura integrazione Key Issue: How will enterprise architecture best practices evolve to accommodate heterogeneity in the next five years? A systematic attack on the challenge of application integration is based on the principles of modularity and encapsulation. An application system can be said to have two information models: an internal model that applies within the system and an external (or “exchange”) model that describes its relationships with the outside world. Traditional architecture stresses the internal model, but that is not central to the problem of integration. The exchange model is an information architecture that describes the schema formats, semantics and behavior of the interactions with other systems or people outside a logical black box. The enterprisewide message dictionary or interface repository enables reuse of the interface definitions and, sometimes, the actual messages. The exchange repository may include application-level dialog (or protocol — now labeled a type of business process management). A very coarse-grained enterprise data model helps with the design of the exchange model, but a detailed internal data model of the participating systems is unnecessary. The integration competency center must cooperate closely with central data administration, because operational data stores and data warehouses may be fed through the enterprise nervous system and its message warehouses. Action Item: The exchange data model should be developed incrementally as new applications are added or modified, rather than attempting a comprehensive, enterprisewide interface model, before starting any development work. a.a. 2004/05 Tecnologie Web

55 SOA: il sistema informativo organizzato a Servizi
Tactical Guideline: Reusing big things (e.g., services) through messaging is easier than reusing small things (e.g., classes or subroutines) through copying, especially if many different development teams are involved. Customer Billing A/R Inventory Orders Elemental Services/ Business Objects Get Inventory Update Inventory Get Orders Update Orders Get ID No. Get Address Change Address Update Billing Get Balance Composite Services/ Process Objects Inquire Orders Enter Order Inquire Balance Open Account Call Center B2C Retail B2B Sales Batch Client Client Applications Key Issue: What will be the critical success factors for implementing architecture in the next five years? Service-oriented architecture reuse differs from traditional code reuse or object-oriented (OO) class reuse. Services are reused just by sending messages from disparate clients to one shared service through runtime middleware (“delegation”); whereas code or class reuse involves copying or inheriting code through a programming language tool. Elementary services call no other services. Enterprises sometimes use composite services that invoke a sequence of other composite or elementary services. Composite services can be implemented in “process” or “task” business objects, or in business process “orchestration” tools. Developers have many design choices (e.g., whether to use many small services or a few bigger services). The most widely shared functions (e.g., maintaining customer, product and employee information) are often implemented as services because they are the most widely reused kinds of information. It is not necessary, and it is often impractical, to implement all of an application’s work as services. Action Item: New, large-scale applications with long expected life spans should use a service-oriented architecture for all functions that are potentially reusable. Browser a.a. 2004/05 Tecnologie Web

56 Service-Oriented Architecture : The architecture of interfaces
Definition: Design of Service-oriented systems is design of service interfaces and of service interactions Service-Oriented Architecture : The architecture of interfaces Service Software component that is a business-complete logical unit of work, accessible programmatically from independently designed contexts via a direct openly documented interface Service Interface Service Implementation SOA Application software topology consisting of services and service consumers (clients) in loosely coupled 1-to-1 relationships Service Consumer (Client) Interface proxy Interface A service is a software component that is suitable for cross-application access. A service represents a business function, though it is implemented as a technical component. A service is the point of linkage between business and technical design of business applications. A service is never a complete application or a complete transaction. It is always a building block. SOA is the architecture of an application that utilizes services. While services define potentially-reusable business functions, SOA binds services into applications. SOA applications consist of services and service consumers. Services are defined by their interfaces which wrap their implementations (sometimes complex integrated flows, other times a simple single program). Logical design of SOA is focused on the definition of service interfaces and design of interactions between service interfaces. Technically, design of SOA also includes design of service implementations SOA is a loosely coupled (but not decoupled) architecture. Loose coupling of SOA manifests itself in flexible association of services and service consumers. A new service consumer can access a pre-existing service entirely un-intrusively (a poorly designed service may lock a service into a particular service consumer, denying the key benefit of SOA). Action item: Begin design of SOA with design of service interfaces. a.a. 2004/05 Tecnologie Web

57 Service Implementation: What Happens Behind The Interface
Strategic Planning Assumption: Through 2008, more than 60 percent of SOA projects will be composite: will engage business logic or data of multiple applications (0.8 probability) Service Implementation: What Happens Behind The Interface All-New Service Wrapped Service Service Consumer Composite Service A logical definition of a service simply indicates the business function that a service performs. In reality, the service implementation may translate to a relatively complex process and depend on many sources of information to fulfill the functional requirement designed for the service. What makes it more complicated is that the technical design of the service implementation cannot make any assumptions about the context in which the service would be invoked. The service may be used stand-alone, as part of a sequence of calls on behalf of a real-time transaction or as a subordinate component in an asynchronous EDA. Due to this inherent complexity, most service implementations likely will be relatively simple, self-contained and stateless. (All three principles — simplicity, isolation and statelessness — are the best practices of design for all distributed systems.) Some service implementations will be developed as new components. This is the simplest case and also the least frequent through 2006, given that the composite application style will likely be the leading driver for adoption of SOA. Some early Web services implementations have been automatically generated (wrapped pre-existing JavaBeans, CORBA objects, CICS DPL transaction programs, C++ classes). These wrapped services are the easiest to implement but are often the least effective, because the design objective of an object class or a component is different from that of a service -- the resulting service may be too fine-grained, may spur massive network traffic and may flood the services repository). Action Item: use advanced enterprise software engineering skills for design of service implementations Service interface Service implementation Non-SOA applications a.a. 2004/05 Tecnologie Web

58 Flussi di esecuzione Service Oriented Event Driven Client 1 Server 1
Decision Framework: EDA is decoupled; asynchronous SOA is loosely coupled; synchronous SOA is somewhat coupled; and monolithic (non-SOA) applications generally are tightly coupled. Client 1 Service Oriented Server 1 Server 2/Client 2 Server 3 Server 4 Module 4 Event 1 Module 1 Fork Event 2 Module 3 Event Driven Join Module 5 Event 3 An SOA client (for example, a Web services “consumer”) invokes a service (for example, a Web services “provider”). The client decides when and if to invoke a particular server. A client always holds information about the state of the business process, but an SOA server is often stateless. By contrast, each runtime connection in an EDA is potentially a many-to-many relationship, where the overall processing flow is determined by the event sinks or “subscribers” (modules that receive the event). An event published by one source may be delivered to multiple “sinks” (a one-to-many relationship that forks the flow of control). EDA is more efficient than SOA if there are multiple destinations for the same data because the source sends the event only once, whereas an SOA client would have to make successive calls through multiple interfaces to achieve the same wide distribution. Each sink may receive multiple events before taking any action, enacting a many-to-one relationship that joins the flow of control. Sources do not know anything about the sinks, and vice versa. The event itself contains state information. Event sources and sinks may be added, modified or deleted without affecting any other source or sink. Action Item: Use SOA when the nature of the business problem requires a request/response relationship in which the client module gets some answer (immediate or deferred) from a subordinate procedure before it can complete its work. Use events for applications in which multiple processing streams may execute simultaneously; the timing of events, such as the beginning or end of a step, or the arrival of additional external input, is unpredictable; or there is a need to dynamically add, drop or modify processing steps without changing any running modules in any way. EDA also improves the understanding of what is happening in the business process. Module 2 a.a. 2004/05 Tecnologie Web

59 Funzioni di un Integration Broker
Strategic Planning Assumption: More than 80 percent of enterprises that lead their respective industries in revenue growth from 2002 to 2005 will have implemented a real-time “enterprise nervous system” for integrating applications within and outside the enterprise (0.8 probability). Business Activity Monitor Event and State Monitoring Metadata Management Development Tools Security and Directory Management Tools Process Manager Business Process Management Transformation Intelligent Routing Message Broker Messaging, Gateways, File Transfer Communication, Data Movement Key Issue: How will enterprise architecture best practices evolve to accommodate heterogeneity in the next five years? City planning technology standards control the number of disparate middleware products in use. Their goals are to maximize interoperability and minimize support and software license costs. The integration middleware may include basic communication facilities (e.g., MOM, file transfer services, screen scrapers and database gateways); an integration broker or two; business process managers; business activity monitors; message warehouse, development, administrative, metadata (message dictionary) and security services; and optional gateways and adapters for independent software vendor (ISV) packages. Enterprises that fail to standardize on their integration middleware will end up with expensive and complex “nervous systems,” too many MOM products, too many integration brokers, too many business process managers and other redundancies. Most enterprises, however, will be incapable of consolidating all their work onto a single integration middleware technology. More than 33 percent of large enterprises will have two or more disparate integration brokers in production by the end of 2003 (0.7 probability). Action Item: The enterprise integration competency center should standardize on the minimum, practical number of disparate integration middleware tools to reduce costs and maximize the effectiveness of the enterprise nervous system. a.a. 2004/05 Tecnologie Web

60 Esempio di Architettura Multicanale
a.a. 2004/05 Tecnologie Web

61 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 a.a. 2004/05 Tecnologie Web

62 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 a.a. 2004/05 Tecnologie Web

63 Abstract Implementation
Strategic Planning Assumptions: By 2007, at least 25 percent of all WSDL Web services will be invoked inside the enterprise’s firewall, and the majority of these will not use Internet communications; in other words, at least 25 percent of Web services will not be Web-based (0.7 probability). By 2007, more than 90 percent of enterprises that use Web services will host Web services implementations on two or more Web services provider platforms (0.9 probability). WSDL Abstract Implementation WSDL allows Web services to be self-describing. A WSDL document includes nine basic XML elements: Port Type Operation Messages <types> … </types> <parts> … </parts> 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. Maps To Binding Associated With Port Protocol Key Issue: What exactly are Web services and how do they work? WSDL is a syntax and vocabulary for creating an XML-based interface to an application. As such, it provides several pieces of information. WSDL specifies a standard format for specifying messages and data passed between a Web service’s client and server, describes the semantics for these messages (i.e., unidirectional or bi-directional, asynchronous or synchronous) and includes directions for accessing a Web service using one or more transport protocols. Many WSDL tools can also create client-side proxies, called stubs, which make it easier to access a Web service. In this sense, WSDL acts like other interface definition languages (IDLs). WSDL allows Web services to be self-describing. Using WSDL, a Web service can describe its location, protocol interfaces and operations in much the same way that Java objects and components use reflection and introspection. This allows humans and computers to dynamically discover and use Web services when needed. Having a standard set of service-oriented messaging facilities and a standardized mechanism for discovering services is of no use if there is no way to describe what a service is and how its facilities can be accessed. Enter WSDL, recently submitted to the W3C XMLP Working Group and expected to be a recommendation by year-end As communications protocols and message formats are standardized in the Web community, the ability to describe the communications in some structured way becomes increasingly possible and important. WSDL service definitions provide documentation for distributed systems and serve as a recipe for automating the details involved in applications communication. Action Item: Evaluate tools that provide support for WSDL. End Point End Point a.a. 2004/05 Tecnologie Web

64 WSDL Document Elements
Key Issue: Where is WSDL heading? Web services publishers — that is, organizations that list Web services on the registry — use the documents to publish and describe their services. Web services consumers — that is, clients who are looking for Web services — download these documents, and use the information to locate and work with the services. The interaction between Web services publishers and consumers is: 1) The consumer gets the WSDL file’s URL, or address, and requests the file. This address can be an individual file, a server or a Web services registry. 2) The publisher processes the consumer’s request (most commonly via HTTP) and sends the WSDL document to the consumer. 3) The consumer’s XML parser reads the file, processes the elements and loads the WSDL file into the Document Object Model (DOM). 4) The consumer uses an appropriate WSDL client to create an XML service invocation request, most frequently via SOAP. This client may accompany or be included in the WSDL file. 5) The consumer’s SOAP service creates the SOAP envelope, adds the request to the payload and sends the SOAP document to the publisher’s URL. 6) The publisher’s Web services proxy parses the message, extracts the payload and calls up the appropriate processing facilities, which return their responses to the proxy. 7) The publisher’s proxy collects the response, translates it to XML, creates a SOAP message and puts the response in the payload, and returns it to the consumer via HTTP. a.a. 2004/05 Tecnologie Web

65 UDDI Registry Data Structures
Key Issue: What is the prognosis for UDDI? In many ways, UDDI is the most complex of the three canonical Web services. The registry itself is populated by five data structures, many of which come directly from WSDL documents. The business entity is the topmost element in a registry file; it describes the publishing organization, and provides contact and querying information. Just below this is the business services element, which offers human-readable, nontechnical information about the service and at least one binding template for binding to the service using a specific protocol. The binding template explains how to locate and connect to the Web service by referencing at least one tModel document. tModels are probably the most important documents in the registry. They are relatively free-form documents that contain details about the service, such as where it is located, or programmatic information for binding to the service. tModels can include additional APIs or specifications, information directed to programmers, or even encapsulate information directly from a Web service’s WSDL document. Canonical tModel files are available from classification organizations such as Dun & Bradstreet. The last data structure, the publisher assertion, declares a business relationship between two or more entities in a UDDI registry. These are most often used to identify subdivisions or departments of a larger organization, or membership in an industry association. a.a. 2004/05 Tecnologie Web

66 Mapping WSDL to UDDI Business Entity UDDI tModel Registration
Strategic Advice: Create a WSDL document for every Web service to be listed in a UDDI registry, because WSDL document elements map directly into UDDI registration files. Business Entity UDDI Registration File tModel Business Service BindingTemplate Finds Points To Points To Service Implementation Service Interface Import Imports Import WSDL File Service Types Port Message PortType Key Issue: What is the prognosis for UDDI? UDDI registries can leverage and aggregate information from WSDL documents to populate Web services registration and tModel documents; however, WSDL documents are not mandatory for UDDI registrations. In general, a UDDI business entity can point to information in a WSDL service implementation (the concrete elements in a WSDL file), and a UDDI tModel can point to any or all information in the WSDL service interface (the abstract elements in the WSDL file). There are also some specific correspondences between UDDI and WSDL elements, with which information from the WSDL can be directly loaded into UDDI; for example, a WSDL service element corresponds to a UDDI business service element, a WSDL port corresponds to a UDDI binding template, and the type, message, port type and binding elements from WSDL can be loaded directly into a UDDI tModel. UDDI is itself a Web service with its own WSDL file. It exposes itself as a Web service to describe the UDDI registry. UDDI models itself in UDDI and — at least in version 2.0 — has two tModels: one representing the publishing API and the other representing the inquiry API. UDDI version 3.0 may add more tModels to correspond to the additional APIs that are furnished with the specification. Binding a.a. 2004/05 Tecnologie Web

67 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 a.a. 2004/05 Tecnologie Web

68 Esempio di documento XML
<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE RICHIESTA_PAGAMENTO SYSTEM “ <!-- Messaggio relativo ad una richiesta di pagamento a seguito di fattura   --> <RICHIESTA_PAGAMENTO> <FATTURA APPROVATA_DA="Mario Rossi" DATA="22-Set-1999“ LIVELLO="Urgente" FIRMATA_DA="Mario Rossi"> <CLIENTE>Burlini Costruzioni spa</CLIENTE>   <ORDINE_ACQUISTO>OA1234X99</ORDINE_ACQUISTO> <IMPORTO>LIT </IMPORTO>   </FATTURA> </RICHIESTA_PAGAMENTO> a.a. 2004/05 Tecnologie Web

69 Esempio di DTD <?xml version="1.0" encoding="UTF-8" ?>
<!-- Dichiarazione del documento "Richiesta di Pagamento" --> <!ELEMENT RICHIESTA_PAGAMENTO (FATTURA)+> <!ELEMENT FATTURA (CLIENTE, ORDINE_ACQUISTO, IMPORTO)> <!ATTLIST ARTICOLO APPROVATA_DA CDATA #REQUIRED> <!ATTLIST ARTICOLO FIRMATA_DA CDATA #REQUIRED> <!ATTLIST ARTICOLO DATA CDATA #IMPLIED> <!ATTLIST ARTICOLO LIVELLO (Urgente|Normale) "Normale" > <!ELEMENT CLIENTE (#PCDATA)> <!ELEMENT ORDINE_ACQUISTO (#PCDATA)> <!ELEMENT IMPORTO (#PCDATA)> a.a. 2004/05 Tecnologie Web

70 Simple API for XML (SAX).
Using SAX, the parser reads in the XML data source and makes callbacks to its client application whenever it encounters a distinct section of the XML document. For example, a SAX event is fired whenever the end of an XML element has been encountered. The event includes the name of the element that has just ended. To use SAX, you implement an event handler for the parser to use while parsing an XML document. a.a. 2004/05 Tecnologie Web

71 Document Object Model (DOM)
a.a. 2004/05 Tecnologie Web

72 Trasformazioni XSLT Performing XSLT transformations requires an XSLT-compliant processor. The most popular open source XSLT engine for Java is the Apache Software Foundation’s Xalan project. Information about Xalan can be found at a.a. 2004/05 XSLT (eXtensible Stylesheet Language for Transformations) Tecnologie Web

73 Evoluzione delle soluzioni Microsoft
Strategic Planning Assumption: By 2007, Microsoft will evolve its enterprise architecture (now .NET) to a new vision of integrated real-time enterprise, substantially altering its initial set of middleware and tools (0.6 probability). Evoluzione delle soluzioni Microsoft ……. .NET DNA2000 Internet Network Computing COM+ DNA Loose Coupling MTS Enterprise Quality of Service DCOM Three-Tier Architecture COM Transactional Components Distributed Components Components Key Issue: What will be the technology evolution and business case for J2EE and .NET? .NET is the latest deliverable in Microsoft’s evolution from a vendor of desktop software to a vendor of distributed enterprise infrastructure. Microsoft has come a long way since the early days of COM and DCOM. .NET is the second time Microsoft has introduced radically new software infrastructure technology. The first was the introduction of Microsoft Transaction Server in Then a new programming model and much new technology was introduced, but the fundamental COM base was preserved. With .NET, the COM base, initially designed for the desktop and stretched to its limits to support enterprise computing, is now retired and replaced by the infrastructure of common language run-time. .NET represents a fundamental change in Microsoft enterprise computing software. Transition from COM/COM+ to .NET will take many years and will carry major transition costs, for vendors of Microsoft-based tools and for enterprises that own IT. On the other side of this process lie the benefits of Microsoft’s new vision of a loosely coupled distributed enterprise. However, Microsoft’s .NET vision is not yet fully jelled. New ideas and new application styles associated with the emerging integrated real-time enterprise will lead .NET to significant extensions and changes through Microsoft enterprise infrastructure will not reach maturity or slow down its pace of change until 2006. Action Item: Prepare for a lengthy and expensive transition to the still-evolving .NET. 1990s 2000s a.a. 2004/05 Tecnologie Web

74 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) a.a. 2004/05 Tecnologie Web

75 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 a.a. 2004/05 Tecnologie Web

76 Il Framework .Net System System.Data System.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 SessionState Caching Services Description Discovery Protocols UI HtmlControls WebControls System.Drawing Imaging Drawing2D Printing System.Windows.Forms ComponentModel a.a. 2004/05 Tecnologie Web

77 JVM e CLR a.a. 2004/05 Tecnologie Web

78 Executing a Managed Application
At execution time the IL and Metadata are JIT compiled SomeSources.exe IL Metadata Running Process’ Memory JIT Compiler Native Machine Language Sample Dialog: When a user executes a managed application, the system immediately loads the CLR unto the new processes. The CLR then begins JIT compiling the IL from the executable and executing it. It is not necessary for every IL instruction in an executable to be JIT compiled before it is run. This happens as needed, on a method-by-method basis. Once the code is running, it is run directly by the CPU. However, the JIT compiler emits code that insures that your program remains manageable by the CLR. So even though the code is running native, it is always managed code. The notion of managed code running in native machine language can be tough to comprehend. But the point is that it is IL until the point of running. It is the CLR that creates the machine language, so it has all of the control necessary to maintain the managed status of the software. The CPU executes the JIT- compiled machine code directly a.a. 2004/05 Tecnologie Web

79 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 a.a. 2004/05 Tecnologie Web

80 { Enterprise Services ASP.NET Enterprise Services ADO.NET
Gli Enterprise Services forniscono i servizi di MTS/COM+ (transazioni, pooling risorse...) ASP.NET Enterprise Services { ADO.NET a.a. 2004/05 Tecnologie Web

81 Hosting the .NET Framework CLR
ASP.Net Web Server Network Service-Client Managed Process ASP.Net ISAPI DLL Hosting the .NET Framework CLR SOAP Method Request XML Web Service objects Sample Dialog: Here is a birds-eye view of the ASP.Net model. Client software makes a soap request for a web service resource via HTTP sent to the server. [Click] The server notices that the request is for a resource with the .asmx extension, and passes the request to ASP.Net ISAPI DLL. [Click] The DLL hosts the runtime in process and creates managed objects, some built in, some custom, that marshall the request from soap into a method call [Click] and marshal return data from the call back into SOAP ASP.Net then sends the response back to IIS [Click] The web server sends the response back to the client software [click] and the client goes on its way, possibly making more requests, perhaps not. Speaker Instructions: This slide is animated to help tell the story. I have put [click]’s in where you might click the mouse. You should practice animated slides more than non-animated slides, because timing is important. SOAP Method Response a.a. 2004/05 Tecnologie Web

82 Esempio di Web Service con ASP.NET
DateService.asmx WebService Language="C#" Class="DateService" %> using System; using System.Web.Services; public class DateService:WebService{ [WebMethod] public String GetDateString() { return DateTime.Now.ToString("D"); } Sample Dialog: Web services are just C# or VB.Net code stored in a file with a .ASMX extension. The file is then stored in a virtual root where IIS can serve them to clients. The first time that an .ASMX file is served, it is compiled by ASP.Net, and then the binary object is executed. All successive requests skip compilation and just execute the methods in the binary object. ASP.Net manages the marshalling of parameters and return values to SOAP. Speaker Instructions: Servizi implementati in file .ASMX a.a. 2004/05 Tecnologie Web

83 Esempio di richiamo di un Web Service in .NET
DateClient.cs using System; class App{ public static void Main(){ DateService webObj = new DateService(); webObj.Url = " String dateString = webObj.GetDateString(); Console.WriteLine(dateString); } Sample Dialog: Meanwhile, if you use managed code top create a client it is similarly simple to creating a web service. This code shows a client that points to a web service on the internet. It simply performs the network communication by instantiating an object and calling a method. In this example, the DateService type is a proxy that was automatically generated from a WSDL description of a web service. . Simple model for network communication Object Instantiation Method Call DateService type is a proxy object a.a. 2004/05 Tecnologie Web

84 JWSDP Java Web Services Development Pack come infrastruttura per lo sviluppo di applicazioni Web-based Tecnologie di accesso a Database mediante JDBC gestione di XML gestione di applicazioni Server-side (Servlets, JSP) Gestione dei Web Services a.a. 2004/05 Tecnologie Web

85 JWSDP JAXP – processa documenti XML utilizzando diversi parsers
JAXB – permette la corrispondenza tra elementi XML a classi Java JAXM – invia messaggi SOAP su Internet in modo standard JAXR – permette di accedere ai business registries e condividere le informazioni JAX-RPC – invia chiamate a messaggi SOAP e riceve la risposta a.a. 2004/05 Tecnologie Web

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

87 Composizione di WS (I) Servizio composto: utilizza altri servizi per fornire il servizio richiesto Middleware per la composizione di servizi fornisce astrazioni e infrastrutture per la definizione ed esecuzione del servizio composto a.a. 2004/05 Tecnologie Web

88 Composizione di WS (II)
Esempio: supply chain Supply chain Supplier I contabilità fornitori Supplier II a.a. 2004/05 Tecnologie Web

89 Composizione di WS (III)
Modello e linguaggio di composizione ambiente di sviluppo Ambiente di esecuzione a.a. 2004/05 Tecnologie Web

90 Dimensioni del modello di composizione di WS
Modello delle componenti Modello di orchestrazione Modello dei dati e di accesso ai dati Modello di selezione Transazioni Gestione delle eccezioni a.a. 2004/05 Tecnologie Web

91 BPEL: Business Process Execution Language for Web Services
Linguaggio che supporta la specifica di composizione e coordinazione Specifiche per processo eseguibile per definire l’implementazione logica di un servizio composto Comportamento esterno del servizio e implementazione interna a.a. 2004/05 Tecnologie Web

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

93 Software Engineering Ciclo di vita del software OO Design e UML
a.a. 2004/05 Tecnologie Web

94 Avviamento e Manutenzione
Il Ciclo di Vita del Software (a cascata) Requisiti di Sistema validazione Requisiti Software Disegno di Sistema Disegno di Dettaglio Programmazione Unit Test Test Avviamento e Manutenzione Analysis Phase System Design Object Design Implementation Delivery & Maintenance a.a. 2004/05 Tecnologie Web

95 Esempio Waterfall Design dell’architettura Top-down design
Decidere il linguaggio di programmazione Decidere sul riuso Design delle interfacce dei moduli Tutte le decisioni di design devono essere giustificate chiaramente a.a. 2004/05 Tecnologie Web

96 Esempio Waterfall (cont.)
Detailed Design Design delle strutture dati e degli algoritmi dei moduli Codifica Tradurre il design dettagliato in codice Testing Test con dati tipici, dati errati Stress testing Manutenzione a.a. 2004/05 Tecnologie Web

97 Problemi del Waterfall
Non accade Progetti reali tendono a non seguire un flusso sequenziale Attività sono fatte opportunisticamente durante tutte le “fasi” Non prevede incertezza e modifica dei requisiti Like ordering with no chance to look around, compare prices, change your mind, etc. (McCracken and Jackson, 1981) Consegna solo alla fine (lunga attesa) a.a. 2004/05 Tecnologie Web

98 Quando il Waterfall funziona
Progetti molto semplici Progetti dove i requisiti sono stabili e orientati alla matematica e il sistema può essere testato facilmente Esempio: centrale nucleare a.a. 2004/05 Tecnologie Web

99 Prototyping “When a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time.” (Brooks, 1975) Modelli da eliminare utilizzati per capire I requisiti ed esporre i rischi Non devono essere basati sul codice (es., arta) a.a. 2004/05 Tecnologie Web

100 Natura del prototyping
Un approccio plan-based adatto a piccoli, agili sviluppi durante l’analisi dei requisiti a.a. 2004/05 Tecnologie Web

101 Prototyping Analisi dei requisiti Requisiti Prodotto ingegnerizzato No
Modifiche? Yes No Quick Design All is in the initial phase of requirement analysis. Raffinare Prototype Costruire Prototype Valutare Prototype (Pressman, 1996) a.a. 2004/05 Tecnologie Web

102 Problemi del Prototyping
Cliente vede una versione funzionante che può non essere costruita con qualità e manutabilità in mente e non capisce che deve essere gettata via E’ difficile da gettare via in ogni caso… Compromessi di implementazione utilizzati per veloci prototipi possono diventare parte della versione funzionante a.a. 2004/05 Tecnologie Web

103 Incrementale Forma originale: “Evolutionary delivery” (Gilb, 1988)
Sistema consegnato in pezzi, alta priorità viene prima Incrementi iniziali informano requisiti per futuri incrementi Dimensione degli incrementi varia (originalmente un massimo di alcune settimane) a.a. 2004/05 Tecnologie Web

104 Incrementale Def outline requisiti Assegn. requisiti agli incrementi
Design system architecture Svilup Increm sistema Validaz. Increment. Integraz Increment. Validaz. sistema Sistema Finale Sistema incompleto (Sommerville, 2001) a.a. 2004/05 Tecnologie Web

105 Extreme Programming (XP)
“Listening, Testing, Coding, Designing. That's all there is to software. Anyone who tells you different is selling something.” – Kent Beck Processo software evolutivo e Lightweight a.a. 2004/05 Tecnologie Web

106 XP Valori e Principi Principi base: 4 Valori: Feedback rapido
Assume semplicità Cambiamenti incrementali Abbraccia il cambiamento Lavoro di qualità 4 Valori: Semplicità Comunicazione Feedback Coraggio a.a. 2004/05 Tecnologie Web

107 XP Practices Planning game Releases corte Metafore Design semplice
Testing Refactoring Pair programming Proprietà collettiva Continuous integration Settimana di 40 ore Cliente On-site Standards di codifica a.a. 2004/05 Tecnologie Web

108 Extreme Programming (Wells, 2000) a.a. 2004/05 Tecnologie Web

109 UML per documentare le applicazioni three-tier
L’UML è un linguaggio di modellazione accettato come standard da importanti organizzazioni ed aziende (OMG e Microsoft fra le altre) particolarmente adatto alla descrizione di applicazioni three-tier e/o a componenti. Molte metodologie (per esempio Rational Unified Process) sono basate su UML UML è composto da una serie di formalismi, fra di essi citiamo quelli più utili a descrivere il progetto in esame: Use case diagrams Class diagrams Sequence diagrams Component diagrams Un articolo che spiega i passi dello sviluppo da UML a EJB cliccare qui a.a. 2004/05 Tecnologie Web

110 Componenti di UML a.a. 2004/05 Tecnologie Web

111 Use Case Diagrams Gli Use Case descrivono delle funzioni elementari viste dal punto di vista dell’utente finale L’elenco degli Use Case rappresenta l’intera copertura funzionale dell’applicazione Ogni Use Case può essere descritto con un testo allegato o con altri diagrammi (sequence e activity) che ne descrivono il comportamento dettagliato Input relationship data Customer Confirm Contract Receive Alert a.a. 2004/05 Tecnologie Web

112 Class Diagrams I class diagram rappresentano le componenti logiche dell’applicazione possono rappresentare: componenti grafiche, procedure, dati… le classi possono avere attributi e metodi associati <<servlet>> Login <<Session EJB>> <<Entity EJB>> <<Entity EJB>> 1..1 ContractManager Contract Customer 0..* <<servlet>> Update Contract Data Tier 1 Tier 2 Tier 3 a.a. 2004/05 Tecnologie Web

113 Sequence Diagrams I Sequence diagrams descrivono, per uno specifico use case, le interazioni che intervengono fra le classi Dai sequence diagrams si ottengono dati utili all’analisi delle comunicazioni in rete Realizzando sequence diagram per ogni use case dell’applicazione si certifica la completezza dei class diagram : Update Contract Data : Client : Contract Manager : Customer input new data update( ) setMaxAmount( ) sendAlert( ) Firewall http Firewall IIOP WS AS a.a. 2004/05 Tecnologie Web

114 Component Diagram I Component Diagram descrivono i moduli software che compongono l’applicazione Si possono descrivere le relazioni fra le classi e le componenti che implementano tali classi (interfacce) Dai component diagram alcuni strumenti CASE permettono la generazione di codice (Java, VB, C++ …) <<Entity EJB>> Contract Contract Contract Home a.a. 2004/05 Tecnologie Web

115 Un esempio: una Biblioteca Diagramma degli Use Case
Acquisizione nuovo libro o CD Restituzione Prestito di un libro o CD Utente Biblioteca Nuova iscrizione <<estende>> Bibliotecario a.a. 2004/05 Tecnologie Web

116 Descrizione dello Use Case “Prestito”
ACTOR: Bibliotecario PRECONDIZIONI: Un iscritto alla biblioteca si presenta per un prestito di un libro o CD DESCRIZIONE: L’iscritto può richiedere direttamente il titolo del libro o CD, nel caso non si ricordasse esattamente il titolo, può indicarne l’autore. Il bibliotecario effettua la ricerca e viene visualizzata una lista di libri o CD che possono essere presi in prestito e li propone all’iscritto. L’iscritto ne seleziona uno e lo chiede in prestito. Il bibliotecario va a reperire il libro o CD e registra l’effettuato prestito. ECCEZIONI: Il libro o CD non è disponibile in biblioteca: il prestito non viene effettuato. Il libro o CD è già in prestito: il prestito non viene effettuato. La persona richiedente non è ancora iscritto: il bibliotecario lo iscrive e poi continua l’operazione di prestito. L’iscritto ha già troppi libri o CD in prestito: il prestito non viene effettuato. POSTCONDIZIONI: Prestito effettuato: libro o CD esce dalla biblioteca. a.a. 2004/05 Tecnologie Web

117 Finestra “Ricerca” a.a. 2004/05 Tecnologie Web

118 Finestra “Prestito” a.a. 2004/05 Tecnologie Web

119 Diagrammma delle Classi
Libro Editore : String CD Casa_Discografica : String Prestito Data : Date Crea() ElencoIscritti NuovaIscrizione() RicercaIscritto() Iscritto Nome : String String NArticoli : Number NuovoPrestito() RilasciaPrestito() +Elenco_Iscritti +Iscritto Biblioteca OraApertura : Ora OraChiusura : Ora RicercaPerTitolo() RicercaPerAutore() ProdottoMultimediale Titolo : String Autore : String Locazione RichiestaDisponibilità() RendiIndisponibile() RendiDisponibile() +prestito prestito 1 * +appartiene appartiene a.a. 2004/05 Tecnologie Web

120 Sequence Diagram dello Use Case “prestito”
: Bibliotecario Universitaria : Biblioteca : Prodotto Multimediale : Finestra Prestito : Finestra Ricerca : Prestito : Iscritto : ElencoIscritti 1: Attiva finestra 2: RicercaPerAutore (String) 3: RicercaPerTitolo (String) 6: Attiva finestra 7: RicercaIscritto( ) 8: Crea ( ) 9: NuovoPrestito ( ) 10: RendiIndisponibile ( ) 11: conferma 5: lista 4: RichiestaDisponibilità ( ) alternativi a.a. 2004/05 Tecnologie Web

121 State Diagram di “Prodotto Multimediale”
Iniziale Eliminato In Acquisto Acquistato acquisto Registrato Disponibile In Prestito inventario catalogazione restituzione perdita prestito richiesta a.a. 2004/05 Tecnologie Web