1
00:00:00,180 --> 00:00:00,720
Bienvenidos.

2
00:00:00,750 --> 00:00:02,940
Vamos a ver la introducción a Lápiz Cetelem.

3
00:00:03,180 --> 00:00:03,900
De qué se trata?

4
00:00:03,970 --> 00:00:09,660
Bueno, el happy select o el select en sí es una clase, un objeto de Java que se utiliza para crear

5
00:00:09,750 --> 00:00:15,700
una página web, pero una página web dinámica que tiene características del protocolo HTTP.

6
00:00:15,810 --> 00:00:22,860
Es decir, se encarga de procesar un request, lo maneja y por supuesto, también de acuerdo al procesamiento

7
00:00:22,860 --> 00:00:24,750
que se realiza, devuelve una respuesta.

8
00:00:24,840 --> 00:00:27,180
Otra característica es que son manejado.

9
00:00:27,300 --> 00:00:32,220
Esto significa que se crean por el contenedor de Cerler, que también se le conoce como contenedor web.

10
00:00:32,370 --> 00:00:35,820
Se crean, se almacenan y tienen un ciclo de vida.

11
00:00:35,910 --> 00:00:39,240
Este ciclo de vida manejado por este contenedor que después vamos a ver.

12
00:00:39,330 --> 00:00:46,170
Otra característica importante que son mapeados os asigna a una ruta wireless para que después, mediante

13
00:00:46,170 --> 00:00:53,670
un navegador web o un cliente HTTP podamos acceder a un select y realizar una petición y haga un procesamiento.

14
00:00:53,790 --> 00:00:55,730
Bien, veamos cómo funciona el Saleta.

15
00:00:55,980 --> 00:01:02,520
Vamos a tener un cliente, por ejemplo, un navegador con contenido HTML, un HTML estático o bien una

16
00:01:02,520 --> 00:01:03,060
JSP.

17
00:01:03,150 --> 00:01:04,320
Incluso puede ser otros, otros.

18
00:01:04,830 --> 00:01:09,720
Se muestra en pantalla esta información y el usuario va a interactuar con esta página.

19
00:01:09,810 --> 00:01:11,940
Va a realizar algún tipo petición.

20
00:01:12,000 --> 00:01:18,600
Esto puede ser mediante un enlace wireless haciendo clic en una ruta °l enviando parámetros, pero también

21
00:01:18,600 --> 00:01:24,160
puedes enviar tu formulario llenando campos y enviando este formulario se envía al servidor.

22
00:01:24,210 --> 00:01:25,460
Pero quién maneja?

23
00:01:25,470 --> 00:01:26,730
Quién procesa?

24
00:01:26,820 --> 00:01:28,410
Esta información es el SELECT.

25
00:01:28,530 --> 00:01:29,990
Es decir, todo pasa por Starlet.

26
00:01:30,210 --> 00:01:35,460
Bueno, por detrás de escena hay un From Controller que se encarga de manejar los Arlett y según la

27
00:01:35,460 --> 00:01:42,180
ruta °l del request va a asignar el cerle correspondiente que está mapeado a esa ruta va a obtener estos

28
00:01:42,180 --> 00:01:44,460
parámetros que son enviados por este cliente.

29
00:01:44,490 --> 00:01:49,790
Parámetros http mediante el objeto http select rickles.

30
00:01:49,920 --> 00:01:54,780
Después vamos a ver más en detalle, pero lo importante es que el usuario puede enviar parámetros y

31
00:01:54,780 --> 00:01:57,030
el SELECT lo recibe y lo procesa.

32
00:01:57,180 --> 00:02:02,850
De acuerdo a estos parámetros va a realizar algún tipo de tarea, por ejemplo, algún acceso a la base,

33
00:02:02,850 --> 00:02:06,270
datos, lógica, negocio o algún cálculo matemático.

34
00:02:06,420 --> 00:02:10,830
Y de acuerdo, eso va a devolver una respuesta al cliente, típicamente un objeto.

35
00:02:10,920 --> 00:02:15,150
Y ese objeto se muestra en esta plantilla, por ejemplo.

36
00:02:15,270 --> 00:02:21,840
JSP Pero también, no solamente muestra información en el navegador como respuesta como resultado,

37
00:02:21,960 --> 00:02:27,690
sino que también podría redirigir hacia otro saddle o o hacia otro JSP.

38
00:02:27,870 --> 00:02:31,470
Es decir, podría redireccionar la respuesta a otro recurso.

39
00:02:31,650 --> 00:02:37,230
Bien, veamos una característica importante que es el contexto MVC con el API Select.

40
00:02:37,230 --> 00:02:42,240
También podemos implementar un patrón m%s donde toda la responsabilidad es decir, el flujo de nuestra

41
00:02:42,240 --> 00:02:44,730
aplicación cae por shores, select y select.

42
00:02:44,820 --> 00:02:50,520
Se encarga de maquinar todo, de manejar las peticiones del usuario que le están llegando.

43
00:02:50,610 --> 00:02:56,280
manejà respuesta, pero entre medio tiene que realizar alguna tarea o interactúa con la persistencia

44
00:02:56,310 --> 00:03:02,700
con lógica negocio, con consultas según los parámetros que envía el usuario y obtiene un resultado

45
00:03:02,910 --> 00:03:05,520
del servicio de la lógica de negocio.

46
00:03:05,650 --> 00:03:08,370
Ese resultado generalmente es un objeto de modelo.

47
00:03:08,460 --> 00:03:14,160
Puede ser un POJO, un objeto que contiene los datos de una aplicación con atributo método quieten setter.

48
00:03:14,250 --> 00:03:19,890
También se le conoce como lo llama Vinz y como respuesta se lo devuelve al cliente.

49
00:03:20,070 --> 00:03:20,580
En la respuesta.

50
00:03:20,610 --> 00:03:27,030
Pero esta respuesta sería una vista JCP separado y eso es separación de roles, separación entre el

51
00:03:27,030 --> 00:03:32,790
controlador, el celeste de nuestro controlador, el modelo o el resultado que devuelve la lógica negocio

52
00:03:32,920 --> 00:03:37,200
el el service, por ejemplo, y la vista HTML es el JSP.

53
00:03:37,380 --> 00:03:43,950
Había explicado que un SALDE también puede tener HTML embebido, es decir, dentro de la misma clase

54
00:03:44,040 --> 00:03:49,850
en código Java mediante el objeto print greater podemos guardar contenido en la repuesta contenido HTML

55
00:03:49,950 --> 00:03:54,450
y es decir que el SELECT hace papel de vista y controlador al mismo tiempo.

56
00:03:54,600 --> 00:03:56,910
Eso se puede hacer ahora no recomendado.

57
00:03:57,030 --> 00:04:03,870
Lo mejor es separar los roles y llevar todo el HTML a una JSP a un archivo separado que se encargue

58
00:04:03,870 --> 00:04:07,200
solamente de la presentación de manejar este código HTML.

59
00:04:07,410 --> 00:04:10,600
Además, hace mucho más amistoso, mucho más fácil de manejar html.

60
00:04:10,800 --> 00:04:18,120
Claro, porque si estamos utilizando HTML con Java dentro del SELECT, todo mezclado anidado se fijan

61
00:04:18,220 --> 00:04:24,360
o se hace muy difícil manejar porque tenemos que concatenar el HTML con otras variables y también es

62
00:04:24,360 --> 00:04:26,520
poco manteni dible en el tiempo.

63
00:04:26,760 --> 00:04:29,190
Bien, veamos un repaso del rico y el repost.

64
00:04:29,280 --> 00:04:35,130
Yo sé que lo vimos, lo vimos en la introducción del protocolo HTTP, pero acá lo vamos a ver más orientado

65
00:04:35,220 --> 00:04:35,970
a la PÍSALE.

66
00:04:36,060 --> 00:04:41,490
Bueno, ya vimos lo que es un rico es una petición web, una solicitud, información que es enviada

67
00:04:41,580 --> 00:04:46,320
desde un cliente, típicamente un navegador, pero también podría ser, por ejemplo, una aplicación

68
00:04:46,380 --> 00:04:51,570
en Android, una aplicación con algún frontend JavaScript como Angular, como React.

69
00:04:51,690 --> 00:04:52,140
Se fijan?

70
00:04:52,350 --> 00:04:56,700
Bueno, da lo mismo, pero envía información desde un cliente hacia el servidor.

71
00:04:56,790 --> 00:04:59,640
Este servidor, un contenedor web, por ejemplo Tomcat.

72
00:05:00,030 --> 00:05:05,910
Sitios de aplicaciones recibe este request y según el for controllers según la ruta jureles que te tapiada

73
00:05:06,000 --> 00:05:11,820
los deriba a un starlet, exhalen maneja este request, lo procesa y más de lo mismo, más de lo que

74
00:05:11,820 --> 00:05:12,600
hemos hablado.

75
00:05:12,690 --> 00:05:19,650
También dentro del request están los datos o parámetros que envía, que ingresa el usuario mediante

76
00:05:19,650 --> 00:05:28,620
una ruta °l en una petición http get o mediante un formulario una petición http post.

77
00:05:28,770 --> 00:05:35,310
También es request maneja cabeceras las cabeceras http que también en metadata esa información del cliente.

78
00:05:35,430 --> 00:05:36,690
Eso también lo Bhima ven?

79
00:05:36,750 --> 00:05:43,470
Y la respuesta es lo que el servidor devuelve al cliente una vez que se procesa el recuestas típicamente.

80
00:05:43,500 --> 00:05:49,310
Pues el texto en formato HTML o texto plano también puede ser Jason.

81
00:05:49,350 --> 00:05:55,650
Si trabajamos con API, rest, xml o datos binario alguna imágenes, video, pdf, un exel.

82
00:05:55,770 --> 00:05:56,110
En fin.

83
00:05:56,190 --> 00:06:02,040
Pero también tenemos las cabeceras de la respuesta donde va el tipo contenido el content type.

84
00:06:02,280 --> 00:06:05,970
También está el estado de la respuesta el http status.

85
00:06:06,090 --> 00:06:09,210
Se acuerdan los código 200 cuando todo sale bien?

86
00:06:09,270 --> 00:06:12,530
404 cuando no existe la página web.

87
00:06:12,720 --> 00:06:14,610
El recurso cuando nos encuentra.

88
00:06:14,610 --> 00:06:15,870
Por ejemplo el select.

89
00:06:16,020 --> 00:06:19,560
Ahora veamos los métodos http soportados por el Ãpice atleta.

90
00:06:19,710 --> 00:06:20,400
Son 7.

91
00:06:20,490 --> 00:06:21,570
Acá tenemos la lista.

92
00:06:21,690 --> 00:06:27,240
Lo más típico cuando trabajamos con API Rest, por ejemplo el Dilek, el GET, el post y el put@ son

93
00:06:27,240 --> 00:06:33,690
los 4 principales en API Rest en edad písale son implementado dentro de la clase servlet de la clase

94
00:06:33,780 --> 00:06:36,780
http halder con los métodos dú algo.

95
00:06:36,840 --> 00:06:37,920
Por ejemplo Nugget.

96
00:06:38,130 --> 00:06:39,320
Grupos Dudek.

97
00:06:39,900 --> 00:06:44,580
AR Claro, esos son cuando trabajamos con API rest, pero en una aplicación web común y corriente.

98
00:06:44,700 --> 00:06:48,240
Típicamente vamos a trabajar con Tom-Tom, con el sujeto y con el post.

99
00:06:48,390 --> 00:06:54,480
Ahora estos métodos se llaman de forma automática mediante el método cervesa y de acuerdo al tipo de

100
00:06:54,480 --> 00:06:54,990
request.

101
00:06:55,110 --> 00:07:00,240
Si se envía un tipo GET va invocar de forma automática el método Nugget.

102
00:07:00,480 --> 00:07:03,270
Ahora, si la petición viene de un formulario.

103
00:07:03,330 --> 00:07:08,250
Por lo tanto proviene de un tipo post, va a ejecutar el método rupos.

104
00:07:08,370 --> 00:07:14,600
Si mediante una jureles va a seguir este flujo http rico en GET se llama el service.

105
00:07:14,670 --> 00:07:16,470
El server deriva al Huguette.

106
00:07:16,650 --> 00:07:18,660
El luge devuelve la respuesta al service.

107
00:07:18,750 --> 00:07:23,310
El servidor devuelve la respuesta al cliente, al navegador y la muestra pantalla.

108
00:07:23,370 --> 00:07:29,160
Si es un rico es del tipo post lo mismo, pero el service va a embocar en método rupos.

109
00:07:29,250 --> 00:07:36,030
El Dupont va a procesar el formulario o el contenido que se envía en el cuerpo del request y lo va a

110
00:07:36,030 --> 00:07:36,480
devolver.

111
00:07:36,600 --> 00:07:39,380
Se fijan al service y el service al usuario.

112
00:07:39,510 --> 00:07:42,960
No se preocupen, pero todo esto tema quizás sea un poco abstracto.

113
00:07:43,080 --> 00:07:46,140
Lo vamos a ver durante el curso ya con ejemplo, con código.

114
00:07:46,260 --> 00:07:51,030
No me gusta repetir mucho las cosas que digo, pero a veces lo hago porque para evitar problemas, errores,

115
00:07:51,030 --> 00:07:51,480
típico.

116
00:07:51,570 --> 00:07:54,870
Pero el método service nunca lo tenemos que sobrescribir.

117
00:07:54,960 --> 00:08:01,200
De la clase hates debe ser Lett, porque él se encarga de llamar a los métodos de la petición a los

118
00:08:01,200 --> 00:08:06,540
métodos http Nugget o Dupont, o lo que sea, de forma automática él lo maneja.

119
00:08:06,600 --> 00:08:09,400
Si los orcs vivimos no se van a llamarlo metodo U.G.T.

120
00:08:09,480 --> 00:08:11,400
Ni mi post no va a funcionar correctamente.

121
00:08:11,550 --> 00:08:17,580
Entonces, si queremos manejar una petición con Salde, lo que vamos a sobrescribir a implementar van

122
00:08:17,580 --> 00:08:22,420
a ser los métodos dú get tu post o dú algo, pero no el service.

123
00:08:22,650 --> 00:08:23,160
Continuemos.

124
00:08:23,190 --> 00:08:27,900
Veamos un poco la estructura de las clases e interfaces de la pisarlas.

125
00:08:28,200 --> 00:08:33,180
Bueno, la clase principal y con la que vamos a trabajar y con implementemos nuestro propio Arlett,

126
00:08:33,300 --> 00:08:39,690
vamos a tener que heredar de esta clase de http select en la clase más importante, pero no es la única

127
00:08:39,720 --> 00:08:45,200
porque tenemos generic select que es una clase tracta, la cual hereda http select.

128
00:08:45,540 --> 00:08:51,300
Y luego tenemos la interface Arlett, que es una interfaz con métodos por supuesto sin implementar.

129
00:08:51,450 --> 00:08:58,230
Protocolo de implementación como el método init, el método service y el método Destroy son los métodos

130
00:08:58,320 --> 00:08:59,010
más importante.

131
00:08:59,100 --> 00:09:03,600
Hay otros más, pero esos tres son lo más importante porque representan el ciclo de vida.

132
00:09:03,750 --> 00:09:04,640
La clase generics.

133
00:09:04,650 --> 00:09:08,890
El le da una pequeña implementación al init y al distraido.

134
00:09:09,060 --> 00:09:11,550
Pero obviamente nosotros podríamos sobrescribir.

135
00:09:11,550 --> 00:09:14,220
Es un método irra implementarlo a nuestra forma.

136
00:09:14,370 --> 00:09:19,800
Después vamos a ver que el método init es para inicializar el stadler y el distraido es para destruir

137
00:09:19,920 --> 00:09:22,800
o cerrar el Cerler para terminar con el ciclo de vida.

138
00:09:22,920 --> 00:09:28,740
Y el método servis es un método abstracto en la clase generics Selden no tiene implementación.

139
00:09:28,830 --> 00:09:35,010
Quien implementa este método servis https: Arlett le da una implementación tal como ha dicho hace poco,

140
00:09:35,070 --> 00:09:39,720
según el tipo de petición o el http método.

141
00:09:39,840 --> 00:09:46,170
Si es get o post se encarga de llamar a los método Bullet Dupont do put respectivamente.

142
00:09:46,320 --> 00:09:50,280
Por lo tanto, nosotros nunca vamos a sobrescribir el service jamás.

143
00:09:50,370 --> 00:09:53,400
Solamente vamos a implementar los métodos dú algo.

144
00:09:53,550 --> 00:09:59,370
Luego el https: arlett trabaja con el https: el let response para la respuesta.

145
00:09:59,880 --> 00:10:07,380
Rickles para la solicitud y a su vez cada uno de todos implementa la interfaz Saddle Request y Celle

146
00:10:07,380 --> 00:10:07,920
ripostó.

147
00:10:08,370 --> 00:10:14,220
Pero de esto lo único que me interesa es que la clase principal es el http Selden, en la cual nosotros

148
00:10:14,220 --> 00:10:20,730
vamos a heredar de esta ya sobrescribir los métodos Duckie Odú Post y por último, veamos el ciclo de

149
00:10:20,730 --> 00:10:21,750
vida de un celler.

150
00:10:21,900 --> 00:10:26,250
Bien, cuando implementamos un Saler, bueno, vamos a compilar nuestra aplicación.

151
00:10:26,400 --> 00:10:32,340
Vamos a realizar el despliegue en Tomcat o en un servidor de aplicaciones y automáticamente estos Hallet

152
00:10:32,400 --> 00:10:38,820
que están en nuestra aplicación se van a registrar en el contenedor de Tomcat en un contenedor web o

153
00:10:38,820 --> 00:10:44,070
de Stadler como se le llama entonces se registra, se almacenan y dentro se maneja el ciclo de vida.

154
00:10:44,160 --> 00:10:50,070
Una vez que se registran, se le invoca el método init, pero una sola vez es para inicializar el servlet

155
00:10:50,250 --> 00:10:54,690
se llama una sola vez dentro de todo el ciclo de vida y muy parición constructor.

156
00:10:54,780 --> 00:11:00,420
En el fondo podemos inicializar algunos parámetros de configuración, alguna conexión que necesitemos.

157
00:11:00,420 --> 00:11:01,830
Se fijan algo por el estilo.

158
00:11:01,950 --> 00:11:06,660
Después de que se realiza una petición, no es que se cree un shell de nuevo?

159
00:11:06,690 --> 00:11:07,560
No, para nada.

160
00:11:07,680 --> 00:11:11,460
El chalet es compartido por toda la aplicaciones y por todos los clientes.

161
00:11:11,550 --> 00:11:12,480
Es como un singleton.

162
00:11:12,540 --> 00:11:18,960
Va a estar prácticamente durante el tiempo que va a estar nuestra aplicación desplegada en el servidor.

163
00:11:19,050 --> 00:11:24,990
Pero lo que si cada vez que se realiza un rico test se genera un hilo o un proceso separado del resto

164
00:11:25,110 --> 00:11:29,130
por cada request, es un único hilo independiente a los demás.

165
00:11:29,280 --> 00:11:36,390
Y acá se invoca el método service y por cada uno se a pasar un objeto nuevo y también único del Rickert

166
00:11:36,540 --> 00:11:37,320
y del Response.

167
00:11:37,500 --> 00:11:40,440
Por cada cliente, por cada usuario que realiza una petición.

168
00:11:40,590 --> 00:11:42,360
Se pasa por argumento en el service.

169
00:11:42,510 --> 00:11:49,410
El método service obtiene el request, el response y lo va a derivar al Bullet o al Dupont o al método

170
00:11:49,410 --> 00:11:50,520
Dú que corresponda.

171
00:11:50,640 --> 00:11:52,230
Y ahí procesamos nuestra petición.

172
00:11:52,350 --> 00:11:53,640
Hacemos lo que tenemos que hacer.

173
00:11:53,760 --> 00:11:59,610
Entonces importante que quede claro que durante el ciclo hoy día un SELECT puede recibir muchas cientos

174
00:11:59,700 --> 00:12:06,420
y miles de peticiones, cientos de llamada al método Arques y cada una se manejan en un hilo distinto,

175
00:12:06,450 --> 00:12:08,330
separada, el resto nos afectan.

176
00:12:08,520 --> 00:12:09,360
Y al finalizar.

177
00:12:09,420 --> 00:12:15,660
Por ejemplo, si un select pasa mucho tiempo que no recibe ninguna llamada, no recibe ningún request,

178
00:12:15,780 --> 00:12:18,270
automáticamente se va a destruir.

179
00:12:18,330 --> 00:12:22,720
Por lo tanto, se invoca el método destroy y ya deja de ser manejado por el contenedor de SELECT.

180
00:12:22,890 --> 00:12:28,110
O bien cuando bajamos el servicio de nuestra aplicación, también se destruyen todos los servlet de

181
00:12:28,110 --> 00:12:30,390
nuestra aplicación y se le va llamando el método y Troi.

182
00:12:30,540 --> 00:12:32,700
El método Destroy es para cerrar todo.

183
00:12:32,730 --> 00:12:38,670
Por ejemplo, si en el init inicializamos algún recurso, por ejemplo, si abrimos alguna conexión en

184
00:12:38,670 --> 00:12:41,580
el destroy la tenemos que cerrar y conexión de objetivo.

185
00:12:41,610 --> 00:12:43,350
Por ejemplo, alguna base rato.

186
00:12:43,440 --> 00:12:48,690
Ahora no está recomendable quienes iní tengamos una conexión a la base de datos porque sería una conexión

187
00:12:48,690 --> 00:12:51,150
compartida por varios request por el cliente.

188
00:12:51,210 --> 00:12:57,900
La mejor opción es tener una conexión de un pull de conexiones distinta y se le asigna una a un cliente

189
00:12:57,900 --> 00:12:59,820
en particular y manejar un pull, por ejemplo.

190
00:12:59,820 --> 00:13:05,670
Se fijan entonces cuando se inicializa un Rickert, a un usuario se le asigna una conexión del pool

191
00:13:05,790 --> 00:13:10,740
y después, cuando finaliza el request, libera esa conexión para que sea utilizado por otro usuario

192
00:13:10,860 --> 00:13:16,170
y así y además lo importante que maneje su propia transacciones independiente a los demás clientes que

193
00:13:16,170 --> 00:13:17,400
nos afectan unos con otros.

194
00:13:17,520 --> 00:13:22,620
Y por último, otro punto importante de los Alder como un objeto select puede ser compartido por muchos

195
00:13:22,710 --> 00:13:23,260
usuarios.

196
00:13:23,460 --> 00:13:29,160
Ojo, no el método Service, porque el método service se llama en un hilo distinto, pero en general

197
00:13:29,250 --> 00:13:31,430
la clase Select es única o Aloma.

198
00:13:31,440 --> 00:13:37,380
Podríamos tener un pool de San Letra, pero independiente es compartido por varios cliente por varios

199
00:13:37,380 --> 00:13:44,070
usuario y si tenemos un atributo que guarda información en este SALDE y un usuario modifica ese atributo,

200
00:13:44,160 --> 00:13:46,860
ese valor de ese atributo va a afectar al resto.

201
00:13:47,070 --> 00:13:52,230
Entonces es muy importante que un SELECT no maneje estado sea Styles sin estado.

202
00:13:52,500 --> 00:13:57,630
De hecho el rico es y el response y el protocolo HTTP por defecto no maneja estado.

203
00:13:57,780 --> 00:14:01,290
El SALDE tampoco debiese manejar estado para que nos afecten a los demás.

204
00:14:01,380 --> 00:14:06,630
Cualquier estado que queramos manejar o mantener algún objeto entre peticiones, entre páginas.

205
00:14:06,720 --> 00:14:09,770
Utilizamos el objeto http session.

206
00:14:09,810 --> 00:14:11,460
Pero ese otro tema que después vamos a ver.

207
00:14:11,670 --> 00:14:13,110
Por ejemplo para un carro de compra.

208
00:14:13,200 --> 00:14:16,710
Pero no tener un objeto carro de compra como atributo encarcelen.

209
00:14:16,800 --> 00:14:17,010
Claro.

210
00:14:17,010 --> 00:14:23,100
Porque si un usuario modifica agrega producto, esos productos se van a ver reflejado también para los

211
00:14:23,100 --> 00:14:23,730
demás usuarios.

212
00:14:23,790 --> 00:14:29,730
Y no le diré que ese carro de compra o esa información de ese usuario sea solamente específico para

213
00:14:29,730 --> 00:14:30,240
ese usuario.

214
00:14:30,330 --> 00:14:32,340
Se tiene que manejar en un contexto distinto.

215
00:14:32,460 --> 00:14:33,150
En la sesión.

216
00:14:33,240 --> 00:14:34,320
Bueno, eso sería todo.

217
00:14:34,350 --> 00:14:37,140
Creo que me queda un poco largo la introducción del SELECT.

218
00:14:37,230 --> 00:14:40,070
Lo dejamos así y nos vemos en la siguiente clase.