4Come realizzare una componenteStrategic 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 componenteDataCodeProxy / WrapperDataExt. method….DataInt. Method...CodeTraditionalObj.Obj.Obj.Obj.Source: Gartner ResearchComponents 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.OOa.a. 2004/05Tecnologie Web

28Applicazioni 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 J2EEEntityBeanDBMSAppletJSPServletSessionBeanMessage-DrivenBeanQBrowserJ2MEJCAResourceManagerERPJ2EE 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.CICSa.a. 2004/05DesktopTecnologie WebServer

35Formati di deployment J2EEJ2EE 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/05Tecnologie Web

50Service-oriented or Event-drivenDecision 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 InteractionUses interface metadataOne-to-one connectionsClient directs flowLinear path of executionClosed to unforeseen input once a flow is startedClientServerInterface proxyInterface stubEvent-driven NotificationUses event descriptor metadataMany-to-many connectionsSink (recipient) determines flowDynamic, parallel, asynchronous flowsCan react to new external input while process is in flightSourceEventSinkSOA 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/05Tecnologie Web

51Dalle procedure ai serviziWeb ServicesServicesComponentsGranularityScopeB2B Market,Global EnterpriseCoarseObjectsHTTP+SOAPMOMORBTypical Access viaSmall Enterprise,Complex ApplicationHomogeneous ApplicationProgramTighterLooserCouplingProceduralCallSource: Gartner ResearchE-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/05Tecnologie Web

52La complessità dei sistemi informativi aziendali nasce dalla sovrapposizione nel tempo delle soluzioniStrategic 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-actionfileFTPORBlMessageGatewayAPPCCICS gatewayORBqueueDown-loadHTTP/XMLScreen scrapeSocketsRPCSource: Gartner Researcha.a. 2004/05Tecnologie Web

54Service 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 integrazioneKey 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/05Tecnologie Web

55SOA: il sistema informativo organizzato a ServiziTactical 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.CustomerBillingA/RInventoryOrdersElemental Services/Business ObjectsGet InventoryUpdate InventoryGet OrdersUpdate OrdersGetID No.Get AddressChange AddressUpdate BillingGetBalanceComposite Services/Process ObjectsInquireOrdersEnterOrderInquireBalanceOpen AccountCall CenterB2C RetailB2B SalesBatch ClientClient ApplicationsKey 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.Browsera.a. 2004/05Tecnologie Web

56Service-Oriented Architecture : The architecture of interfacesDefinition: Design of Service-oriented systems is design of service interfaces and of service interactionsService-Oriented Architecture : The architecture of interfacesServiceSoftware component that is a business-complete logical unit of work, accessible programmatically from independently designed contexts via a direct openly documented interfaceService InterfaceService ImplementationSOAApplication software topology consisting of services and service consumers (clients) in loosely coupled 1-to-1 relationshipsService Consumer (Client)Interface proxyInterfaceA 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 implementationsSOA 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/05Tecnologie Web

57Service Implementation: What Happens Behind The InterfaceStrategic 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 InterfaceAll-New ServiceWrapped ServiceService ConsumerComposite ServiceA 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 implementationsService interfaceService implementationNon-SOA applicationsa.a. 2004/05Tecnologie Web

58Flussi di esecuzione Service Oriented Event Driven Client 1 Server 1Decision Framework: EDA is decoupled; asynchronous SOA is loosely coupled; synchronous SOA is somewhat coupled; and monolithic (non-SOA) applications generally are tightly coupled.Client 1Service OrientedServer 1Server 2/Client 2Server 3Server 4Module 4Event 1Module 1ForkEvent 2Module 3Event DrivenJoinModule 5Event 3An 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 2a.a. 2004/05Tecnologie Web

59Funzioni di un Integration BrokerStrategic 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).BusinessActivityMonitorEvent and StateMonitoringMetadata Management Development ToolsSecurity and DirectoryManagement ToolsProcess ManagerBusiness Process ManagementTransformationIntelligent RoutingMessage BrokerMessaging, Gateways, File TransferCommunication, Data MovementKey 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/05Tecnologie Web

63Abstract ImplementationStrategic 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).WSDLAbstract ImplementationWSDL allows Web services to be self-describing.A WSDL document includes nine basic XML elements:Port TypeOperationMessages<types> …</types><parts> …</parts>Five abstract elements — port type, operation, message, part and typeThree concrete elements — service, port and bindingOne definition element — provides definitions relating to the service.Maps ToBindingAssociated WithPortProtocolKey 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 PointEnd Pointa.a. 2004/05Tecnologie Web

64WSDL Document ElementsKey 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/05Tecnologie Web

65UDDI Registry Data StructuresKey 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/05Tecnologie Web

66Mapping WSDL to UDDI Business Entity UDDI tModel RegistrationStrategic 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 EntityUDDIRegistrationFiletModelBusiness ServiceBindingTemplateFindsPoints ToPoints ToService ImplementationService InterfaceImportImportsImportWSDLFileServiceTypesPortMessagePortTypeKey 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.Bindinga.a. 2004/05Tecnologie Web

70Simple 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/05Tecnologie Web

72Trasformazioni XSLTPerforming 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 ata.a. 2004/05XSLT (eXtensible Stylesheet Language for Transformations)Tecnologie Web

73Evoluzione delle soluzioni MicrosoftStrategic 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……..NETDNA2000Internet Network ComputingCOM+DNALoose CouplingMTSEnterprise Quality of ServiceDCOMThree-Tier ArchitectureCOMTransactional ComponentsDistributed ComponentsComponentsKey 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.1990s2000sa.a. 2004/05Tecnologie Web

78Executing a Managed ApplicationAt execution time the IL andMetadata are JIT compiledSomeSources.exeILMetadataRunning Process’ MemoryJIT CompilerNativeMachine LanguageSample 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 directlya.a. 2004/05Tecnologie Web

81Hosting the .NET Framework CLRASP.NetWeb ServerNetworkService-ClientManaged ProcessASP.Net ISAPI DLLHosting the .NET Framework CLRSOAP Method RequestXML Web Service objectsSample 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 SOAPASP.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 Responsea.a. 2004/05Tecnologie Web

82Esempio di Web Service con ASP.NETDateService.asmxWebService 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 .ASMXa.a. 2004/05Tecnologie Web

83Esempio di richiamo di un Web Service in .NETDateClient.csusing 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);}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 communicationObject InstantiationMethod CallDateService type is a proxy objecta.a. 2004/05Tecnologie Web

99Prototyping“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 rischiNon devono essere basati sul codice (es., arta)a.a. 2004/05Tecnologie Web