El usuario puede crear una lista blanca o una lista negra para un conjunto de métodos en un servicio POJO. Las listas blancas y negras se realizan utilizando el atributo de filtro del elemento de métodos en el elemento POJO. Los valores del filtro pueden ser whitelisting y blacklisting. Si no se especifica el filtro, se listan todos los métodos. El método getAddress de la clase AddressLookup puede incluirse en una lista blanca especificando el servicio POJO como en el siguiente ejemplo.
El ejemplo demuestra que utilizando el adaptador RPC sólo se puede acceder a getAddress de la clase AddressLookup. El mismo método puede incluirse en la lista negra como en el siguiente ejemplo.
El ejemplo anterior demuestra que todos los métodos de la clase AddressLookup, excepto getAddress, son accesibles utilizando el adaptador RPC. Si no se especifica el elemento de métodos del servicio POJO o no se especifica el atributo de filtro para el elemento de métodos, de forma predeterminada se incluyen todos los métodos en la lista blanca.
En muchos casos, es posible que necesite acceder al objeto HttpServletRequest en los métodos que se llaman desde JavaScriptTM. Esto se consigue en el adaptador RPC colocando HttpServletRequest como el primer parámetro en la llamada de método. La descripción de método simple (SMD) que se devuelve no tiene el objeto HttpServletRequest como parámetro y puede invocar al método desde JavaScript sin pasar este parámetro. Por ejemplo, consideremos un método putNameInSession(HttpServletRequest req, String name). Se visualiza el XML correspondiente siguiente:
Los validadores se definen utilizando los elementos de validador del archivo de configuración del adaptador RPC. Puede especificar un conjunto de validadores para servicios POJO individuales. Antes de invocar un método, el método validate del validador especificado se invoca en los parámetros del método. Puede especificar validadores individuales para cada parámetro de método. Todos los validadores amplían la clase abstracta com.ibm.websphere.rpcadapter.Validator. Otra forma de validación es utilizando expresiones regulares. Puede utilizar el elemento validation-regex para especificar expresiones regulares que coinciden con los valores de parámetro. Si los valores de parámetro no coinciden con la expresión regular, se crea un error de validación.
Los errores de validación provocan la devolución de un objeto de error en formato JSON. Esta información puede utilizarse en el manejo de errores. A continuación se describen los campos.
El adaptador RPC da soporte ahora a los ámbitos de los objetos que expone. El adaptador RPC da soporte a tres ámbitos diferentes denominados Request, Session y Application, que se pueden especificar para almacenar el objeto expuesto en la petición, sesión o aplicación. Cuando el ámbito se establece en Application o Session, una ventaja adicional es que el objeto no se vuelve a crear cada vez, sino que se busca en el ámbito Session o Application. La clave utilizada tiene el formato "com.ibm.websphere.rpcadapter:ServiceName", donde ServiceName es el nombre del objeto expuesto. Para poder especificar esta clave, se proporciona un código de ámbito para cada objeto que puede contener los valores: Session, Request y Application. Consideremos el ejemplo siguiente.
El adaptador RPC ahora da soporte a la adición de valores de retorno para la sesión. Para habilitar este valor de adición, es necesario añadir el código <add-to-session> tal como se muestra a continuación.
El adaptador RPC da soporte ahora a objetos complejos, por ejemplo, objetos que pueden contener otros objetos. Los objetos complejos están soportados como tipos de retorno y como parámetros de método. El adaptador RPC puede serializar ahora cualquier tipo de objeto complejo. Las correlaciones y las colecciones no están soportadas como parámetros de llamadas de método. Esto se debe a que la clase de los objetos incluidos en la Correlación o Colección no pueden identificarse únicamente a partir de su contenido. Este soporte requerirá sugerencias de clases o tipos parametrizados, que no están todavía soportados. Asimismo, no se pueden invocar métodos con parámetros complejos a través de HTTP-RPC, aunque los tipos de retorno complejo estén soportados.
Este es un caso particular del soporte de objetos complejos. Por ejemplo, A -> B -> A, o A contiene B que contiene A. El componente de adaptador RPC del producto maneja este caso sustituyendo las apariciones duplicadas de objetos por marcadores $jref (serialización JSON) o $xref (serialización XML). Estos marcadores contienen información que puede utilizarse para buscar el objeto original, por ejemplo, una expresión XPath en el caso de XML y una expresión JavaScript en el caso de JSON. El soporte del manejo de objetos recursivos puede activarse estableciendo el valor del código <recursive-object-support> en true. Esto se muestra en el siguiente ejemplo.
A menudo, los objetos que deben exponerse pueden tener determinados campos que el desarrollador de aplicaciones no desee exponer a través del servicio Web JSON o XML. El adaptador RPC ofrece la posibilidad de suprimir campos del objeto devuelto. Esta supresión de campos puede habilitarse mediante el código <serialized-params>. A continuación, se muestra la configuración necesaria para suprimir el campo postalCode de la clase com.ibm.Address. Como resultado de esta configuración, el campo postalCode de la clase com.ibm.Address nunca se serializará.
El usuario puede especificar alias para las clases. El alias se utiliza como nombre de nodo durante la serialización XML. En el ejemplo siguiente se muestra cómo puede configurarse el alias de la dirección.
El usuario puede especificar convertidores de JSON/XML. Si se especifica un
convertidor para una clase, el convertidor se utilizará para la serialización JSON/XML de
dicha clase. Todas las clases de convertidor deben implementar la interfaz
com.ibm.websphere.rpcadapter.converters.IConverter
. De forma predeterminada, el
adaptador RPC se proporciona con los siguientes convertidores.
Convertidor | Uso |
com.ibm.websphere.rpcadapter.converters.sql.Date
|
Para convertir java.sql.Date en una serie de fecha y hora. |
com.ibm.websphere.rpcadapter.converters.sql.Time
|
Para convertir java.sql.Time en una serie de fecha y hora. |
com.ibm.websphere.rpcadapter.converters.sql.TimeStamp
|
Para convertir java.sql.TimeStamp en una serie de fecha y hora. |
com.ibm.websphere.rpcadapter.converters.util.Date
|
Para convertir java.util.Date en una serie de fecha y hora. |
Puede especificar convertidores en RpcAdapterConfig.xml de forma similar que en el siguiente ejemplo. El código <subclass-suppport> se puede utilizar para especificar que incluso las subclases de la clase de bean especificada deben convertirse mediante el convertidor de clases al establecer el valor entre los códigos en true. De forma predeterminada, se establece en false.
Por motivos de seguridad, el adaptador RPC puede configurarse para emitir salida filtrada de comentario JSON cuando se utiliza para exponer métodos como servicios Web JSON, por ejemplo, datos JSON envueltos con '/*' y '*/'. Dojo ofrece la posibilidad de procesar este JSON filtrado de comentario en el lado del cliente. De forma predeterminada, esta característica está inhabilitada RPCAdapter. Puede habilitarse estableciendo el código filtrado en true en el archivo RPCAdapterConfig.xml, tal como se muestra en el siguiente ejemplo.
El soporte de seguridad en el adaptador RPC se obtiene utilizando la seguridad Web de Java EE. Todos los servicios que se han configurado para mostrarse al cliente tendrán URL exclusivos. El acceso a estos URL se restringe utilizando la seguridad Web de Java EE. Para ello, debe crear un reino de seguridad en el servidor de aplicaciones; a continuación, debe definir un acceso basado en roles a distintos URL en el archivo del descriptor de despliegue, web.xml; y, por último, debe correlacionar estos roles con usuarios o grupos en el reino de seguridad utilizando una configuración específica de servidor. Esta característica no se puede utilizar por sí sola para las llamadas de proceso por lotes.
Además de la seguridad Web de Java EE, el adaptador RPC también se puede configurar para realizar comprobaciones de autorización para los servicios expuestos y, por consiguiente, permitir el acceso sólo a determinados roles definidos en web.xml o en geronimo-web.xml. Para utilizar esta característica, el url-pattern "/RPCAdapter/*" debe protegerse mediante web.xml. El siguiente paso implica el uso del código <role> para especificar si sólo un usuario con un determinado rol podrá acceder al servicio correspondiente. Tenga en cuenta que mientras RPCAdapter realiza la autorización de servicio, sigue siendo la responsabilidad de la aplicación la autenticación del usuario antes de invocar al servicio protegido. Si no se realiza la autenticación antes de invocar al servicio protegido, RPCAdapter no permitirá el acceso al servicio correspondiente. Esto sólo es aplicable para los métodos del servicio que ya están incluidos en la lista blanca. El acceso a un servicio se puede controlar como se muestra a continuación.
Los usuarios pueden procesar por lotes un conjunto de llamadas utilizando la API BatchService. Una nueva fábrica de servicios de proceso por lotes se puede crear, inicializar y someter de la forma siguiente.
Los métodos con sobrecarga pueden exponerse especificando un nombre exclusivo para un determinado método con sobrecarga y los correspondientes tipos de parámetros en el archivo RpcAdapterConfig.xml.
A los métodos se les puede asignar nombres que son distintos de los reales que se utilizan en la implementación Java. Esto puede llevarse a cabo utilizando códigos <alias> y <name> de una forma parecida a la utilizada en la sobrecarga de métodos. La única excepción será que los tipos no tienen que especificarse si no hay sobrecarga en el método.
Para acceder a enterprise beans a través de RPCAdapter, especifique la información necesaria del módulo EJB en RPCAdapterConfig.xml. Los métodos del módulo EJB se muestran y puede invocar un método directamente desde JavaScript.
Para acceder a los beans de sesión a través de RPCAdapter, especifique las interfaces remota y local, el nombre JNDI para la consulta de módulo EJB y los métodos que se implementan. En el caso de EJB 3.0, las interfaces local y remota se sustituyen por una sola interfaz generalmente llamada interfaz de empresa. Por consiguiente, especifique la interfaz de empresa utilizando el código <business-interface>. El código <ejb-name> se utiliza para asociar un nombre lógico con un módulo EJB. <jndi-name> se utiliza para consultar módulos EJB. El nombre JNDI especificado por el usuario en el archivo RPCAdapterConfig.xml debe coincidir con el nombre JNDI especificado en el archivo web.xml.
En el caso de EJB 3.0, añada el prefijo "java:comp/env/" para el nombre JNDI, si
el servidor de aplicaciones utilizado es WebSphere® Application Server Community
Edition. En el caso de WebSphere Application Server, si se utiliza EJB 3.0, el nombre
JNDI dentro del código <jndi-name> debe tener el prefijo formado por la palabra clave "ejblocal:". Debe proporcionar el tipo de bean de sesión, con estado o sin estado, utilizando el código <session-type>.
En el siguiente ejemplo se muestra una entrada de ejemplo para el bean de sesión sin estado en el archivo RPCAdapterConfig.xml.
En beans de sesión con estado, la interfaz inicial puede contener más de una función de creación. En ese caso, especifique la función crear que se va a llamar. Utilice el código <create> para declarar la de creación en el archivo RPCAdapterConfig.xml. El fragmento de código del bean de sesión con estado para EJB 2.1 es el siguiente.
El soporte de anotaciones le permite exponer los servicios directamente desde el código en lugar de configurarlos en el archivo RPCAdapterConfig.xml. Para habilitar esta característica, en este release se proporciona el archivo RPCAdapter-annotation.jar. Coloque este archivo jar en el directorio WEB-INF/lib de la aplicación Web que utilice esta característica. Debe anotar la clase que contiene los métodos que va a exponer con @Pojo y los correspondientes métodos con las anotaciones @Method y @Params. Una clase anotada es visible para RPCAdapter a través del archivo web.xml. Especifique el nombre canónico de la clase anotada como valor "init-param" para el RPCAdapter. Indique el correspondiente nombre "init-param" como classn, donden es cualquier número. A continuación se muestra un fragmento de código de ejemplo.
En un adaptador RPC, el formato de salida es JSON o XML.
A continuación se listan las diversas salidas XML que se generan bajo distintos casos de ejemplo.
Si el tipo de retorno es void, la salida XML generada es un código de resultado vacío como se muestra a continuación.
Si el método de JavaBeans es public int getSalary()
, la salida es
parecida a la siguiente:
public String getMessage()
, la salida es
parecida a la del ejemplo siguiente.
public Boolean isLeapYear(int year)
, la salida es
parecida a la del ejemplo siguiente.
Para el tipo de retorno Colección, la salida es un conjunto de elementos donde cada elemento representa una entrada en la colección. Si la colección contiene alguna instancia de un tipo de objeto suprimido, dicha entrada se ignora.
public Collection getEmployees()
y la
colección devuelta contiene instancias de Employee, una salida de ejemplo es parecida a
la del ejemplo siguiente.
Para el tipo de retorno Array, la salida es un conjunto de elementos donde cada elemento representa una entrada en la matriz.
public Employee[] getEmployees()
y la
matriz (Array) devuelta está compuesta por instancias de Employee, una salida de ejemplo
es parecida a la del ejemplo siguiente.
Para el tipo de retorno Correlación, la salida será un conjunto de elementos, donde
cada elemento representa un par de clave-valor en la correlación. El nombre de nodo es
la clave.
Si el método de JavaBeans es public Map getDepartments()
y la
correlación devuelta en un par clave-valor de código de departamento a detalles de
departamento, una salida de ejemplo es parecida a la del ejemplo siguiente.
Para el tipo de retorno de JavaBeans todos los métodos de lectura y los campos
públicos sin un método de lectura se considerarán para la serialización XML. Los
JavaBeans se representan por un elemento. El nombre de nodo de este elemento será del
tipo de JavaBeans que representa. Si se
especifica un alias para el bean, se utilizará como nombre de nodo.
Si el método de JavaBeans es public Employee getEmployee()
, una salida
de ejemplo es parecida a la siguiente.
A continuación se explican las diversas salidas JSON en distintos casos de ejemplo.
Si el tipo de retorno es void, la salida JSON generada es un objeto de resultado JSON.
public int getSalary()
, la salida es
parecida al siguiente ejemplo. public String getMessage()
, la salida es
parecida a la del ejemplo siguiente.
public Boolean isLeapYear(int year)
, la
salida es parecida a la del ejemplo siguiente.
Para el tipo de retorno Colección, la salida es un conjunto de elementos donde cada elemento representa una entrada en la colección. Si la colección contiene alguna instancia de un tipo de objeto suprimido, dicha entrada se ignora.
public Collection getEmployees()
y la
colección devuelta contiene instancias de Employee, una salida de ejemplo es parecida a
la del ejemplo siguiente.
Para el tipo de retorno Array, la salida es un conjunto de elementos donde cada elemento representa una entrada en la matriz.
public Employee[] getEmployees()
y la
matriz (Array) devuelta está compuesta por instancias de Employee, una salida de ejemplo
es parecida a la del ejemplo siguiente.
Para el tipo de retorno Correlación, la salida será un conjunto de pares de
clave-valor.
Si el método de JavaBeans es public Map getDepartments()
y la
correlación devuelta en un par clave-valor de código de departamento a detalles de
departamento, una salida de ejemplo es parecida a la del ejemplo siguiente.
Los JavaBeans se representan como pares de clave-valor con la clave como nombre del
campo y el valor como valor del campo. Sólo se serializan los campos públicos y los
campos con métodos getter.
Si el método de JavaBeans es public Employee getEmployee()
, una salida
de ejemplo es parecida a la siguiente.
El adaptador RPC puede configurarse para (1) crear una instancia de JavaBeans por petición o (2) reutilizar instancias por usuario. (Por ejemplo, puede configurarse un carro de la compra como la segunda opción). El comportamiento predeterminado es crear una instancia de un nuevo JavaBeans por petición. La reutilización se configura mediante la información del descriptor de bean. Consulte la documentación de la API SampleBeanInfo para obtener detalles.
Algunos mandatos se desarrollan sin la expectativa de exponerse directamente como servicios. En casos así, un descriptor de acceso JavaBeans se puede desarrollar para contener la lógica implicada. Por ejemplo, el EJB ShoppingCart en el ejemplo PlantsByWebSphere incluye un método addItem(StoreItem item). El objeto StoreItem incluye el precio del artículo, por lo que este diseño se supone que sólo las fuentes invocarán el método, como el siguiente ejemplo en el servlet ShoppingServlet.