Visi\u00f3n general<\/b>
\nLa programaci\u00f3n basada en componentes se ha hecho m\u00e1s popular que nunca. Hoy en d\u00eda, casi no hay aplicaci\u00f3n que no utilice componentes de alg\u00fan tipo, normalmente de distintos proveedores. A medida que las aplicaciones se han vuelto m\u00e1s sofisticadas, tambi\u00e9n ha crecido la necesidad de aprovechar componentes distribuidos en m\u00e1quinas remotas.<\/p>\n
<\/p>\n
Un ejemplo de aplicaci\u00f3n basada en componentes es una soluci\u00f3n de comercio electr\u00f3nico de extremo a extremo. Una aplicaci\u00f3n de comercio electr\u00f3nico que reside en una granja Web necesita enviar pedidos a una aplicaci\u00f3n de planificaci\u00f3n de recursos empresariales (ERP) back-end. En muchos casos, la aplicaci\u00f3n ERP reside en un hardware diferente y puede ejecutarse en un sistema operativo distinto.<\/p>\n
El Microsoft Distributed Component Object Model (DCOM), una infraestructura de objetos distribuidos que permite a una aplicaci\u00f3n invocar componentes del Component Object Model (COM) instalados en otro servidor, ha sido portado a varias plataformas distintas de Windows. Pero DCOM nunca ha tenido una gran aceptaci\u00f3n en estas plataformas, por lo que rara vez se utiliza para facilitar la comunicaci\u00f3n entre ordenadores Windows y no Windows. Los proveedores de software ERP suelen crear componentes para la plataforma Windows que se comunican con el sistema back-end a trav\u00e9s de un protocolo propietario.<\/p>\n
Algunos servicios utilizados por una aplicaci\u00f3n de comercio electr\u00f3nico pueden no residir en absoluto en el centro de datos. Por ejemplo, si la aplicaci\u00f3n de comercio electr\u00f3nico acepta el pago con tarjeta de cr\u00e9dito de los bienes adquiridos por el cliente, debe solicitar los servicios del banco comercial para procesar la informaci\u00f3n de la tarjeta de cr\u00e9dito del cliente. Pero a efectos pr\u00e1cticos, DCOM y las tecnolog\u00edas relacionadas, como CORBA y Java RMI, se limitan a aplicaciones y componentes instalados en el centro de datos corporativo. Dos razones principales para ello son que, por defecto, estas tecnolog\u00edas aprovechan protocolos propietarios y que estos protocolos est\u00e1n inherentemente orientados a la conexi\u00f3n.<\/p>\n
Los clientes que se comunican con el servidor a trav\u00e9s de Internet se enfrentan a numerosas barreras potenciales para comunicarse con el servidor. En todo el mundo, los administradores de red preocupados por la seguridad han implementado enrutadores y cortafuegos corporativos para impedir pr\u00e1cticamente cualquier tipo de comunicaci\u00f3n a trav\u00e9s de Internet. A menudo se necesita un acto de Dios para que un administrador de red abra los puertos m\u00e1s all\u00e1 del m\u00ednimo.<\/p>\n
Si tienes la suerte de que un administrador de red abra los puertos adecuados para soportar tu servicio, lo m\u00e1s probable es que tus clientes no tengan la misma suerte. Por eso, los protocolos propietarios como DCOM, CORBA y Java RMI no son pr\u00e1cticos para Internet.<\/p>\n
El otro problema, como ya he dicho, de estas tecnolog\u00edas es que est\u00e1n intr\u00ednsecamente orientadas a la conexi\u00f3n y, por tanto, no pueden gestionar las interrupciones de la red con elegancia. Como Internet no est\u00e1 bajo tu control directo, no puedes hacer suposiciones sobre la calidad o fiabilidad de la conexi\u00f3n. Si se produce una interrupci\u00f3n en la red, la siguiente llamada que el cliente haga al servidor podr\u00eda fallar.<\/p>\n
La naturaleza orientada a la conexi\u00f3n de estas tecnolog\u00edas tambi\u00e9n dificulta la construcci\u00f3n de las infraestructuras de carga equilibrada necesarias para lograr una alta escalabilidad. Una vez cortada la conexi\u00f3n entre el cliente y el servidor, no se puede simplemente dirigir la siguiente petici\u00f3n a otro servidor.<\/p>\n
Los desarrolladores han intentado superar estas limitaciones aprovechando un modelo llamado sin estado <\/i>programaci\u00f3n<\/i>, pero han tenido un \u00e9xito limitado porque las tecnolog\u00edas son bastante pesadas y encarecen el restablecimiento de la conexi\u00f3n con un objeto remoto.<\/p>\n
Dado que el procesamiento de la tarjeta de cr\u00e9dito de un cliente lo realiza un servidor remoto en Internet, DCOM no es ideal para facilitar la comunicaci\u00f3n entre el cliente de comercio electr\u00f3nico y el servidor de procesamiento de tarjetas de cr\u00e9dito. Como en una soluci\u00f3n ERP, a menudo se instala un componente de terceros en el centro de datos del cliente (en este caso, por el proveedor de la soluci\u00f3n de procesamiento de tarjetas de cr\u00e9dito). Este componente sirve como poco m\u00e1s que un proxy que facilita la comunicaci\u00f3n entre el software de comercio electr\u00f3nico y el banco comercial a trav\u00e9s de un protocolo propietario.<\/p>\n
\u00bfVe alg\u00fan patr\u00f3n? Debido a las limitaciones de las tecnolog\u00edas existentes para facilitar la comunicaci\u00f3n entre sistemas inform\u00e1ticos, los proveedores de software han recurrido a menudo a crear su propia infraestructura. Esto significa que los recursos que podr\u00edan haberse utilizado para a\u00f1adir una funcionalidad mejorada al sistema ERP o al sistema de procesamiento de tarjetas de cr\u00e9dito se han dedicado, en cambio, a escribir protocolos de red propietarios.<\/p>\n
En un esfuerzo por soportar mejor estos escenarios de Internet, Microsoft adopt\u00f3 inicialmente la estrategia de aumentar sus tecnolog\u00edas existentes, incluyendo COM Internet Services (CIS), que permite establecer una conexi\u00f3n DCOM entre el cliente y el componente remoto a trav\u00e9s del puerto 80. Por diversas razones, CIS no fue ampliamente aceptado.<\/p>\n
Estaba claro que se necesitaba un nuevo enfoque. As\u00ed que Microsoft decidi\u00f3 abordar el problema desde la base. Veamos algunos de los requisitos que deb\u00eda cumplir la soluci\u00f3n para tener \u00e9xito.<\/p>\n
Dado el t\u00edtulo de este libro, no deber\u00eda sorprender que la soluci\u00f3n creada por Microsoft se conozca como Servicios web<\/i>. Un servicio Web expone una interfaz para invocar una actividad concreta en nombre del cliente. Un cliente puede acceder al servicio Web mediante el uso de est\u00e1ndares de Internet.<\/p>\n
Elementos b\u00e1sicos de los servicios web<\/b>
\nEl siguiente gr\u00e1fico muestra los elementos b\u00e1sicos necesarios para facilitar la comunicaci\u00f3n remota entre dos aplicaciones.<\/p>\n
Analicemos el prop\u00f3sito de cada uno de estos m\u00f3dulos. Como muchos lectores est\u00e1n familiarizados con DCOM, tambi\u00e9n mencionar\u00e9 el equivalente en DCOM de cada building block.<\/p>\n
Sin una forma est\u00e1ndar de formatear los mensajes, desarrollar un conjunto de herramientas para abstraer al desarrollador de los protocolos subyacentes es pr\u00e1cticamente imposible. La creaci\u00f3n de una capa de abstracci\u00f3n entre el desarrollador y los protocolos subyacentes permite al desarrollador centrarse m\u00e1s en el problema empresarial y menos en la infraestructura necesaria para implantar la soluci\u00f3n.<\/p>\n
Decisiones sobre el dise\u00f1o de servicios web<\/b><\/p>\n
Analicemos algunas de las decisiones de dise\u00f1o que subyacen a estos componentes b\u00e1sicos de los servicios web.<\/p>\n
Elecci\u00f3n de protocolos de transporte<\/b><\/p>\n
El primer paso fue determinar c\u00f3mo se comunicar\u00edan entre s\u00ed el cliente y el servidor. El cliente y el servidor pueden residir en la misma LAN, pero el cliente podr\u00eda comunicarse con el servidor a trav\u00e9s de Internet. Por lo tanto, el protocolo de transporte debe ser igualmente adecuado para entornos LAN y para Internet.<\/p>\n
Como he mencionado antes, tecnolog\u00edas como DCOM, CORBA y Java RMI son poco adecuadas para soportar la comunicaci\u00f3n entre el cliente y el servidor a trav\u00e9s de Internet. Protocolos como el Protocolo de Transferencia de Hipertexto (HTTP) y el Protocolo Simple de Transferencia de Correo (SMTP) son protocolos probados en Internet. HTTP define un patr\u00f3n de mensajer\u00eda solicitud\/respuesta para enviar una solicitud y obtener una respuesta asociada. SMTP define un protocolo de mensajer\u00eda enrutable para la comunicaci\u00f3n as\u00edncrona. Veamos por qu\u00e9 HTTP y SMTP son adecuados para Internet.<\/p>\n
Las aplicaciones Web basadas en HTTP son intr\u00ednsecamente ap\u00e1tridas. No dependen de una conexi\u00f3n continua entre el cliente y el servidor. Esto convierte a HTTP en un protocolo ideal para configuraciones de alta disponibilidad, como los cortafuegos. Si el servidor que gestion\u00f3 la solicitud original del cliente deja de estar disponible, las solicitudes posteriores se pueden dirigir autom\u00e1ticamente a otro servidor sin que el cliente lo sepa ni le importe.<\/p>\n
Casi todas las empresas disponen de una infraestructura compatible con SMTP. SMTP es muy adecuado para la comunicaci\u00f3n as\u00edncrona. Si el servicio se interrumpe, la infraestructura de correo electr\u00f3nico gestiona autom\u00e1ticamente los reintentos. Al contrario que con HTTP, puede pasar mensajes SMTP a un servidor de correo local que intentar\u00e1 entregar el mensaje de correo en su nombre.<\/p>\n
La otra gran ventaja de HTTP y SMTP es su omnipresencia. Los empleados han llegado a confiar tanto en el correo electr\u00f3nico como en sus navegadores Web, y los administradores de red se sienten muy c\u00f3modos dando soporte a estos servicios. Tecnolog\u00edas como la traducci\u00f3n de direcciones de red (NAT) y los servidores proxy permiten acceder a Internet a trav\u00e9s de HTTP desde redes LAN corporativas que, de otro modo, estar\u00edan aisladas. Los administradores a menudo exponen un servidor SMTP que reside dentro del cortafuegos. Los mensajes enviados a este servidor se dirigir\u00e1n a su destino final a trav\u00e9s de Internet.<\/p>\n
En el caso del software de procesamiento de tarjetas de cr\u00e9dito, se necesita una respuesta inmediata del banco comercial para determinar si el pedido debe enviarse al sistema ERP. HTTP, con su patr\u00f3n de mensajes solicitud\/respuesta, es muy adecuado para esta tarea.<\/p>\n
La mayor\u00eda de los paquetes de software ERP no son capaces de gestionar los grandes vol\u00famenes de pedidos que potencialmente pueden generarse desde la aplicaci\u00f3n de comercio electr\u00f3nico. Adem\u00e1s, no es imprescindible que los pedidos se env\u00eden al sistema ERP en tiempo real. Por lo tanto, SMTP puede aprovecharse para poner los pedidos en cola de modo que puedan ser procesados en serie por el sistema ERP.<\/p>\n
Si el sistema ERP admite transacciones distribuidas, otra opci\u00f3n es aprovechar Microsoft Message Queue Server (MSMQ). Mientras la aplicaci\u00f3n de comercio electr\u00f3nico y el sistema ERP residan en la misma LAN, la conectividad a trav\u00e9s de protocolos ajenos a Internet es menos problem\u00e1tica. La ventaja de MSMQ sobre SMTP es que los mensajes pueden colocarse y retirarse de la cola dentro del \u00e1mbito de una transacci\u00f3n. Si falla un intento de procesar un mensaje que se ha sacado de la cola, el mensaje volver\u00e1 autom\u00e1ticamente a la cola cuando se cancele la transacci\u00f3n.<\/p>\n
Elegir un esquema de codificaci\u00f3n<\/b><\/p>\n
HTTP y SMTP proporcionan un medio para enviar datos entre el cliente y el servidor. Sin embargo, ninguno de los dos especifica c\u00f3mo deben codificarse los datos dentro del cuerpo del mensaje. Microsoft necesitaba una forma est\u00e1ndar e independiente de la plataforma para codificar los datos intercambiados entre el cliente y el servidor.<\/p>\n
Dado que el objetivo era aprovechar los protocolos basados en Internet, la elecci\u00f3n natural era el lenguaje XML (Extensible Markup Language). XML ofrece muchas ventajas, como la compatibilidad entre plataformas, un sistema de tipos com\u00fan y la compatibilidad con los juegos de caracteres est\u00e1ndar del sector.<\/p>\n
Los esquemas de codificaci\u00f3n binaria como los utilizados por DCOM, CORBA y Java RMI deben abordar los problemas de compatibilidad entre las distintas plataformas de hardware. Por ejemplo, las distintas plataformas de hardware tienen distintas representaciones binarias internas de los n\u00fameros multibyte. Las plataformas Intel ordenan los bytes de un n\u00famero multibyte utilizando la convenci\u00f3n little endian; muchos procesadores RISC ordenan los bytes de un n\u00famero multibyte utilizando la convenci\u00f3n big endian.<\/p>\n
XML evita los problemas de codificaci\u00f3n binaria porque utiliza un esquema de codificaci\u00f3n basado en texto que aprovecha los conjuntos de caracteres est\u00e1ndar. Adem\u00e1s, algunos protocolos de transporte, como SMTP, s\u00f3lo pueden contener mensajes basados en texto.<\/p>\n
Los m\u00e9todos binarios de codificaci\u00f3n, como los utilizados por DCOM y CORBA, son engorrosos y requieren una infraestructura de apoyo para abstraer al desarrollador de los detalles. XML es mucho m\u00e1s ligero y f\u00e1cil de manejar porque puede crearse y consumirse mediante t\u00e9cnicas est\u00e1ndar de an\u00e1lisis de texto.<\/p>\n
Adem\u00e1s, existe una gran variedad de analizadores XML que simplifican a\u00fan m\u00e1s la creaci\u00f3n y el consumo de documentos XML en pr\u00e1cticamente todas las plataformas modernas. XML es ligero y cuenta con un excelente soporte de herramientas, por lo que la codificaci\u00f3n XML permite un alcance incre\u00edble, ya que pr\u00e1cticamente cualquier cliente de cualquier plataforma puede comunicarse con su servicio web.<\/p>\n
Elegir una convenci\u00f3n de formato<\/b><\/p>\n
A menudo es necesario incluir metadatos adicionales en el cuerpo del mensaje. Por ejemplo, es posible que desee incluir informaci\u00f3n sobre el tipo de servicios que un servicio Web debe proporcionar para satisfacer su solicitud, como el alistamiento en una transacci\u00f3n o informaci\u00f3n de enrutamiento. XML no proporciona ning\u00fan mecanismo para diferenciar el cuerpo del mensaje de sus datos asociados.<\/p>\n
Los protocolos de transporte como HTTP proporcionan un mecanismo extensible para los datos de cabecera, pero algunos datos asociados al mensaje pueden no ser espec\u00edficos del protocolo de transporte. Por ejemplo, el cliente puede enviar un mensaje que necesita ser enrutado a m\u00faltiples destinos, potencialmente a trav\u00e9s de diferentes protocolos de transporte. Si la informaci\u00f3n de enrutamiento se colocara en una cabecera HTTP, tendr\u00eda que ser traducida antes de ser enviada al siguiente intermediario a trav\u00e9s de otro protocolo de transporte, como SMTP. Dado que la informaci\u00f3n de enrutamiento es espec\u00edfica del mensaje y no del protocolo de transporte, deber\u00eda formar parte del mensaje.<\/p>\n
El Protocolo Simple de Acceso a Objetos (SOAP) proporciona un medio independiente del protocolo para asociar la informaci\u00f3n de cabecera con el cuerpo del mensaje. Cada mensaje SOAP debe definir un sobre. El sobre tiene un cuerpo que contiene la carga \u00fatil del mensaje y una cabecera que puede contener metadatos asociados al mensaje.<\/p>\n
SOAP no impone restricciones sobre el formato del cuerpo del mensaje. Esta es una preocupaci\u00f3n potencial porque sin una forma consistente de codificar los datos, es dif\u00edcil desarrollar un conjunto de herramientas que te abstraiga de los protocolos subyacentes. Es posible que tenga que dedicar bastante tiempo a ponerse al d\u00eda sobre la interfaz del servicio Web en lugar de resolver el problema de negocio que tiene entre manos.<\/p>\n
Lo que se necesitaba era una forma est\u00e1ndar de dar formato a un mensaje de llamada a procedimiento remoto (RPC) y codificar su lista de par\u00e1metros. Esto es exactamente lo que ofrece la Secci\u00f3n 7 de la especificaci\u00f3n SOAP. Describe una convenci\u00f3n de nomenclatura est\u00e1ndar y un estilo de codificaci\u00f3n para los mensajes orientados a procedimientos.<\/p>\n
Dado que SOAP proporciona un formato est\u00e1ndar para serializar datos en un mensaje XML, plataformas como ASP.NET y Remoting pueden abstraer los detalles por usted.<\/p>\n
Elecci\u00f3n de los mecanismos de descripci\u00f3n<\/b><\/p>\n
SOAP ofrece una forma est\u00e1ndar de dar formato a los mensajes intercambiados entre el servicio web y el cliente. Sin embargo, el cliente necesita informaci\u00f3n adicional para serializar correctamente la solicitud e interpretar la respuesta. XML Schema proporciona un medio para crear esquemas que pueden utilizarse para describir el contenido de un mensaje.<\/p>\n
XML Schema proporciona un conjunto b\u00e1sico de tipos de datos incorporados que pueden utilizarse para describir el contenido de un mensaje. Tambi\u00e9n puede crear sus propios tipos de datos. Por ejemplo, el banco comercial puede crear un tipo de datos complejo para describir el contenido y la estructura del cuerpo de un mensaje utilizado para enviar una solicitud de pago con tarjeta de cr\u00e9dito.<\/p>\n
Un esquema contiene un conjunto de definiciones de tipos de datos y elementos. Un servicio web utiliza el esquema no s\u00f3lo para comunicar el tipo de datos que se espera que contenga un mensaje, sino tambi\u00e9n para validar los mensajes entrantes y salientes.<\/p>\n
Sin embargo, un esquema por s\u00ed solo no proporciona informaci\u00f3n suficiente para describir eficazmente un servicio web. El esquema no describe los patrones de mensajes entre el cliente y el servidor. Por ejemplo, un cliente necesita saber si debe esperar una respuesta cuando se env\u00eda un pedido al sistema ERP. Un cliente tambi\u00e9n necesita saber a trav\u00e9s de qu\u00e9 protocolo de transporte espera recibir solicitudes el servicio web. Por \u00faltimo, el cliente debe conocer la direcci\u00f3n de acceso al servicio web.<\/p>\n
Esta informaci\u00f3n la proporciona un documento WSDL (Web Services Description Language). WSDL es un documento XML que describe completamente un servicio web concreto. Herramientas como ASP.NET WSDL.exe y Remoting SOAPSUDS.exe pueden consumir WSDL y crear autom\u00e1ticamente proxies para el desarrollador.<\/p>\n
Como ocurre con cualquier componente utilizado para crear software, un servicio web tambi\u00e9n debe ir acompa\u00f1ado de documentaci\u00f3n escrita para los desarrolladores que programen con \u00e9l. La documentaci\u00f3n debe describir lo que hace el servicio Web, las interfaces que expone y algunos ejemplos de c\u00f3mo utilizarlo. Una buena documentaci\u00f3n es especialmente importante si el servicio Web se expone a clientes a trav\u00e9s de Internet.<\/p>\n
Elecci\u00f3n de los mecanismos de descubrimiento<\/b><\/p>\n
Una vez desarrollado y documentado un servicio web, \u00bfc\u00f3mo pueden localizarlo los clientes potenciales? Si el servicio Web est\u00e1 dise\u00f1ado para ser consumido por un miembro de su equipo de desarrollo, su enfoque puede ser bastante informal, como compartir la URL del documento WSDL con su compa\u00f1ero un par de cub\u00edculos m\u00e1s abajo. Pero cuando los clientes potenciales est\u00e1n en Internet, hacer publicidad de su servicio Web de forma eficaz es una historia completamente diferente.<\/p>\n
Lo que hace falta es una forma com\u00fan de anunciar los servicios web. La Descripci\u00f3n, Descubrimiento e Integraci\u00f3n Universales (UDDI) ofrece precisamente ese mecanismo. UDDI es un servicio de directorio centralizado est\u00e1ndar del sector que puede utilizarse para anunciar y localizar servicios Web. UDDI permite a los usuarios buscar servicios Web utilizando una serie de criterios de b\u00fasqueda, como el nombre de la empresa, la categor\u00eda y el tipo de servicio Web.<\/p>\n
Los servicios web tambi\u00e9n pueden anunciarse a trav\u00e9s de DISCO, un formato de documento XML propietario definido por Microsoft que permite a los sitios web anunciar los servicios que exponen. DISCO define un protocolo sencillo que facilita un estilo de hiperenlace para localizar recursos. El principal consumidor de DISCO es Microsoft Visual Studio.NET. Un desarrollador puede dirigirse a un servidor web concreto y navegar por los distintos servicios web expuestos por el servidor.<\/p>\n
\u00bfQu\u00e9 le falta a los servicios web?<\/b><\/p>\n
Es posible que se haya dado cuenta de que algunos elementos clave de una infraestructura de componentes distribuidos no est\u00e1n definidos por los servicios web. Dos de las omisiones m\u00e1s notables son una API bien definida para crear y consumir servicios Web y un conjunto de servicios de componentes, como el soporte para transacciones distribuidas. Analicemos cada una de estas piezas que faltan.<\/p>\n
En un esfuerzo por garantizar que los servicios Web sean independientes del lenguaje de programaci\u00f3n, Microsoft ha dejado en manos de los proveedores de software individuales la vinculaci\u00f3n del soporte de los servicios Web a una plataforma concreta. M\u00e1s adelante hablar\u00e9 de dos implementaciones de servicios Web para la plataforma .NET, ASP.NET y Remoting.<\/p>\n
Algunos servicios, como la compatibilidad con transacciones distribuidas, pueden introducirse m\u00e1s adelante, a medida que madure la tecnolog\u00eda. Otros, como la agrupaci\u00f3n de objetos y posiblemente la gesti\u00f3n del tiempo de vida de los objetos, pueden considerarse un detalle de implementaci\u00f3n de la plataforma. Por ejemplo, Remoting define extensiones para dar soporte a la gesti\u00f3n del tiempo de vida de los objetos, y Microsoft Component Services da soporte a la agrupaci\u00f3n de objetos.<\/p>\n
Resumen<\/b><\/p>\n
La programaci\u00f3n basada en componentes ha demostrado ser una gran ayuda para la productividad de los desarrolladores, pero algunos servicios no pueden ser encapsulados por un componente que resida en el centro de datos del cliente. Las tecnolog\u00edas heredadas, como DCOM, CORBA y Java RMI, son inadecuadas para permitir a los clientes acceder a servicios a trav\u00e9s de Internet, por lo que Microsoft consider\u00f3 necesario empezar desde abajo y crear un m\u00e9todo est\u00e1ndar para acceder a servicios remotos.<\/p>\n
Servicios web<\/i> es un t\u00e9rmino gen\u00e9rico que describe un conjunto de protocolos y servicios est\u00e1ndar utilizados para facilitar un nivel b\u00e1sico de interoperabilidad entre aplicaciones. El apoyo que han recibido los servicios Web por parte de la industria no tiene precedentes. Nunca antes tantas empresas l\u00edderes en tecnolog\u00eda hab\u00edan apoyado una norma que facilita la interoperabilidad entre aplicaciones, independientemente de la plataforma en la que se ejecuten.<\/p>\n
Uno de los factores que contribuyen al \u00e9xito de los servicios Web es que se basan en est\u00e1ndares de Internet ya existentes, como XML y HTTP. Como resultado, cualquier sistema capaz de analizar texto y comunicarse a trav\u00e9s de un protocolo de transporte est\u00e1ndar de Internet puede comunicarse con un servicio Web. Las empresas tambi\u00e9n pueden aprovechar la inversi\u00f3n que ya han realizado en estas tecnolog\u00edas.<\/p>","protected":false},"excerpt":{"rendered":"
Overview Component-based programming has become more popular than ever. Hardly an application is built today that does not involve leveraging components in some form, usually from different vendors. As applications have grown more sophisticated, the need to leverage components distributed on remote machines has also grown.<\/p>","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-231","post","type-post","status-publish","format-standard","hentry","category-smtp-servers"],"_links":{"self":[{"href":"https:\/\/www.smtp-server.net\/es\/wp-json\/wp\/v2\/posts\/231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.smtp-server.net\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.smtp-server.net\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/es\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/es\/wp-json\/wp\/v2\/comments?post=231"}],"version-history":[{"count":1,"href":"https:\/\/www.smtp-server.net\/es\/wp-json\/wp\/v2\/posts\/231\/revisions"}],"predecessor-version":[{"id":232,"href":"https:\/\/www.smtp-server.net\/es\/wp-json\/wp\/v2\/posts\/231\/revisions\/232"}],"wp:attachment":[{"href":"https:\/\/www.smtp-server.net\/es\/wp-json\/wp\/v2\/media?parent=231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.smtp-server.net\/es\/wp-json\/wp\/v2\/categories?post=231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.smtp-server.net\/es\/wp-json\/wp\/v2\/tags?post=231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}