Serv-JSP-CORBA

Internet Protocols and Applications I : 

Internet Protocols and Applications I Incheon Paik

Some Protocols : 

2 Some Protocols HTTP Communication Connectionless Communication Stateless Communication (1) TCP Connection Request (2) HTTP Request (3) HTTP Response (4) TCP Connection Close Client Server

Some Protocols : 

3 Some Protocols HTTP Message Start Line : Client Request Information / Response Status Information Message Header : Additional Information for HTTP Message such as Date, Program Name, Version, Cookie, User Authentication, Cache Message Body : Contents for Request or Response. In case of POST, Input data consists of data stream encoded in request message.

Some Protocols : 

4 Some Protocols Client Request Message in HTTP Request : HTTP Command, URI, and HTTP Version, Header Name:Header Value, Request Message Body HTTP Command : GET, HEAD, POST/ OPTIONS, PUT, DELETE, LINK, UNLINK, TRACE Server Response Message in HTTP Response Message : HTTP Version, Status Code, Code Description, Response Header, Response Message Body Response Status Code : (Reference 100-199), (Success 200-299), (Redirection 300-399), (Incomplete 400-499), (Server Error 500-599)

Some Protocols : 

5 Some Protocols HTTP Message Header HTTP Header : Used for transmitting any kinds of information between client and server, [Header Name : Blank Header-value] General Header : Client Request, Server Response, Cache setup, Connection, Date, etc Client Request Header : Client information and preferred data type, Accept Character set, encoding type, and authorization Response Header : Server Information, Message processing methods for response message. Web server information, Cookie setup, authenticate information. Entity Header : HTTP message body information, encoding method of message, contents length, MD5 information, encoding method of contents transmission, MIME type

Some Protocols : 

6 Some Protocols MIME Type As HTTP transmission deal with multimedia documents, pre-defined method to deal with that data by client should be described. MIME(Multipurpose Internet Mail Extension) Type Client : Using Accept Header, Clients can define their preferred media type Server : Describe MIME Type in Content-Type Header MIME Type form : Type/Subtype (ex: application/x-javascript) Standard MIME Type : Text, Multipart, Message, Application, Image, Audio, Video

CGI Communication : 

7 CGI Communication CGI(Common Gateway Interface) Transmit Messages by GET/POST Method Characteristics Extend Web Server, Dynamic Response, Only Install in Server Side Overhead, Security, Interactive pages, Cannot keep the connection : Problems Web Server CGI Program Processes Process 1 Process 1 Process 1

Extended CGI : 

8 Extended CGI ASP (Active Server Page) of Microsoft Combine HTML, Server side Script, and Server side Component Written in Jscript, VBScript, and run on IIS Server Can use COM Component Java Servlet and JSP Platform Independent, Safe and Effective Thread Service, Object Oriented Paradigm Easy to interoperate with Legacy Application JSP is similar to ASP, and provide HTML script language and JavaBeans Component Object Web CORBA (Common Object Request Broker Architecture) EJB (Enterprise JavaBeans) DCOM (Distributed Common Object Model)

Slide 9: 

9 Classic Web Application Architecture Ajax Architecture AJAX (Asynchronous JavaScript And XML)

Motivations of Servlet and JSP : 

10 Motivations of Servlet and JSP Faster than CGI (no process creation overhead) Java is Internet oriented Servlet API: Security Session support Code reuse and portability JDBC support Next step: Enterprise Java Beans (EJB) Slide 9-18, Used the Material by Philippe Rochat

Object Web : 

11 Object Web Web Server JSP Servlet EJB CORBA DBMS Legacy Application HTML/XML Applet HTTP HTTP RMI/IIOP IIOP

Servlet and Servlet Container : 

12 Servlet and Servlet Container Java Servlet API Servlet Application 1 Servlet Application 2 Servlet Application N Servlet Container 1 Servlet Container 2 Servlet Container N Servlet Container: - To run servlet, there need to be JVM to run Java servlet class and servlet container to provide servlet applications with system service. Deliver HTTP request of a client to servlet application, and HTTP response of the servlet applcation to the client

How-to Write Servlet : 

13 How-to Write Servlet Very Similar to applet Must inherits HttpServlet Must implements one of doGet doPost doPut … Receives HttpServletRequest HttpServletResponse

Life-Cycle : 

14 Life-Cycle Instantiation Init() Service() Done()

Session : 

15 Session public void doGet(HttpServletRequest request, HttpServletResponse response) HttpSession session = request.getSession(true); session.setAttribute(dataName, dataValue); Enumeration e = session.getAttributeNames();

Examples : 

16 Examples Refer to Apache Tomcat When you install Apache Tomcat, http://localhost:8080/servlets-examples/

Cookies : 

17 Cookies public void doGet(HttpServletRequest request, HttpServletResponse response) Cookie[] cookies = request.getCookies(); response.addCookie(c);

Pros and Con’s : 

18 Pros and Con’s Con’s HTML embedded in Java source file Pro’s Power of Java Platform Speed Portability across servers and DB’s

More … : 

19 More … At sun http://java.sun.com/products/servlet/index.html Apache http://jakarta.apache.org/tomcat/ Lbdpc15 TomCat documentation

Execution of JSP : 

20 Execution of JSP Web Browser A user requests .jsp file through URL. Web server requests JSP handler to process .jsp file JSP/Servlet container pass the corresponding .jsp file to JSP handler servlet JSP Handler Servlet Check JSP file, execute the existing .class servlet when no change When there was change, generate .java source code from .jsp Compile the java source when .class file was generated normally, execute the servlet. Web Server Servlet Container JSP Handler Servlet JSP Servlet JSP Request Handler Request JSP File (.jsp) Java File (.java) Class File (.class) JSP File Check JSP file Compile Java file Compile Servlet Invocation Class Loading

JSP : 

21 JSP Allows HTML embedded tags: <html> <jsp:useBean id="cart" scope="session" class="sessions.DummyCart" /> <jsp:setProperty name="cart" property="*" /> <% cart.processRequest(request); %> <FONT size = 5 COLOR="#CC0000"> <br> You have the following items in your cart: <ol> <% String[] items = cart.getItems(); for (int i=0; i<items.length; i++) { %> <li> <%= items[i] %> <% } %> </ol> </FONT> <hr> <%@ include file ="/jsp/sessions/carts.html" %> </html>

Examples : 

22 Examples Refer to Apache Tomcat When you install Apache Tomcat, http://localhost:8080/jsp-examples/

Introduction toCommon Object Request Broker Architecture(CORBA) : 

Introduction toCommon Object Request Broker Architecture(CORBA)

Contents : 

Contents Overview of distributed programming challenges Overview of CORBA architecture CORBA programming with Java ORB WWW, Java and CORBA GIOP and IIOP Trends in Internet

Introduction : 

25 Introduction Developing distributed applications whose components collaborate efficiently, reliabley, transparently, and scalably is hard. To help address this challenge, the Object Management Group(OMG) is specifying the CORBA OMG is a consortium of 700 more strong computer compaines and universities. Netscape, Sun, HP, DEC, Mircrosoft, IBM, Visigenic, IONA, etc.

History of OMG CORBA : 

26 History of OMG CORBA 1991 CORBA version 1.1 published 1992 - 1996 CORBA Core and Interoperability : Architecture & Communications 1994 CORBA 2.0 published, including Interoperable Specification 1994 - 1996 CORBAservices : Basic Services for Object-Oriented Application May, 1996 CORBA Task Force issues Secure Interoperability Protocol 1995 - CORBAfacilities : Application level Data Manipulation & Storage

History of OMG CORBA : 

27 History of OMG CORBA 1997 CORBA version 2.1 Identify Problems 1998 CORBA 2.2 Portable Object Adapter : Management of Lifetime Server Object, Portability CORBA 2.3 Object By Value 1999 CORBA 3 Internet Integration, QoS, CORBA Component Architecture

Source of Complexity : 

Source of Complexity Distributed application development exhibits both inherent and accidental complexity Inherent Complexity results from fundamental Challenges in the distributed application domain, e.g., Addressing the impact of latency Detecting and recovering from partial failures of networks and hosts Load balancing and service partitioning Consistent ordering of distributed events

Source of Complexity : 

29 Source of Complexity Accidental complexity results from limitations with tools and techniques used to develop distributed applications. Lack of type-safe, portable, re-entrant, and extensible system call interfaces and component libraries Inadequate debugging support Widespread use of algorithmic decomposition Fine for explaining network programming concepts and algorithms but inadequate for developing large-scale distributed applications Continuous rediscovery and reinvention of core concepts and components

Motivation for CORBA : 

Motivation for CORBA Simplifies application interworking CORBA provides higher level integration than traditional "untyped TCP byte streams " Provides a foundation for higher-level distributed object collaboration e.g., Windows OLE and the OMG Common Object Service Specification(COSS) Benefits for distributed programming similar to OO languages for non-distributed programming e.g., encapsulation, interface inheritance, and object-based exception handling

CORBA Contributions : 

CORBA Contributions CORBA addresses two challenges of developing distributed system: Making distributed application development no more difficult than developing centralized programs. Easier said than done due to : Partial failures Impact of latency Load balancing Event Ordering Providing an infrastructure to integrate application components into a distributed system i.e., CORBA is an "enabling technology"

CORBA Bank Example (Old Version) : 

CORBA Bank Example (Old Version) Ideally, to use a distributed service, we'd like it to look much like a non-distributed service : public static void main(String args[]) { Bank.AccountManager manager = Bank.AccountManager_var.bind(“My Bank"); Bank.Account account = manager.open(name); float balance = account.balance(); System.out.println ("The balance in " + name + "'s account is $" + balance); }

CORBA Bank Interface : 

CORBA Bank Interface We need to write an OMG IDL. Interface for our Bank object This interface is used by both clients and servers // Bank.idl module Bank { interface Account { float balance(); }; interface AccountManager { Account open(in string name); }; };

CORBA is Software Bus : 

CORBA is Software Bus CORBA provides a communication infrastructure for a heterogeneous, distributed collection of collaborating objects.

Related Works : 

Related Works Related technologies for application integration include : Traditional RPC Provides "procedural" integration of application serveices Doesn't provide object abstractions Does not address inheritance of interfaces Widows OLE/COM Traditionally limited to desktop application

CORBA Components : 

CORBA Components The CORBA specification is comprised of several parts : 1. An Object Request Broker (ORB) 2. Basic Object Adapter (BOA), Portable Object Adapter(POA) 3. An Interface Definition Language (IDL) 4. A Static Invocation Interface (SII) 5. A Dynamic Invocation Interface (DII) 6. A Dynamic Skeleton Interface(DSI) 7. Interface and implementation repositories 8. Programming language mappings 9. An Interoperability Spec(GIOP and IIOP) Other documents form OMG descirbe common object services built upon CORBAservices e.g. , Event services, Name services, Lifecycle service

CORBA Architecture : 

37 CORBA Architecture

CORBA Architecture : 

38 CORBA Architecture The ORB is the foundation of all other CORBA services and facilities

Object Request Broker : 

Object Request Broker The Object Request Broker(ORB) is the central component in CORBA An ORB provides mechanisms for invoking methods on local/remote objects ORB mechanisms automate : Object location, creation, activation and object management Message exchange between objects CORBA ORB provides security also.

Interface Definition Language (IDL) : 

Interface Definition Language (IDL) Developing flexible distributed applications on heterogeneous platforms requires a strict separation of interface from implementation(s) Benefits of using an IDL Ensure platform independence e.g., Windows NT to UNIX Enforce modularity e.g., must separate concerns Increase robustness e.g., reduce opportunities for network programming errors Enable language independence e.g., C, Smalltalk, COBOL to C++, Java

CORBA IDL : 

CORBA IDL OMG IDL is an object-oriented interface definition language Used to specify interfaces containing operations and attributes OMG IDL support interface inheritance (both single and multiple inheritance) OMG IDL is designed to map onto multiple programming languages e.g., C, C++, Smalltalk, COBOL, Modula 3, DCE, Java, etc. OMG IDL is similar to Java interfaces, class and C++ class

OMG IDL Compiler : 

OMG IDL Compiler A OMG IDL compiler generates client stubs and server skeletons Stubs and skeletons automate the following activities (in conjunction with the ORB) Client proxy factories Prameter marshalling/demarshalling Implementation class interface generation Object registration and activation Object location and binding

Producing IDL file, Client, and Object Implementation : 

43 Producing IDL file, Client, and Object Implementation

Application Interfaces : 

Application Interfaces Interfaces described using OMG IDL may be application-specific, e.g., Databases Spreadsheets Spell checker Network manager Air traffic control Documents Medical imaging systems Objects may be defined at any level of granularity e.g., from fine-grained GUI objects to multi-mega byte multimedia "Blobs"

OMG IDL Features : 

OMG IDL Features OMG IDL is a superset of C++, Java, etc. Note, it is not a complete programming language, it only defines interfaces OMG IDL supports the following features : Modules Interfaces Operations Attributes Inheritance Basic types(e.g., double, long, char, etc). Arrays Sequence Struct, enum, union, typedef Consts Exceptions

Static Invocation Interface(SII) : 

Static Invocation Interface(SII) The most common way of using OMG IDL involves the "Static Invocation Interface" (SII) In this case, all the methods are specified in advance and are know to the client and the server via proxies proxies are also known as surrogates The primary advantage of the SII is its simplicity, typesafety, and efficiency

Dynamic Invocation Interface (DII) : 

Dynamic Invocation Interface (DII) A less common way of using OMG IDL involves the "Dynamic Invocation Interface" (DII) The DII enables objects and their methods to be specified and called at run-time Uses meta-data stored in an "Interface Repository" The DII is more flexible than the SII apporach, e.g., It supports tools tools like a MIB browser that may not know all their components or operations at compile-time It also enables the use of deferred synchronous invocation The DII is also more complicated and less typesafe and efficient.

Dynamic Skeleton Interface (DSI) : 

Dynamic Skeleton Interface (DSI) The "Dynamic Skeleton Interface" (DSI) provides analogous functionality for the server-side that the DII provides on the client-side It is defined in CORBA 2.0 primarily for using building ORB "Bridges" The DSI lets server code handle arbitrary invocations on CORBA objects

Object References : 

Object References An "Object reference" is an opaque handle to an object Object references amy be passed among processes on separate hosts The underlying CORBA ORB will correctly convert object references into a form that can be transmitted over the network Presumably by converting it to a "stringfied" reference The ORB passes the receiver's implementation a pointer to a proxy in its own address space This proxy refers to the object's implementation Object references are a powerful feature of CORBA e.g., supports "peer-to-peer" interactions

Object Adaptor : 

Object Adaptor CORBA "object adaptors" provide services for binding object references to their associated object implementations Several types of object adaptors are available : Basic Object Adaptor(BOA) Objects and object references are known to the ORB Thus, an object implementation has to explicitly register objects to be activated Object-Oriented Database Adaptor(OODA) This adapter uses a connection to an o-o db to access the objects stored in it. Since the OODB provides the emthods and persistent storage, object may be registerd implicitly.

Object Adaptor : 

Object Adaptor Creation and Analysis of Object Reference Method Invocation Interaction Activation and Deactivation of Object and Implementation Matching to Object Implementation According to Object Reference Registration of Object Problem of BOA Inconsistency of Specification Difference of BOA Implementation Problem in Server Portability

Portable Object Adaptor : 

Portable Object Adaptor Allow the Persistent Object Allow more Object Implementation   Characteristics Map an Object Reference to the Servant that Implements that object Allow Transparent Activation of Objects Associate Policy Information With Objects Make a CORBA object persistent over several server process lifetimes Object ID Namespace Policy of Multi-Threading, Security, Object Management Multi POA with different policy and name space exist in a server

EXAMPLE : 

EXAMPLE Bank Example Bank server maintains the user's account Clients can request to open his account and to ask his balance via CORBA interfaces and CORBA run-time Since the server(s) and the clients are distributed, the solution must work across LAN and WAN environments

Initial OMG IDL Bank Specification : 

54 Initial OMG IDL Bank Specification // Bank.idl module Bank { interface Account { float balance(); }; interface AccountManager { Account open(in string name); }; };

Compiling the Interface Definition : 

Compiling the Interface Definition Running the Bank module definition through the IDL compiler generates client stubs and server skeletons The client stub acts as a proxy and handles object binding and parameter marshalling from requestor The server skeleton handles object registration, activation, and parameter demarshalling from target CORBA allows two ways to associate an object implementation to a generated IDL skeleton : 1. BOAImpl -> uses the Class form of the Adapter pattern(inheritance) 2. TIE -> uses the Object form of the Adapter pattern (object composition)

Object Activation, invocation by the BOA : 

56 Object Activation, invocation by the BOA

Main Server Program : 

Main Server Program Developer Can Register or Activate the Objects on Server according to Policy // Server.java import org.omg.PortableServer.*; public class Server { public static void main(String[] args) { try { // Initialize the ORB. org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null); // get a reference to the root POA POA rootPOA = POAHelper.narrow(orb.resolve_initial_references("RootPOA")); // Create policies for our persistent POA org.omg.CORBA.Policy[] policies = { rootPOA.create_lifespan_policy(LifespanPolicyValue.PERSISTENT) };

Main Server Program (Continued) : 

58 Main Server Program (Continued) // Create myPOA with the right policies POA myPOA = rootPOA.create_POA( "bank_agent_poa", rootPOA.the_POAManager(), policies ); // Create the servant AccountManagerImpl managerServant = new AccountManagerImpl(); // Decide on the ID for the servant byte[] managerId = "BankManager".getBytes(); // Activate the servant with the ID on myPOA myPOA.activate_object_with_id(managerId, managerServant); // Activate the POA manager rootPOA.the_POAManager().activate(); System.out.println(myPOA.servant_to_reference(managerServant) + " is ready."); // Wait for incoming requests orb.run(); } catch (Exception e) { e.printStackTrace(); } } }

A Client Program : 

59 A Client Program // Client.java public class Client { public static void main(String[] args) { // Initialize the ORB. org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null); // Get the manager Id byte[] managerId = "BankManager".getBytes(); // Locate an account manager. Give the full POA name and the servant ID. Bank.AccountManager manager = Bank.AccountManagerHelper.bind(orb, "/bank_agent_poa", managerId); // use args[0] as the account name, or a default. String name = args.length > 0 ? args[0] : "Jack B. Quick"; // Request the account manager to open a named account. Bank.Account account = manager.open(name); // Get the balance of the account. float balance = account.balance(); // Print out the balance. System.out.println ("The balance in " + name + "'s account is $" + balance); } }

Implementing the Object : 

60 Implementing the Object // AccountManagerImpl.java import org.omg.PortableServer.*; import java.util.*; public class AccountManagerImpl extends Bank.AccountManagerPOA { public synchronized Bank.Account open(String name) { // Lookup the account in the account dictionary. Bank.Account account = (Bank.Account) _accounts.get(name); // If there was no account in the dictionary, create one. if(account == null) { // Make up the account's balance, between 0 and 1000 dollars. float balance = Math.abs(_random.nextInt()) % 100000 / 100f; // Create the account implementation, given the balance. AccountImpl accountServant = new AccountImpl(balance);

Implementing the Object : 

61 Implementing the Object try { // Activate it on the default POA which is root POA for this servant account = Bank.AccountHelper.narrow(_default_POA().servant_to_reference(accountServant)); } catch (Exception e) { e.printStackTrace(); } // Print out the new account. System.out.println("Created " + name + "'s account: " + account); // Save the account in the account dictionary. _accounts.put(name, account); } // Return the account. return account; } private Dictionary _accounts = new Hashtable(); private Random _random = new Random(); }

Run Example : 

62 Run Example Activate OSAGENT Server Side <prompt> java Server Server Activation Client Side <prompt> java Client [Account Name] Client can receive the response from Server

OMG IDL Mapping Rules : 

OMG IDL Mapping Rules The CORBA specification defines mappings from CORBA IDL to various programming language e.g., C++, C, Java, Smalltalk Mapping OMG IDL to Java Each module is mapped to package Each interface within a module is mapped to abstract class or fully implemented class Each operation is mapped to a Java method with appropriate parameters Each read/write attribute is mapped to a pair of get/set methods A read-only attribute is only mapped to a single get method

Binding a Client to a Target Object : 

Binding a Client to a Target Object Three typical steps : 1. A CORBA client (requestor) obtains an "object reference" from a server e.g., May use a naming service or a locator service 2. This object reference serves as a local proxy for the remote target object 3. The client may then invoke methods on its proxy Recall that object references may be passed as parameters to other remote objects

Experiences with Java ORBs : 

65 Experiences with Java ORBs ORB Interoperability Visigenic’s Black Widow(now, VisiBroker) supports the CORBA 2.0 IIOP DSTC provide a permanent ORB Interoperability showcase Java language binding for CORBA Development time can be significantly reduced when using Java instead of C++ Portability Java ORB profit from Java portability Performance Now, Java ORBs do not perform very well(about 20 times longer) But, faster compiler (e.g., Just-in Time Compiler) will solve it Applet clients vs. CGI based clients Middleware advantages automatic generation of stub code separating interfaces from implementations automatic type checking

Internet Inter-ORB Protocol(IIOP) : 

66 Internet Inter-ORB Protocol(IIOP) Interoperability Via ORB-to-ORB ORB Interoperability Architecture Example of CORBA 2.0 Interoperability Interoperable Object Reference General Inter-ORB Protocol(GIOP) Internet Inter-ORB Protocol (IIOP)

Interoperability Via ORB-to-ORB : 

67 Interoperability Via ORB-to-ORB All of the clients connected to ORB 1 can access object implementations in both ORB 1 and ORB 2 The same condition holds for clients connected to ORB 2 This architecture scales to any number of connected ORBs

Interoperability via ORB-to-ORB : 

68 Interoperability via ORB-to-ORB

ORB Interoperability Architecture : 

69 ORB Interoperability Architecture Immediate bridging two domains talk directly to each other over a single bridge that translate whatever parts of the message require it. fast and efficient but inflexible and require a lot of bridges Mediated bridging All domains bridge to a single common protocol common protocol is IIOP the number of bridge types only grows as fast as the number of different domains. this conforms to the backbone configuration of most large, multiprotocol networks; mediated bridging configures naturally in these networks.

Example of CORBA 2.0 Interoperability : 

70 Example of CORBA 2.0 Interoperability

Interoperable Object Reference (IOR) : 

71 Interoperable Object Reference (IOR) Specialized Object Reference Be used by an application in the exact same way that an object reference is used allows an application to make remote method calls on a CORBA object An application which obtain IOR, it can access the remote CORBA object via IIOP The application constructs a GIOP message and sends it The IOR contains all the information needed to route the message directly to the appropriate server

General Inter-ORB Protocol (GIOP) : 

72 General Inter-ORB Protocol (GIOP) Goal Widest possibility, availability, Simplicity, Scalability, Lowcost, Generality, Architectural neutrality GIOP consists of three specification The Common Data Representation (CDR) definition Trasnfer syntax, mapping from data types defined in OMG IDL to a bicanonica, low-level representation for transfer between agents. SPEC takes into account byte ordering and alignment

General Inter-ORB Protocol (Continued) : 

73 General Inter-ORB Protocol (Continued) GIOP message formats carry requests, locate object implementations, and manage communication channels. Message Header include magic number, version number, byte order, message type, message size Seven Messages Be sent by the client : Request, CancelRequest, LocateRequest Be sent by Server : Reply, LocateReply, CloseConnection Both may send : MessageError

General Inter-ORB Protocol (Continued) : 

74 General Inter-ORB Protocol (Continued) GIOP transport requirements a connection-oriented protocol reliable delivery (byte order must be preserved, and acknowledgment of delivery must be available) participants must be notified of disorderly connection loss the model of initiating a connection must meet certain requirements

Internet Inter-ORB Protocol (IIOP) : 

75 Internet Inter-ORB Protocol (IIOP) The mapping of the GIOP message transfer to TCP/IP connections is called IIOP GIOP can map to Novell IPX and OSI also TCP/IP Connection Usage Servers must listen for connection requests. A client needing a object’s services must initiate a connection with the address specified in the IOR, with a connection request The listening server may accept or reject the connection. Once a connection is accepted, the client may send Request, LocateRequest, or CancelRequest messages by writing to the TCP/IP socket it owns for the connection.

CORBA Common Services : 

76 CORBA Common Services Basic Services to build distributed object system Naming, Event, Persistence, Life Cycle, Concurrency, Externalization, Relation, Transaction, Timing, License, Security,Property, Query, Trader, Collection, Startup, Interface type Version Management Services

CORBA Common Facilities : 

77 CORBA Common Facilities Software Components to provide some application function Horizontal facilities, Vertical facilities Horizontal facilities : Compound Presentation, Compound Interchange, Internalization, Time Operations, Mobile Agent, System Management Vertical facilities : Healthcare, Financial Facilities.