Vue d'ensemble<\/b>
\nLa programmation \u00e0 base de composants est devenue plus populaire que jamais. Il n'y a gu\u00e8re d'application aujourd'hui qui n'implique pas l'utilisation de composants sous une forme ou une autre, provenant g\u00e9n\u00e9ralement de diff\u00e9rents fournisseurs. Au fur et \u00e0 mesure que les applications sont devenues plus sophistiqu\u00e9es, la n\u00e9cessit\u00e9 d'exploiter des composants distribu\u00e9s sur des machines distantes s'est \u00e9galement accrue.<\/p>\n
<\/p>\n
Une solution de commerce \u00e9lectronique de bout en bout constitue un exemple d'application bas\u00e9e sur des composants. Une application de commerce \u00e9lectronique h\u00e9berg\u00e9e sur une ferme de serveurs Web doit transmettre les commandes \u00e0 une application de gestion int\u00e9gr\u00e9e (ERP) en arri\u00e8re-plan. Dans de nombreux cas, l'application ERP est h\u00e9berg\u00e9e sur un mat\u00e9riel diff\u00e9rent et peut fonctionner sous un autre syst\u00e8me d'exploitation.<\/p>\n
Le Mod\u00e8le d'objets distribu\u00e9s de Microsoft (DCOM), une infrastructure d'objets distribu\u00e9s qui permet \u00e0 une application d'appeler des composants du Mod\u00e8le d'objets composant (COM) install\u00e9s sur un autre serveur, a \u00e9t\u00e9 port\u00e9 sur plusieurs plateformes non Windows. Mais le DCOM n'a jamais \u00e9t\u00e9 largement adopt\u00e9 sur ces plateformes, de sorte qu'il est rarement utilis\u00e9 pour faciliter la communication entre des ordinateurs Windows et non Windows. Les \u00e9diteurs de logiciels ERP cr\u00e9ent souvent des composants pour la plateforme Windows qui communiquent avec le syst\u00e8me back-end via un protocole propri\u00e9taire.<\/p>\n
Certains services utilis\u00e9s par une application de commerce \u00e9lectronique peuvent ne pas se trouver du tout au sein du centre de donn\u00e9es. Par exemple, si l'application de commerce \u00e9lectronique accepte les paiements par carte de cr\u00e9dit pour les articles achet\u00e9s par le client, elle doit faire appel aux services de la banque commerciale pour traiter les informations de carte de cr\u00e9dit du client. Mais dans la pratique, DCOM et les technologies associ\u00e9es telles que CORBA et Java RMI sont limit\u00e9es aux applications et composants install\u00e9s au sein du centre de donn\u00e9es de l'entreprise. Cela s'explique principalement par deux raisons : par d\u00e9faut, ces technologies utilisent des protocoles propri\u00e9taires, et ces protocoles sont intrins\u00e8quement orient\u00e9s connexion.<\/p>\n
Les clients qui communiquent avec le serveur via Internet se heurtent \u00e0 de nombreux obstacles potentiels. Partout dans le monde, les administrateurs r\u00e9seau soucieux de la s\u00e9curit\u00e9 ont mis en place des routeurs et des pare-feu d'entreprise afin de bloquer pratiquement tout type de communication sur Internet. Il faut souvent un \u00e9v\u00e9nement exceptionnel pour qu'un administrateur r\u00e9seau accepte d'ouvrir des ports au-del\u00e0 du strict minimum.<\/p>\n
Si vous avez la chance de convaincre un administrateur r\u00e9seau d'ouvrir les ports n\u00e9cessaires au fonctionnement de votre service, il y a fort \u00e0 parier que vos clients n'auront pas cette chance. Par cons\u00e9quent, les protocoles propri\u00e9taires tels que ceux utilis\u00e9s par DCOM, CORBA et Java RMI ne sont pas adapt\u00e9s aux sc\u00e9narios Internet.<\/p>\n
L'autre probl\u00e8me, comme je l'ai dit, avec ces technologies, c'est qu'elles sont intrins\u00e8quement orient\u00e9es connexion et ne peuvent donc pas g\u00e9rer correctement les interruptions de r\u00e9seau. Comme vous n'avez pas de contr\u00f4le direct sur Internet, vous ne pouvez pas faire de suppositions quant \u00e0 la qualit\u00e9 ou \u00e0 la fiabilit\u00e9 de la connexion. En cas d'interruption de r\u00e9seau, la prochaine requ\u00eate que le client enverra au serveur risque d'\u00e9chouer.<\/p>\n
Le fait que ces technologies soient orient\u00e9es connexion complique \u00e9galement la mise en place des infrastructures \u00e0 \u00e9quilibrage de charge n\u00e9cessaires pour atteindre une grande \u00e9volutivit\u00e9. Une fois la connexion entre le client et le serveur interrompue, il n'est pas possible de simplement rediriger la requ\u00eate suivante vers un autre serveur.<\/p>\n
Les d\u00e9veloppeurs ont tent\u00e9 de surmonter ces limites en s'appuyant sur un mod\u00e8le appel\u00e9 sans nationalit\u00e9 <\/i>programmation<\/i>, mais leur succ\u00e8s a \u00e9t\u00e9 limit\u00e9 car ces technologies sont assez lourdes et rendent co\u00fbteux le r\u00e9tablissement d'une connexion avec un objet distant.<\/p>\n
\u00c9tant donn\u00e9 que le traitement de la carte de cr\u00e9dit d'un client est effectu\u00e9 par un serveur distant sur Internet, DCOM n'est pas la solution id\u00e9ale pour faciliter la communication entre le client du site de commerce \u00e9lectronique et le serveur de traitement des cartes de cr\u00e9dit. Comme dans une solution ERP, un composant tiers est souvent install\u00e9 au sein du centre de donn\u00e9es du client (dans ce cas, par le fournisseur de la solution de traitement des cartes de cr\u00e9dit). Ce composant ne sert gu\u00e8re plus qu\u2019un proxy facilitant la communication entre le logiciel de commerce \u00e9lectronique et la banque du commer\u00e7ant via un protocole propri\u00e9taire.<\/p>\n
Voyez-vous une tendance se dessiner ici ? En raison des limites des technologies existantes pour faciliter la communication entre les syst\u00e8mes informatiques, les \u00e9diteurs de logiciels ont souvent d\u00fb se r\u00e9soudre \u00e0 mettre en place leur propre infrastructure. Cela signifie que des ressources qui auraient pu servir \u00e0 am\u00e9liorer les fonctionnalit\u00e9s du syst\u00e8me ERP ou du syst\u00e8me de traitement des cartes de cr\u00e9dit ont \u00e9t\u00e9 consacr\u00e9es \u00e0 l'\u00e9laboration de protocoles r\u00e9seau propri\u00e9taires.<\/p>\n
Afin de mieux prendre en charge ce type de sc\u00e9narios Internet, Microsoft a d'abord opt\u00e9 pour une strat\u00e9gie visant \u00e0 enrichir ses technologies existantes, notamment les COM Internet Services (CIS), qui permettent d'\u00e9tablir une connexion DCOM entre le client et le composant distant via le port 80. Pour diverses raisons, les CIS n'ont pas \u00e9t\u00e9 largement adopt\u00e9s.<\/p>\n
Il est apparu clairement qu'une nouvelle approche s'imposait. Microsoft a donc d\u00e9cid\u00e9 d'aborder le probl\u00e8me en partant de la base. Voyons quelques-unes des exigences auxquelles la solution devait r\u00e9pondre pour \u00eatre couronn\u00e9e de succ\u00e8s.<\/p>\n
Au vu du titre de cet ouvrage, il n'est gu\u00e8re surprenant que la solution mise au point par Microsoft soit connue sous le nom de Services Web<\/i>. Un service Web met \u00e0 disposition une interface permettant d'invoquer une activit\u00e9 sp\u00e9cifique pour le compte du client. Un client peut acc\u00e9der au service Web en utilisant les normes Internet.<\/p>\n
\u00c9l\u00e9ments constitutifs des services Web<\/b>
\nLe sch\u00e9ma suivant pr\u00e9sente les \u00e9l\u00e9ments fondamentaux n\u00e9cessaires pour permettre la communication \u00e0 distance entre deux applications.<\/p>\n
Voyons ensemble \u00e0 quoi sert chacun de ces \u00e9l\u00e9ments constitutifs. Comme de nombreux lecteurs connaissent bien DCOM, je mentionnerai \u00e9galement l'\u00e9quivalent DCOM de chaque \u00e9l\u00e9ment constitutif.<\/p>\n
En l'absence d'une m\u00e9thode standard pour formater les messages, il est pratiquement impossible de d\u00e9velopper un ensemble d'outils permettant de dissocier le d\u00e9veloppeur des protocoles sous-jacents. La mise en place d'une couche d'abstraction entre le d\u00e9veloppeur et les protocoles sous-jacents permet \u00e0 ce dernier de se concentrer davantage sur le probl\u00e8me m\u00e9tier \u00e0 r\u00e9soudre et moins sur l'infrastructure n\u00e9cessaire \u00e0 la mise en \u0153uvre de la solution.<\/p>\n
Choix de conception des services Web<\/b><\/p>\n
Abordons quelques-uns des choix de conception qui sous-tendent ces \u00e9l\u00e9ments constitutifs des services Web.<\/p>\n
Choix des protocoles de transport<\/b><\/p>\n
La premi\u00e8re \u00e9tape consistait \u00e0 d\u00e9terminer comment le client et le serveur allaient communiquer entre eux. Le client et le serveur peuvent se trouver sur le m\u00eame r\u00e9seau local, mais le client pourrait \u00e9galement communiquer avec le serveur via Internet. Le protocole de transport doit donc \u00eatre adapt\u00e9 aussi bien aux environnements de r\u00e9seau local qu'\u00e0 Internet.<\/p>\n
As I mentioned earlier, technologies such as DCOM, CORBA, and Java RMI are ill suited for supporting communication between the client and the server over the Internet. Protocols such as Hypertext Transfer Protocol (HTTP) and Simple Mail Transfer Protocol (SMTP) are proven Internet protocols. HTTP defines a request\/response messaging pattern for submitting a request and getting an associated response. SMTP defines a routable messaging protocol for asynchronous communication. Let’s examine why HTTP and SMTP are well suited for the Internet.<\/p>\n
HTTP-based Web applications are inherently stateless. They do not rely on a continuous connection between the client and the server. This makes HTTP an ideal protocol for high-availability configurations such as firewalls. If the server that handled the client’s original request becomes unavailable, subsequent requests can be automatically routed to another server without the client knowing or caring.<\/p>\n
Almost all companies have an infrastructure in place that supports SMTP. SMTP is well suited for asynchronous communication. If service is disrupted, the e-mail infrastructure automatically handles retries. Unlike with HTTP, you can pass SMTP messages to a local mail server that will attempt to deliver the mail message on your behalf.<\/p>\n
The other significant advantage of both HTTP and SMTP is their pervasiveness. Employees have come to rely on both e-mail and their Web browsers, and network administrators have a high comfort level supporting these services. Technologies such as network address translation (NAT) and proxy servers provide a way to access the Internet via HTTP from within otherwise isolated corporate LANs. Administrators will often expose an SMTP server that resides inside the firewall. Messages posted to this server will then be routed to their final destination via the Internet.<\/p>\n
In the case of credit card processing software, an immediate response is needed from the merchant bank to determine whether the order should be submitted to the ERP system. HTTP, with its request\/response message pattern, is well suited to this task.<\/p>\n
Most ERP software packages are not capable of handling large volumes of orders that can potentially be driven from the e-commerce application. In addition, it is not imperative that the orders be submitted to the ERP system in real time. Therefore, SMTP can be leveraged to queue orders so that they can be processed serially by the ERP system.<\/p>\n
If the ERP system supports distributed transactions, another option is to leverage Microsoft Message Queue Server (MSMQ). As long as the e-commerce application and the ERP system reside within the same LAN, connectivity via non-Internet protocols is less of an issue. The advantage MSMQ has over SMTP is that messages can be placed and removed from the queue within the scope of a transaction. If an attempt to process a message that was pulled off the queue fails, the message will automatically be placed back in the queue when the transaction aborts.<\/p>\n
Choosing an Encoding Scheme<\/b><\/p>\n
HTTP and SMTP provide a means of sending data between the client and the server. However, neither specifies how the data within the body of the message should be encoded. Microsoft needed a standard, platform-neutral way to encode data exchanged between the client and the server.<\/p>\n
Because the goal was to leverage Internet-based protocols, Extensible Markup Language (XML) was the natural choice. XML offers many advantages, including cross-platform support, a common type system, and support for industry -standard character sets.<\/p>\n
Binary encoding schemes such as those used by DCOM, CORBA, and Java RMI must address compatibility issues between different hardware platforms. For example, different hardware platforms have different internal binary representation of multi-byte numbers. Intel platforms order the bytes of a multi-byte number using the little endian convention; many RISC processors order the bytes of a multi-byte number using the big endian convention.<\/p>\n
XML avoids binary encoding issues because it uses a text-based encoding scheme that leverages standard character sets. Also, some transport protocols, such as SMTP, can contain only text-based messages.<\/p>\n
Binary methods of encoding, such as those used by DCOM and CORBA, are cumbersome and require a supporting infrastructure to abstract the developer from the details. XML is much lighter weight and easier to handle because it can be created and consumed using standard text-parsing techniques.<\/p>\n
In addition, a variety of XML parsers are available to further simplify the creation and consumption of XML documents on practically every modern platform. XML is lightweight and has excellent tool support, so XML encoding allows incredible reach because practically any client on any platform can communicate with your Web service.<\/p>\n
Choosing a Formatting Convention<\/b><\/p>\n
It is often necessary to include additional metadata with the body of the message. For example, you might want to include information about the type of services that a Web service needs to provide in order to fulfill your request, such as enlisting in a transaction or routing information. XML provides no mechanism for differentiating the body of the message from its associated data.<\/p>\n
Transport protocols such as HTTP provide an extensible mechanism for header data, but some data associated with the message might not be specific to the transport protocol. For example, the client might send a message that needs to be routed to multiple destinations, potentially over different transport protocols. If the routing information were placed into an HTTP header, it would have to be translated before being sent to the next intermediary over another transport protocol, such as SMTP. Because the routing information is specific to the message and not the transport protocol, it should be a part of the message.<\/p>\n
Simple Object Access Protocol (SOAP) provides a protocol-agnostic means of associating header information with the body of the message. Every SOAP message must define an envelope. The envelope has a body that contains the payload of the message and a header that can contain metadata associated with the message.<\/p>\n
SOAP imposes no restrictions on how the message body can be formatted. This is a potential concern because without a consistent way of encoding the data, it is difficult to develop a toolset that abstracts you from the underlying protocols. You might have to spend a fair amount of time getting up to speed on the Web service’s interface instead of solving the business problem at hand.<\/p>\n
What was needed was a standard way of formatting a remote procedure call (RPC) message and encoding its list of parameters. This is exactly what Section 7 of the SOAP specification provides. It describes a standard naming convention and encoding style for procedure-oriented messages.<\/p>\n
Because SOAP provides a standard format for serializing data into an XML message, platforms such as ASP.NET and Remoting can abstract away the details for you.<\/p>\n
Choosing Description Mechanisms<\/b><\/p>\n
SOAP provides a standard way of formatting messages exchanged between the Web service and the client. However, the client needs additional information in order to properly serialize the request and interpret the response. XML Schema provides a means of creating schemas that can be used to describe the contents of a message.<\/p>\n
XML Schema provides a core set of built-in datatypes that can be used to describe the contents of a message. You can also create your own datatypes. For example, the merchant bank can create a complex datatype to describe the content and structure of the body of a message used to submit a credit card payment request.<\/p>\n
A schema contains a set of datatype and element definitions. A Web service uses the schema not only to communicate the type of data that is expected to be within a message but also to validate incoming and outgoing messages.<\/p>\n
A schema alone does not provide enough information to effectively describe a Web service, however. The schema does not describe the message patterns between the client and the server. For example, a client needs to know whether to expect a response when an order is posted to the ERP system. A client also needs to know over what transport protocol the Web service expects to receive requests. Finally, the client needs to know the address where the Web service can be reached.<\/p>\n
This information is provided by a Web Services Description Language (WSDL) document. WSDL is an XML document that fully describes a particular Web service. Tools such as ASP.NET WSDL.exe and Remoting SOAPSUDS.exe can consume WSDL and automatically build proxies for the developer.<\/p>\n
As with any component used to build software, a Web service should also be accompanied by written documentation for developers who program against the Web service. The documentation should describe what the Web service does, the interfaces it exposes, and some examples of how to use it. Good documentation is especially important if the Web service is exposed to clients over the Internet.<\/p>\n
Choosing Discovery Mechanisms<\/b><\/p>\n
Once you’ve developed and documented a Web service, how can potential clients locate it? If the Web service is designed to be consumed by a member of your development team, your approach can be pretty informal, such as sharing the URL of the WSDL document with your peer a couple of cubicles down. But when potential clients are on the Internet, advertising your Web service effectively is an entirely different story.<\/p>\n
What’s needed is a common way to advertise Web services. Universal Description, Discovery, and Integration (UDDI) provides just such a mechanism. UDDI is an industry-standard centralized directory service that can be used to advertise and locate Web services. UDDI allows users to search for Web services using a host of search criteria, including company name, category, and type of Web service.<\/p>\n
Web services can also be advertised via DISCO, a proprietary XML document format defined by Microsoft that allows Web sites to advertise the services they expose. DISCO defines a simple protocol for facilitating a hyperlink style for locating resources. The primary consumer of DISCO is Microsoft Visual Studio.NET. A developer can target a particular Web server and navigate through the various Web services exposed by the server.<\/p>\n
What’s Missing from Web Services?<\/b><\/p>\n
You might have noticed that some key items found within a distributed component infrastructure are not defined by Web services. Two of the more noticeable omissions are a well-defined API for creating and consuming Web services and a set of component services, such as support for distributed transactions. Let’s discuss each of these missing pieces.<\/p>\n
In an effort to ensure that Web services are programming language-agnostic, Microsoft has left it up to individual software vendors to bind support for Web services to a particular platform. I will discuss two Web service implementations for the.NET platform, ASP.NET and Remoting, later in the book.<\/p>\n
Some services, such as support for distributed transactions, can be introduced later as the technology matures. Others, such as object pooling and possibly object lifetime management, can be considered an implementation detail of the platform. For example, Remoting defines extensions to provide support for object lifetime management, and Microsoft Component Services provides support for object pooling.<\/p>\n
Summary<\/b><\/p>\n
Component-based programming has proven to be a boon to developer productivity, but some services cannot be encapsulated by a component that resides within the client’s datacenter. Legacy technologies such as DCOM, CORBA, and Java RMI are ill-suited to allowing clients to access services over the Internet, so Microsoft found it necessary to start from the bottom and build an industry-standard way of accessing remote services.<\/p>\n
Services Web<\/i> is an umbrella term that describes a collection of industry- standard protocols and services used to facilitate a base-line level of interoperability between applications. The industry support that Web services has received is unprecedented. Never before have so many leading technology companies stepped up to support a standard that facilitates interoperability between applications, regardless of the platform on which they are run.<\/p>\n
One of the contributing factors to the success of Web services is that they’re built on existing Internet standards such as XML and HTTP. As a result, any system capable of parsing text and communicating via a standard Internet transport protocol can communicate with a Web service. Companies can also leverage the investment they have already made in these technologies.<\/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\/fr\/wp-json\/wp\/v2\/posts\/231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.smtp-server.net\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.smtp-server.net\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/fr\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/fr\/wp-json\/wp\/v2\/comments?post=231"}],"version-history":[{"count":1,"href":"https:\/\/www.smtp-server.net\/fr\/wp-json\/wp\/v2\/posts\/231\/revisions"}],"predecessor-version":[{"id":232,"href":"https:\/\/www.smtp-server.net\/fr\/wp-json\/wp\/v2\/posts\/231\/revisions\/232"}],"wp:attachment":[{"href":"https:\/\/www.smtp-server.net\/fr\/wp-json\/wp\/v2\/media?parent=231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.smtp-server.net\/fr\/wp-json\/wp\/v2\/categories?post=231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.smtp-server.net\/fr\/wp-json\/wp\/v2\/tags?post=231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}