Service forwarding addresses in distributed computing

A message sent to a first service addressed in a distributed computing environment having a service oriented architecture is received, wherein the message is directed to a service that is no longer present at the first service address. The message is forwarded to a second service address at which the service is located.

TECHNICAL FIELD

Embodiments of the present invention relate to distributed systems, and more specifically to forwarding messages in a service oriented architecture.

BACKGROUND

In distributed computing systems having a service oriented architecture, services may be provided by multiple servers at various locations. For a client to utilize available services, the client must know a service address and a service policy (including protocol and message format requirements) of the services. In conventional service oriented architectures, service addresses and service policies are maintained in a message registry along with service descriptions.

When a service address changes, the service registry must be updated to alert clients of the new service address. A client will not know to look for a new service address in the service registry until it fails to receive a response (or receives a fault) to one or more messages sent to the service at the original service address. Therefore, delays may occur in using services that have relocated to new service addresses. Moreover, there is a lag between when a service is updated, and when the updated service information is reflected in the service registry. Thus, the new service address may not be available immediately. Additionally, for some clients it may be burdensome to query the service registry for new service information when service addresses are changed.

DETAILED DESCRIPTION

Described herein is a method and apparatus for forwarding messages in a distributed computing system. In one embodiment, a message sent to a first service address in a distributed computing environment having a service oriented architecture is received. The message may be directed to a service that is no longer present at the first service address. The message may be received by a forwarder that may or may not be located at the first service address. The message is then forwarded to a second service address at which the service is located.

A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes a machine readable storage medium (e.g., read only memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical storage media, flash memory devices, etc.), a machine readable transmission medium (electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.)), etc.

FIG. 1illustrates an exemplary distributed computing system100, in which embodiments of the present invention may operate. In one embodiment, the distributed computing system100includes a service oriented architecture (SOA). A service oriented architecture (SOA) is an information system architecture that organizes and uses distributed capabilities (services) for one or more applications. SOA provides a uniform means to offer, discover, interact with and use capabilities (services) distributed over a network. Through the SOA, applications may be designed that combine loosely coupled and interoperable services.

The distributed computing system100may include clients (e.g., first client105and additional clients125) and services (e.g., first service110, additional services130and core ESB services115), connected via a network135. Each of the clients105and125and services110,115,130may be both message producers and message consumers, as described below.

The network135may be a public network (e.g., Internet), a private network (e.g., Ethernet or a local area Network (LAN)), or a combination thereof. In one embodiment, the network135includes an enterprise service bus (ESB). An ESB is an event-driven and standards-based messaging engine that provides services for more complex architectures. The ESB provides an infrastructure that links together services110,115,130and clients105and125to enable distributed applications and processes. The ESB may be implemented to facilitate an SOA. In one embodiment, the ESB is a single bus that logically interconnects all available services and clients. Alternatively, the ESB may include multiple busses, each of which may logically interconnect different services and/or clients.

Clients105and125may be, for example, personal computers (PC), palm-sized computing devices, personal digital assistants (PDA), etc. Clients105and125may also be applications run on a PC, server, database, etc. In the SOA, clients105and125include applications that access services110and130. Clients105and125may be fat clients (clients that perform local processing and data storage), thin clients (clients that perform minimal or no local processing and minimal to no data storage), and/or hybrid clients (clients that perform local processing but little to no data storage).

In the illustrated embodiment, the first client105is a message producer. Alternatively, additional clients125, first service110, additional services130or core ESB services115may be message producers. A message producer is a client or service that generates a message. Messages include data that may convey information to, or initiate an event on, a message consumer (e.g., a service or client). A message may be generated for any of a myriad of purposes. For example, the message may be generated to report a purchase of a good, to request contact information, to begin a remote process (e.g., initiate a service), etc.

In one embodiment, a message includes a message header, a message context and a message body. The message header may include a unique message identifier and routing information (e.g., recipient, sender, message priority, etc.). The message header may be used to identify the message, and to route the message to end points (recipients) intended by the message producer and/or as determined by the ESB (e.g., by a router within the ESB). The message may be directed to a specific endpoint (e.g., a specific client or service). Alternatively, the message may be posted to an intermediate location, which one or more endpoints may communicate with to receive the message.

The message context may include properties that support compatibility between services and clients (e.g., between the message producer and message consumers). The message context may provide, for example, custom fields or filters, transactional information (e.g., to identify a distributed transaction or session associated with the message), security information (e.g., authorization information, authentication information, etc.), and so on.

The message body may include data to which a client or service may respond (e.g., by initiating an event). The content and configuration (layout) of the message body may determine a message type. Examples of message types include text messages, map messages, bytes messages, stream messages and object messages. Other message types are also possible. In one embodiment, the message body is formatted using an extensible markup language (XML). Use of XML allows flexible information formats to be implemented. Other flexible information formats, such as standard generalized markup language (SGML) may also be used for the message body.

Services110and130may be discretely defined sets of contiguous and autonomous functionality (e.g., business functionality, technical functionality, etc.). Services110and130may be resident on personal computers (PC), servers, routers, etc. Each service110and130may represent a process, activity or other resource that can be accessed and used by other services or clients on network135. Each service110and130may be independent of other services110and130, and may be accessed without knowledge of its underlying platform implementation.

In an example for a business function of “managing orders,” services may include, for example, create order, fulfill order, ship order, invoice order, cancel/update order, etc. Each such service may be autonomous from the other services that are used to manage orders, and may be remote from one another and have different platform implementations. However, the services may be combined and used by one or more applications to manage orders.

Each service may have a service address to which messages directed to the service are sent. The service address is included in a header of a message. A format of the service address may depend on a transport mechanism used by the service. For example, if the transport mechanism is HTTP or FTP, then the service address may include a host number and a port number. If, on the other hand, the transport mechanism is JMS, the service address may be a JMS queue number. If a message is sent to an incorrect service address, a message cannot be processed by the service.

In the illustrated embodiment, the first service110is a message consumer. Alternatively, first client105, additional clients125, core ESB services115or additional services130may be message consumers. A message consumer receives a message generated by a message producer, and sent to an address (e.g., service address or client address) of the message consumer. Based on the content of the message, the message consumer may store information contained in the message, generate a response message to send to a service or client, undergo a state change, and/or initiate some other event. A state change initiated by a message may be dependent on contents of the message (e.g., the message body, message context, etc.), rules governing responses to the message, etc.

In one embodiment, the distributed computing system100includes an ESB that has a collection of core ESB services115. The core ESB services115act on messages that flow through the ESB. Messages can also be directed towards any of the core ESB services115in the same manner as described above with reference to the first service110and additional services130. Any of the core ESB services115may include one or more general purpose computing devices (e.g., personal computer or server) and/or a special purpose computing devices configured to act on messages that flow between message producers (e.g., clients or services) and message consumers (e.g., clients or services) within the ESB.

In one embodiment, the core ESB services115include a service registry145. The service registry145includes information on some or all services of the ESB. In one embodiment, the service registry145includes multiple service entries, each of which includes service information for a single service or set of services. A service entry may include a formal service description (e.g., identifying a service as a flight booking service), service policy (which may include message context requirements (e.g., custom fields or filters, transactional information, security information, transactional requirements, reliability characteristics, whether the service is secure, etc.), service capabilities, protocol and message format requirements, etc.), and a service address (e.g., a host number and a port number for services using HTTP or FTP, a JMS queue name for services using JMS, etc.).

A client105,125may search the service registry145to determine what services are available on the ESB, and where the services are located (e.g., the service addresses). The search may be performed by sending a message to the service registry145requesting information on one or more services, types of services, etc. (e.g., by using a search query, or by browsing the service registry145). Once an appropriate service has been identified, the client105,125may send a message to the service110,130using an appropriate service address.

For a service110,130to be included in the service registry145, that service may send a message to the service registry145identifying information about the service (e.g., service policy, service address, description, etc.). Services110,130on the ESB may occasionally be modified to change a service address, and the service registry145may be notified of the modification. When the service registry145is next updated, the new service address will be reflected in the service registry145.

In one embodiment, the core ESB services115include a content based router120. The content based router120is a service of the ESB that monitors the network135for messages, and transparently routes the messages between clients and services.

In one embodiment, the content based router120acts as a forwarder for one or more services on the ESB (e.g., first service110). When the content based router120intercepts a message from a message producer (e.g., first client105), the content based router120may examine a header and/or other contents of the message to determine whether it is directed to an active service address or addresses of the service. Those messages directed to a specific service address that is no longer active are then forwarded to a specified different service address. A service may therefore receive messages that are sent to old service addresses that are no longer active. For example, content based router120may be set to forward all messages addressed to a first (old) service address of first service110to a second (new) service address of first service110. First service110may therefore be moved as necessary without inconvenience to clients105,125.

In another embodiment, content based router120acts as a switchboard, directing some or all message traffic between clients105,125and services110,115,130. In such an embodiment, some or all messages may be directed to the content based router120. A client105,125may not need to know a service address of an intended service to send a message to it. Instead, a client may only need to know a name or other identifying information of the service110,115,130. Content based router120may then direct incoming messages to appropriate services based on service names or other identifying information.

Content based router120may maintain a list of some or all services110,115,130on the ESB, along with a current service address for each service. The list of service addresses may be used to send each received message to an appropriate service address of an intended service. Content based router120may receive service address updates from services110,115,130as services are relocated. So long as services promptly notify the content based router120of updated service addresses, services may be relocated at the discretion of service providers without inconveniencing clients105,125.

The core ESB services115may include one or more additional modules150, each of which may be a service of the ESB. Examples of additional modules150include modules that provide services for splitting a message into multiple messages, combining multiple messages into a single message, transforming messages from a first format to a second format, applying rules to a message, storing copies of messages, etc. Each additional module150may provide a service to clients105and125and/or services110and130of the distributed computing system100.

FIG. 2Aillustrates a data flow diagram200showing a message flowing through an ESB, in accordance with one embodiment of the present invention. In one embodiment, the ESB is included in distributed computing system100ofFIG. 1.

Returning toFIG. 2A, a client205generates a message that is addressed to a first service address210. Client205then transmits the message to the first service address210.

A forwarder215is located at the first service address210, and receives the message. Forwarder215then forwards the message to a second service address220, at which service225(which previously may have been located at the first service address210) may be located. Forwarder215may have been installed at the first service address210to forward messages to the second service address220when service225was moved to the second service address220. The forwarder215may be a simple forwarder that is configured to forward all received messages to second service address220. Forwarder215may forward messages to the second service address220regardless of message context, message header, or other message content. Moreover, forwarder215may forward messages to second service address220without examining the messages. Therefore, clients may not need to query a service registry to determine a new service address of service225.

Service225receives the forwarded message, and processes it. Service225may then generate a response message, which may be transmitted back to the client205. In one embodiment, the response message is sent back to the client205through the forwarder215. Alternatively, the response message may be sent directly to the client205. Upon receiving the response message, client205may be informed that the service225is now at the second service address220, and subsequent messages may accordingly be sent directly to the second service address220.

In one embodiment, the first service address210and second service address220are hosted by a single machine (e.g., by a single server). Alternatively, the first service address210and second service address220may be hosted by different machines (e.g., by different servers). For the forwarder215to be installed at the first service address210, a server having the first service address210may need to remain in operation.

If service225is moved multiple times, then multiple forwarders may be used. For example, forwarder215may continue to forward messages to second service address220, and an additional forwarder may forward messages to a third service address (not shown). Therefore, messages sent to the first service address210would be forwarded to the second service address220, and then forwarded to the third service address. Alternatively, forwarder215may be reconfigured to forward messages to the third service address. Therefore, messages sent to the first service address210would be forwarded to the third service address, and messages sent to the second service address220would also be forwarded to the third service address.

FIG. 2Billustrates a data flow diagram230showing messages flowing through an ESB, in accordance with another embodiment of the present invention. In one embodiment, the ESB is included in distributed computing system100ofFIG. 1.

Returning toFIG. 2B, a first client235generates a first message addressed to a first service address250, to which the first message is sent. A second client240generates a second message addressed to a third service address255, to which the second message is sent.

A forwarder245is hosted by a machine (e.g., a server) covering the first service address250and the third service address255. The forwarder245may monitor the first service address250and third service address255for received messages. Forwarder245may receive the first message and the second message when they arrive at the first service address250and the third service address255, respectively. Forwarder245may then examine a header of the first message and the second message. Forwarder245may forward messages sent to the first service address250to a second service address260, and may forward messages sent to the third service address255to a fourth service address264. Alternatively, a separate forwarder may be located at each of the first service address250and the third service address255. Such separate forwarders may not need to examine a header of a message to determine where the message should be forwarded.

A first service257is located at the second service address260, and receives the first forwarded message. First service257may process the first forwarded message and generate a first response message, which may be transmitted back to the first client235. A second service262is located at the fourth service address264, and receives the second forwarded message. Second service257may process the second forwarded message and generate a second response message, which may be transmitted back to the second client240. Response messages may be sent back to the appropriate clients235,240through the forwarder245. Alternatively, the response messages may be sent directly to the clients235,240.

FIG. 2Cillustrates a data flow diagram270showing messages flowing through an ESB, in accordance with yet another embodiment of the present invention. In one embodiment, the ESB is included in a distributed computing system100ofFIG. 1.

Returning toFIG. 2C, a first client235generates a first message and sends it to a first service address (not shown). A second client240generates a second message and sends it to a third service address (not shown).

A content based router276(described above with reference toFIG. 1) intercepts the first message and the second message. In one embodiment, the content based router276includes a rules engine278and one or more forwarding rules280.

The rules engine278is a logic component that processes rules (e.g., forwarding rules280) to produce outcomes. The rules engine278may match facts, data and rules, and infer conclusions which may result in actions or events of, for example, a message consumer. In one embodiment, the rules engine278matches the facts, data and rules using a Rete Algorithm. Alternatively, the rules engine may use a Linear Algorithm, Treat Algorithm, Leaps Algorithm, etc. Hybrid algorithms that use combinations of, for example, the Leaps Algorithm and the Rete Algorithm, may also be used.

Forwarding rules280are rules that are processed by rules engine278. Each of the forwarding rules280may identify a forwarding address or forwarding addresses for one or more original addresses. Therefore, when content based router276receives the first message, it may process a first forwarding rule to determine that the first message (addressed to the first service address) should be sent to a second service address284. Likewise, when the content based router receives the second message, it may process a second forwarding rule (or the first forwarding rule) to determine that the second message (addressed to the third service address) should be forwarded to the fourth service address. Content based router276may then forward the first message to the second service address284and the second message to the fourth service address288in accordance with the forwarding rules280.

Use of the content based router276as a forwarder allows a machine (e.g., a server) on which a service was originally located to be shut down. Other forwarders (e.g., those located at the first service address or third service address) may require that the machine on which the service was originally located remain activated and connected to the ESB.

A first service282is located at the second service address284, and receives the first forwarded message. First service282may process the first forwarded message and generate a first response message, which may be transmitted back to the first client272. A second service286is located at the fourth service address288, and receives the second forwarded message. Second service286may process the second forwarded message and generate a second response message, which may be transmitted back to the second client274. Response messages may be sent back to the appropriate clients272,274through the content based router276. Alternatively, the response messages may be sent directly to the clients272,274.

FIG. 3illustrates a flow diagram of one embodiment for a method300of forwarding messages in a distributed computing system. In one embodiment, the distributed computing system is a service oriented architecture (SOA) that includes an enterprise service bus (ESB). The method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), or a combination thereof. In one embodiment, method300is performed by one or more services of distributed computing system100ofFIG. 1.

Referring toFIG. 3, method300includes receiving a message at a first service address (block305). At block310, the message is forwarded to a second service address. In one embodiment, the message is forwarded to the second service address without examining the contents of the message (e.g., the message header, message context, etc.). In another embodiment, the message is forwarded after examining a header of the message to determine a service address to which the message is addressed. In yet another embodiment, the message is forwarded after examining additional message contents of the message.

FIG. 4illustrates a flow diagram of another embodiment for a method400of forwarding messages in a distributed computing system. In one embodiment, the distributed computing system is a service oriented architecture (SOA) that includes an enterprise service bus (ESB). The method may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), or a combination thereof. In one embodiment, method400is performed by one or more services of distributed computing system100ofFIG. 1.

Referring toFIG. 4, method400includes monitoring for messages (block405). In one embodiment, all messages passing through an ESB are monitored (e.g., by a content based router). Alternatively, one or more service addresses may be monitored for incoming messages.

At block415processing logic determines whether a message has been received (e.g., by a content based router or at a service address). If a message is received, the method proceeds to block415. If no message is received, the method continues to block405, and processing logic continues to monitor for messages.

At block415, the contents of a received message are examined. In one embodiment, only a header of the received message is examined. Alternatively, other contents of the received message may be examined, such as a message context and message body.

At block420, processing logic determines whether the message is directed to a first service address. If the message is directed to the first service address, the method proceeds to block435, and the message is forwarded to a second service address. If the message is not directed to the first service address, the method continues to block425.

At block425, processing logic determines whether the message is directed to a third service address. If the message is directed to the third service address, the method proceeds to block430, and the message is forwarded to a fourth service address. If the message is not directed to the third service address, the method ends.

Though method400has been discussed with reference to messages directed to a first and a second service address, method400may equally apply to messages directed to additional service addresses. For example, different forwarding rules and/or forwarders may be used to forward messages directed to five different service addresses, ten different service address, etc. Therefore, method400may accommodate any number of services that change service addresses in a distributed computing system.

The data storage device518may include a machine-accessible storage medium531on which is stored one or more sets of instructions (e.g., software522) embodying any one or more of the methodologies or functions described herein. The software522may also reside, completely or at least partially, within the main memory504and/or within the processor502during execution thereof by the computer system500, the main memory504and the processor502also constituting machine-accessible storage media. The software522may further be transmitted or received over a network520via the network interface device508.

The machine-accessible storage medium531may also be used to store data structure sets that define user identifying states and user preferences that define user profiles. Data structure sets and user profiles may also be stored in other sections of computer system500, such as static memory506.