Internet Services Architecture

At the onset, the Internet supported predominantly client-server type of service architectures, wherein a client made a request of a server and the server provided the service. The service could be as simple as a one-time generated piece of information (for instance, ldap, ntp, etc.), or it could be more complex, like a ftp or a telnet session. The next step to the client-server architectures was the move toward distributed objects.

Distributed object frameworks — like Distributed Component Object Model (DCOM), Common Object Request Broker Architecture (CORBA), and Remote Method Invocation (RMI) — hid the complexities of client—server interactions in well-defined application programming interfaces (APIs). Programmers no longer needed to worry about Internet addresses and port numbers to access servers, or even how to structure the protocol data unit for a service. Precompilers read an interface definition file and generated the corresponding server skeletons and client stubs. The application programmer had to only fill in the application-specific logic in the generated code. Over the years, distributed object frameworks have evolved to provide message reliability and transactional guarantees.

The next step beyond distributed objects is service-oriented computing (SOC) and service-oriented architectures (SOAs), as exemplified by Web services. Papazoglou and Georgakapoulous [PAP03a] describe SOC best as a "computing paradigm that utilizes services as fundamental elements for developing applications." They go on to provide the following description of SOA: "Basic services, their description, and basic operations (publication, discovery, selection, and binding) that produce or utilize such descriptions constitute the SOA foundation."

Software Agent (Service Consumer)

Software Agent (Service Provider)

Response

UDDI

UDDI

Software Agent (Service Consumer)

WSDL-Described Services

Software Agent (Service Provider)

Response

Figure 2.2 Web Services Architecture.

SOAs are characterized by loose coupling between the interacting software agents. The software agents exchange well-defined messages to execute services. The format and semantics of these messages are collectively defined by Web services. Web services transport eXtensible Markup Language (XML) documents between software agents using standard Internet protocols. Software agents that send and receive these documents implement the semantics of a particular service.

Web services are described using the Web Services Definition Language (WSDL), which is an XML format for describing network services as a set of endpoints operating on messages [CHR01]. WSDL describes all information pertinent to a Web service: its name, transport binding (using Simple Object Access Protocol (SOAP), Hypertext Transfer Protocol (HTTP), or Multipurpose Internet Mail Extension (MIME)), and a set of operations supported by the service. Once described as such, services are stored in a Universal Description, Discovery, and Integration (UDDI) registry. Clients can query the registry to get a listing of all matching services. Figure 2.2 contains an overview of this process. A software agent (service producer) describes the services it supports through WSDL and registers them with a UDDI registry. At some later point, another software agent (service consumer) looks up the service in the UDDI and contacts the service producer directly to execute the service.

0 0

Post a comment