Przegl\u0105d<\/b>
\nProgramowanie oparte na komponentach sta\u0142o si\u0119 bardziej popularne ni\u017c kiedykolwiek. Prawie nie buduje si\u0119 dzi\u015b aplikacji, kt\u00f3ra nie wykorzystuje komponent\u00f3w w jakiej\u015b formie, zwykle od r\u00f3\u017cnych dostawc\u00f3w. Poniewa\u017c aplikacje sta\u0142y si\u0119 bardziej wyrafinowane, wzros\u0142a r\u00f3wnie\u017c potrzeba wykorzystania komponent\u00f3w rozproszonych na zdalnych maszynach.<\/p>\n
<\/p>\n
Przyk\u0142adem aplikacji opartej na komponentach jest kompleksowe rozwi\u0105zanie e-commerce. Aplikacja e-commerce rezyduj\u0105ca na farmie internetowej musi przesy\u0142a\u0107 zam\u00f3wienia do aplikacji planowania zasob\u00f3w przedsi\u0119biorstwa (ERP). W wielu przypadkach aplikacja ERP znajduje si\u0119 na innym sprz\u0119cie i mo\u017ce dzia\u0142a\u0107 na innym systemie operacyjnym.<\/p>\n
Microsoft Distributed Component Object Model (DCOM), rozproszona infrastruktura obiektowa, kt\u00f3ra umo\u017cliwia aplikacji wywo\u0142ywanie komponent\u00f3w Component Object Model (COM) zainstalowanych na innym serwerze, zosta\u0142a przeniesiona na wiele platform innych ni\u017c Windows. Jednak DCOM nigdy nie zyska\u0142 szerokiej akceptacji na tych platformach, wi\u0119c rzadko jest u\u017cywany do u\u0142atwienia komunikacji mi\u0119dzy komputerami z systemem Windows i innymi systemami. Dostawcy oprogramowania ERP cz\u0119sto tworz\u0105 komponenty dla platformy Windows, kt\u00f3re komunikuj\u0105 si\u0119 z systemem zaplecza za po\u015brednictwem zastrze\u017conego protoko\u0142u.<\/p>\n
Niekt\u00f3re us\u0142ugi wykorzystywane przez aplikacj\u0119 e-commerce mog\u0105 w og\u00f3le nie znajdowa\u0107 si\u0119 w centrum danych. Na przyk\u0142ad, je\u015bli aplikacja e-commerce akceptuje p\u0142atno\u015b\u0107 kart\u0105 kredytow\u0105 za towary zakupione przez klienta, musi wywo\u0142a\u0107 us\u0142ugi banku handlowego w celu przetworzenia informacji o karcie kredytowej klienta. Jednak ze wzgl\u0119d\u00f3w praktycznych DCOM i powi\u0105zane technologie, takie jak CORBA i Java RMI, s\u0105 ograniczone do aplikacji i komponent\u00f3w zainstalowanych w korporacyjnym centrum danych. Dwa g\u0142\u00f3wne powody tego s\u0105 takie, \u017ce domy\u015blnie technologie te wykorzystuj\u0105 zastrze\u017cone protoko\u0142y, a protoko\u0142y te s\u0105 z natury zorientowane na po\u0142\u0105czenia.<\/p>\n
Klienci komunikuj\u0105cy si\u0119 z serwerem przez Internet napotykaj\u0105 wiele potencjalnych barier w komunikacji z serwerem. \u015awiadomi bezpiecze\u0144stwa administratorzy sieci na ca\u0142ym \u015bwiecie wdro\u017cyli routery korporacyjne i zapory ogniowe, aby uniemo\u017cliwi\u0107 praktycznie ka\u017cdy rodzaj komunikacji przez Internet. Cz\u0119sto potrzeba aktu bo\u017cego, aby administrator sieci otworzy\u0142 porty poza absolutnym minimum.<\/p>\n
Je\u015bli masz wystarczaj\u0105co du\u017co szcz\u0119\u015bcia, aby administrator sieci otworzy\u0142 odpowiednie porty do obs\u0142ugi Twojej us\u0142ugi, prawdopodobnie Twoi klienci nie b\u0119d\u0105 mieli tyle szcz\u0119\u015bcia. W rezultacie zastrze\u017cone protoko\u0142y, takie jak te u\u017cywane przez DCOM, CORBA i Java RMI, nie s\u0105 praktyczne w scenariuszach internetowych.<\/p>\n
Jak ju\u017c wspomnia\u0142em, innym problemem zwi\u0105zanym z tymi technologiami jest to, \u017ce s\u0105 one z natury zorientowane na po\u0142\u0105czenia i dlatego nie s\u0105 w stanie sprawnie radzi\u0107 sobie z przerwami w sieci. Poniewa\u017c Internet nie jest pod bezpo\u015bredni\u0105 kontrol\u0105 u\u017cytkownika, nie mo\u017cna przyjmowa\u0107 \u017cadnych za\u0142o\u017ce\u0144 dotycz\u0105cych jako\u015bci lub niezawodno\u015bci po\u0142\u0105czenia. Je\u015bli wyst\u0105pi przerwa w sieci, nast\u0119pne po\u0142\u0105czenie klienta z serwerem mo\u017ce zako\u0144czy\u0107 si\u0119 niepowodzeniem.<\/p>\n
Zorientowany na po\u0142\u0105czenia charakter tych technologii sprawia r\u00f3wnie\u017c, \u017ce trudno jest zbudowa\u0107 infrastruktur\u0119 r\u00f3wnowa\u017c\u0105c\u0105 obci\u0105\u017cenie, niezb\u0119dn\u0105 do osi\u0105gni\u0119cia wysokiej skalowalno\u015bci. Po zerwaniu po\u0142\u0105czenia mi\u0119dzy klientem a serwerem nie mo\u017cna po prostu skierowa\u0107 nast\u0119pnego \u017c\u0105dania do innego serwera.<\/p>\n
Deweloperzy pr\u00f3bowali przezwyci\u0119\u017cy\u0107 te ograniczenia, wykorzystuj\u0105c model o nazwie bezpa\u0144stwowy <\/i>programowanie<\/i>, ale odnios\u0142y one ograniczony sukces, poniewa\u017c technologie te s\u0105 do\u015b\u0107 ci\u0119\u017ckie i sprawiaj\u0105, \u017ce ponowne nawi\u0105zanie po\u0142\u0105czenia ze zdalnym obiektem jest kosztowne.<\/p>\n
Poniewa\u017c przetwarzanie karty kredytowej klienta jest realizowane przez zdalny serwer w Internecie, DCOM nie jest idealny do u\u0142atwiania komunikacji mi\u0119dzy klientem e-commerce a serwerem przetwarzania kart kredytowych. Podobnie jak w przypadku rozwi\u0105zania ERP, komponent innej firmy jest cz\u0119sto instalowany w centrum danych klienta (w tym przypadku przez dostawc\u0119 rozwi\u0105zania do przetwarzania kart kredytowych). Komponent ten s\u0142u\u017cy jako niewiele wi\u0119cej ni\u017c proxy, kt\u00f3re u\u0142atwia komunikacj\u0119 mi\u0119dzy oprogramowaniem e-commerce a bankiem handlowym za po\u015brednictwem zastrze\u017conego protoko\u0142u.<\/p>\n
Czy widzisz tu jaki\u015b wz\u00f3r? Ze wzgl\u0119du na ograniczenia istniej\u0105cych technologii w u\u0142atwianiu komunikacji mi\u0119dzy systemami komputerowymi, producenci oprogramowania cz\u0119sto uciekaj\u0105 si\u0119 do budowania w\u0142asnej infrastruktury. Oznacza to, \u017ce zasoby, kt\u00f3re mog\u0142y zosta\u0107 wykorzystane do dodania ulepszonej funkcjonalno\u015bci do systemu ERP lub systemu przetwarzania kart kredytowych, zosta\u0142y zamiast tego po\u015bwi\u0119cone na pisanie zastrze\u017conych protoko\u0142\u00f3w sieciowych.<\/p>\n
Staraj\u0105c si\u0119 lepiej wspiera\u0107 takie scenariusze internetowe, Microsoft pocz\u0105tkowo przyj\u0105\u0142 strategi\u0119 rozszerzania istniej\u0105cych technologii, w tym COM Internet Services (CIS), kt\u00f3ra pozwala na ustanowienie po\u0142\u0105czenia DCOM mi\u0119dzy klientem a zdalnym komponentem przez port 80. Z r\u00f3\u017cnych powod\u00f3w CIS nie zosta\u0142 powszechnie zaakceptowany.<\/p>\n
Sta\u0142o si\u0119 jasne, \u017ce potrzebne jest nowe podej\u015bcie. Firma Microsoft postanowi\u0142a wi\u0119c rozwi\u0105za\u0107 ten problem oddolnie. Przyjrzyjmy si\u0119 niekt\u00f3rym wymaganiom, kt\u00f3re rozwi\u0105zanie musia\u0142o spe\u0142ni\u0107, aby odnie\u015b\u0107 sukces.<\/p>\n
Bior\u0105c pod uwag\u0119 tytu\u0142 tej ksi\u0105\u017cki, nie powinno dziwi\u0107, \u017ce rozwi\u0105zanie stworzone przez Microsoft jest znane jako Us\u0142ugi sieciowe<\/i>. Us\u0142uga sieciowa udost\u0119pnia interfejs do wywo\u0142ywania okre\u015blonego dzia\u0142ania w imieniu klienta. Klient mo\u017ce uzyska\u0107 dost\u0119p do us\u0142ugi sieci Web poprzez wykorzystanie standard\u00f3w internetowych.<\/p>\n
Bloki konstrukcyjne us\u0142ug sieciowych<\/b>
\nPoni\u017csza grafika przedstawia podstawowe bloki konstrukcyjne potrzebne do u\u0142atwienia zdalnej komunikacji mi\u0119dzy dwiema aplikacjami.<\/p>\n
Om\u00f3wmy cel ka\u017cdego z tych blok\u00f3w konstrukcyjnych. Poniewa\u017c wielu czytelnik\u00f3w zna DCOM, wspomn\u0119 r\u00f3wnie\u017c o odpowiedniku DCOM ka\u017cdego bloku konstrukcyjnego.<\/p>\n
Bez standardowego sposobu formatowania wiadomo\u015bci, opracowanie zestawu narz\u0119dzi abstrahuj\u0105cych dewelopera od podstawowych protoko\u0142\u00f3w jest prawie niemo\u017cliwe. Stworzenie warstwy abstrakcji mi\u0119dzy deweloperem a podstawowymi protoko\u0142ami pozwala deweloperowi skupi\u0107 si\u0119 bardziej na danym problemie biznesowym, a mniej na infrastrukturze wymaganej do wdro\u017cenia rozwi\u0105zania.<\/p>\n
Decyzje dotycz\u0105ce projektowania us\u0142ug internetowych<\/b><\/p>\n
Let’s discuss some of the design decisions behind these building blocks for Web services.<\/p>\n
Choosing Transport Protocols<\/b><\/p>\n
The first step was to determine how the client and the server would communicate with each other. The client and the server can reside on the same LAN, but the client might potentially communicate with the server over the Internet. Therefore, the transport protocol must be equally suited to LAN environments and the 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
Us\u0142ugi sieciowe<\/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\/pl\/wp-json\/wp\/v2\/posts\/231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.smtp-server.net\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.smtp-server.net\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/pl\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/pl\/wp-json\/wp\/v2\/comments?post=231"}],"version-history":[{"count":1,"href":"https:\/\/www.smtp-server.net\/pl\/wp-json\/wp\/v2\/posts\/231\/revisions"}],"predecessor-version":[{"id":232,"href":"https:\/\/www.smtp-server.net\/pl\/wp-json\/wp\/v2\/posts\/231\/revisions\/232"}],"wp:attachment":[{"href":"https:\/\/www.smtp-server.net\/pl\/wp-json\/wp\/v2\/media?parent=231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.smtp-server.net\/pl\/wp-json\/wp\/v2\/categories?post=231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.smtp-server.net\/pl\/wp-json\/wp\/v2\/tags?post=231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}