U.S. patent application number 12/750143 was filed with the patent office on 2011-06-30 for method and system to automatically adapt web services from one protocol/idiom to another protocol/idiom.
This patent application is currently assigned to BMC SOFTWARE, INC.. Invention is credited to Vincent Joseph Kowalski.
Application Number | 20110161465 12/750143 |
Document ID | / |
Family ID | 44188797 |
Filed Date | 2011-06-30 |
United States Patent
Application |
20110161465 |
Kind Code |
A1 |
Kowalski; Vincent Joseph |
June 30, 2011 |
Method and System to Automatically Adapt Web Services from One
Protocol/Idiom to Another Protocol/Idiom
Abstract
Disclosed are embodiments of a method and system to convert an
existing web services request from a first web services
implementation type to a second web services implementation type.
Example implementation types include SOAP-based and
Representational State Transfer (RESTful). Conversion may be
achieved through use of a generic web services adaptor. The generic
web services adaptor can provide a plurality of interface types and
convert requests to a request type supported by an existing web
service provider endpoint. In some embodiments, requests not
requiring a conversion may be forwarded directly to an existing web
service provider endpoint.
Inventors: |
Kowalski; Vincent Joseph;
(Houston, TX) |
Assignee: |
BMC SOFTWARE, INC.
Houston
TX
|
Family ID: |
44188797 |
Appl. No.: |
12/750143 |
Filed: |
March 30, 2010 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12650107 |
Dec 30, 2009 |
|
|
|
12750143 |
|
|
|
|
Current U.S.
Class: |
709/219 |
Current CPC
Class: |
H04L 67/02 20130101;
H04L 67/2823 20130101; H04L 69/08 20130101 |
Class at
Publication: |
709/219 |
International
Class: |
G06F 15/16 20060101
G06F015/16 |
Claims
1. A method of processing a web services request on a programmable
control device, the method comprising: receiving a web services
request targeted for a first web services interface type;
translating the web services request, on the programmable control
device, to a second web services interface type; sending the
translated web services request to a web services endpoint;
receiving a response from the web services endpoint; translating
the response to be compliant with the first web services interface
type; and responding to the received web services request.
2. The method of claim 1, wherein the web services endpoint
functionality and the steps of translation are provided by a single
computer system.
3. The method of claim 1, wherein the first web services interface
type is SOAP and the second web services interface type is
RESTful.
4. The method of claim 1, wherein the first web services interface
type is RESTful and the second web service interface type is
SOAP.
5. The method of claim 2 wherein the RESTful web services request
is classified as part of the act of translating the web services
request.
6. The method of claim 1, wherein the first web services interface
type is selected from the group consisting of XML-RPC, JSON, HTTP,
RESTful, and SOAP and the second web service interface type is
selected from the group consisting of XML-RPC, JSON, HTTP, RESTful,
and SOAP.
7. A method of processing a web services request on a programmable
control device, the method comprising: receiving, on a programmable
control device, a web services request from a web services client
in a first web services format and an indication of a web services
endpoint; identifying the web services endpoint using the
indication; determining an interface type of an exposed web service
interface on the web services endpoint; translating the received
web services request to be compliant with the determined interface
type if the determined interface type is not already compliant with
the first web services format; sending a compliant web services
request to the web services endpoint; receiving a response from the
web services endpoint; translating the response to be compliant
with the first web services format if the response is not already
compliant with the first web services format; and sending a
response, compliant with the first web services format, to the web
services client.
8. The method of claim 7, wherein the functionality of the
identified web services endpoint and the steps of translation are
provided by a single computer.
9. The method of claim 7, wherein the first web services format is
SOAP and the determined interface type is RESTful.
10. The method of claim 7, wherein the first web services format is
RESTful and the determined interface type is SOAP.
11. The method of claim 10 wherein the RESTful web services request
is classified as part of the act of translating the received web
services request.
12. The method of claim 7, wherein the first web services format is
selected from the group consisting of XML-RPC, JSON, HTTP, RESTful,
and SOAP and the determined interface type is selected from the
group consisting of XML-RPC, JSON, HTTP, RESTful, and SOAP.
13. A computer readable medium comprising computer readable
instructions stored thereon to cause a programmable control device
to perform the method of claim 1.
14. A computer readable medium comprising computer readable
instructions stored thereon to cause a programmable control device
to perform the method of claim 7.
15. A computer system comprising one or more programmable control
devices communicatively coupled to each other and to a computer
network, wherein the one or more programmable control devices are
programmed to: receive a web services request, from the computer
network, targeted for a first web services interface type;
translate the web services request, on the one or more programmable
control devices, to a second web services interface type; send the
translated web services request to a web services endpoint; receive
a response from the web services endpoint; translate the response
to be compliant with the first web services interface type; and
respond to the received web services request.
16. The computer system of claim 15, wherein the first web services
interface type is SOAP and the second web services interface type
is RESTful.
17. The computer system of claim 15, wherein the first web services
interface type is RESTful and the second web service interface type
is SOAP.
18. The computer system of claim 15 wherein the one or more
programmable control devices is further programmed to perform the
programmed acts of receiving and sending to and from a plurality of
web services endpoints and web services clients concurrently and
wherein the programmed act of translating a plurality of different
web services interface types is also performed concurrently.
19. A computer system comprising one or more programmable control
devices communicatively coupled to each other and to a computer
network, wherein the one or more programmable control devices are
programmed to: receive, on one of the one or more programmable
control devices via the computer network, a web services request
from a web services client in a first web services format and an
indication of a web services endpoint; identify the web services
endpoint using the indication; determine an interface type of an
exposed web service interface on the web services endpoint;
translate the received web services request to be compliant with
the determined interface type if the determined interface type is
not already compliant with the first web services format; send a
compliant web services request to the web services endpoint;
receive a response from the web services endpoint; translate the
response to be compliant with the first web services format if the
response is not already compliant with the first web services
format; and send a response, compliant with the first web services
format, to the web services client.
20. The computer system of claim 19, wherein the first web services
format is SOAP and the determined interface type is RESTful.
21. The computer system of claim 19, wherein the first web services
format is RESTful and the determined interface type is SOAP.
22. A computer network comprising: a plurality of processing units
communicatively coupled to a computer network; a first processing
unit configured to perform at least a portion of the method of
claim 1 wherein the entire method of claim 1 is performed
collectively by the plurality of processing units.
23. A computer network comprising: a plurality of processing units
communicatively coupled to a computer network; a first processing
unit configured to perform at least a portion of the method of
claim 7 wherein the entire method of claim 7 is performed
collectively by the plurality of processing units.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This disclosure is a continuation in part of U.S. patent
application Ser. No. 12/650,107 entitled "A Method and System to
Automatically Adapt Web Services from one Protocol/Idiom to Another
Protocol/Idiom" by Vincent Kowalski filed 30 Dec. 2009 and which is
incorporated by reference herein in its entirety.
BACKGROUND
[0002] This disclosure relates generally to the field of web
services. More particularly, but not by way of limitation, this
disclosure refers to a method of adapting web services based on
different implementations (e.g., SOAP or RESTful) to an
implementation style other than that for which a web service was
originally provided.
[0003] In the web services world, Representational State Transfer
(REST) is a design architecture that embraces a stateless
client-server architecture in which the web services are viewed as
resources and can be identified by their Universal Resource
Locators (URLs). Web services clients that want to use these
resources may access a particular representation by transferring
application content using a small globally defined set of remote
methods that describe the action to be performed on the
resource.
[0004] SOAP used to be an acronym that stood for Simple Object
Access Protocol. However over time the acronym was dropped and
there is now no official meaning attributed to the name SOAP. As
used herein, SOAP is built on top of eXtensible Markup Language
(XML). SOAP is a protocol in which operations (similar to functions
or subroutines in standard programming languages) are invoked. This
invocation typically causes an implementation on a server (e.g.,
SOAP web services endpoint) to execute some code (e.g., business
logic) and return a result. SOAP can be viewed as a
"request-response" type of model.
[0005] Today web services are not standardized such that they may
interact with requests from a plurality of protocols or design
architectures. For example, SOAP represents one type of web service
prevalent today and RESTful represents a different type of web
service. It is also clear that both SOAP and REST based web
services are going to coexist in the world for the foreseeable
future. Given this existing lack of standardization, existing web
services may be exposed only for web applications interacting in a
different manner than may be desired by a web developer.
[0006] To overcome these and other limitations it is desirable to
provide a generic web services server (e.g., man in the middle
adaptor) to allow more flexibility to web application
programmers.
SUMMARY
[0007] Disclosed are methods and systems to allow a web application
requesting information based on a particular type of web services
interface (e.g., SOAP or RESTful) to have that request
adapted/converted into another type of web services request and
sent to a corresponding already exposed interface. For example, a
web application desiring to communicate with an existing SOAP web
service via a RESTful interface could have its request converted
automatically from RESTful to SOAP and delivered to the existing
SOAP interface. This adaption or conversion may also be applied for
an existing SOAP web services interface such that a SOAP client may
communicate, indirectly, with an exposed RESTful interface. Thus,
existing web services may be more easily consumed without having to
(re)design and expose an interface for each type desired by client
web applications. Also, responses from the exiting web service may
be converted back to the paradigm expected by the web application
client before being returned.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] FIG. 1 shows, in block diagram form, an exemplary client
communicatively coupled to a web application server, a generic web
services adaptor, and a web service provided by an endpoint.
[0009] FIGS. 2A-B show an example web services request/response for
a RESTful web service and SOAP-based web service.
[0010] FIG. 3 shows, in flowchart form, an embodiment of converting
a SOAP web service request into a RESTful web service request.
[0011] FIG. 4 shows, in flowchart form, an embodiment of converting
a RESTful web service request into a SOAP web service request.
[0012] FIG. 5 shows, in block diagram form, a simplified computer
network comprising a generic adaptor architecture configured to
perform conversion of web services requests from one interface type
to another.
[0013] FIG. 6 shows, in block diagram form, an embodiment of a
computer network comprising a generic adaptor which in turn
comprises a plurality of adaptors for converting web services
requests from one interface type to another
[0014] FIG. 7 shows, in block diagram form, an exemplary computing
device comprising a program control device.
DETAILED DESCRIPTION
[0015] Methods and systems to automatically convert from one web
services implementation type to another web services implementation
type are disclosed. In order for a client and a server to properly
work together there must be a consistent interface between the two.
That is not to say that both applications executing in one or more
computers must have the same interface type for communication.
However, if a client and a server are not communicating via the
same interface, an adaption interface must be provided. In
particular, if a client computer is configured to send/receive a
particular interface type (e.g., SOAP/REST) and a server computer
is configured to answer requests from a different interface type,
then some adaption or conversion must be performed before the
client can properly communicate with the server. Disclosed is a
method and system to expose and convert an existing web service,
provided by an endpoint, to a different interface type and make the
new interface available from a computer executing a generic web
services adaptor.
[0016] Disclosed are embodiments of a generic adaptor for web
services. As discussed above, prior art implementations require a
developer of a web application to code the web application for a
specific type of exposed web services interface. By implementing a
generic web services adaptor, web application developers and others
may code an application to any implementation supported by the
generic adaptor without regard to the actual implementation of the
existing exposed interface of a web service.
[0017] As a result of the ability to perform conversion, the
adaptor may provide a plurality of interfaces for clients (e.g.,
web applications) configured to send/receive in either the original
interface or the newly supplied and exposed interface of a
different type. The embodiments disclosed herein are confined to
SOAP and REST web services. However, those of ordinary skill in the
art will recognize that the concepts disclosed herein may also be
applicable to other web services interface implementation types
(e.g., eXtensible Markup Language--Remote Procedure Call (XML-RPC),
JavaScript Object Notation (JSON), Hypertext Transfer Protocol
(HTTP), etc.).
[0018] Referring now to FIG. 1, a high level block diagram of an
interconnected computer system 100 is shown. Client computer 110
represents a computer which executes a web browser and may connect
(via a Universal Resource Locator (URL)) to web application server
130. In this example, web application server 130 is a consumer of
web services provided by a web services provider (endpoint) 140.
Communication between client computer 110, web application server
130, and endpoint 140 takes place across network 120. A request
across network 120 for a web service from endpoint 140 will
typically be an encapsulated "message." The message may allow for
sending/receiving one or more pieces of information. This
encapsulation may be accomplished in many ways, including a SOAP
style request or a RESTful style request, among others. In other
words, typical requests across a network are bundles of information
such that multiple interactions (for a discrete piece of
information) between a web application executing on web application
server 130 and endpoint 140 may be minimized.
[0019] Network 120 represents a communication coupling between
computers (e.g., 110, 130, 135 and 140). Network 120 may be either
wired or wireless or a combination thereof. Examples of network 120
include, but are not limited to, a LAN, WAN, Internet, Intranet and
the like. Note the segregation of functions described is logical
and not physical. Therefore, it is possible for any combination of
a client application, a web application, a generic web services
adaptor, and a web services provider (endpoint) to coexist on the
same physical computer without actually sending data across a
network such as network 120. Further, the designation of client
versus server may exist between many levels of this logical
segregation. Therefore, client generally refers to a requesting
application/computer and server generally refers to an
application/computer servicing the request. Also, a client
application and corresponding server application may actually
execute on the same or different physical computers.
[0020] If web application server 130 desires a SOAP interface to a
web service on endpoint 140 and endpoint 140 already has an exposed
SOAP interface, then server 130 can communicate directly with
endpoint 140. However, if web application server 130 desires a
RESTful interface to this same exposed SOAP interface then, as
explained above, it cannot communicate directly. In one disclosed
embodiment, this situation may be overcome by having web
application server send its RESTful request to generic web services
adaptor server 135. Generic web service adaptor 135 can then
translate or adapt the request from a RESTful request to a SOAP
style request and forward the request to the already exposed SOAP
interface on endpoint 140. After processing the SOAP style request,
endpoint 140 will respond to server 135 and server 135 may
translate the response to a format expected by original requesting
computer 130. In this embodiment, neither computer 130 nor endpoint
computer 140 must be made aware of, or be concerned with, the type
of interface they are servicing or consuming.
[0021] To aid in the understanding of this disclosure the following
definitions are provided:
[0022] WSDL: Web Services Definition Language (WSDL) is, in
general, an XML format for describing network services as a set of
endpoints operating on messages containing either document-oriented
or procedure-oriented information. The operations and messages are
described abstractly, and then bound to a concrete network protocol
and message format to define an endpoint. Related concrete
endpoints are combined into abstract endpoints (services). WSDL is
extensible to allow the description of endpoints and their messages
regardless of what message formats or network protocols are used to
communicate. WSDL is typically used to define and describe the
interfaces of SOAP-based web services.
[0023] WADL: Web Application Description Language (WADL) is
described in a specification promulgated by the World Wide Web
Consortium (W3C). WADL is designed to provide a machine
process-able description of such HTTP-based Web applications. An
increasing number of Web-based enterprises (e.g., Google.RTM.,
Yahoo.RTM., Amazon.RTM., and Flickr.RTM.) are developing HTTP-based
applications that provide programmatic access to their internal
data. (GOOGLE is a registered trademark of Google Inc., Mountain
View Calif. YAHOO and FLICKR are registered trademarks of Yahoo!
Inc., Sunnyvale Calif. AMAZON is a registered trademark of
Amazon.com Inc., Seattle Wash.) Typically these applications are
described using textual documentation that is sometimes
supplemented with more formal specifications such as XML schema for
XML-based data formats. WADL may be used to define and describe the
interfaces of RESTful web services.
[0024] XML: eXtensible Markup Language is a set of rules for
encoding documents electronically. It is defined in the XML 1.0
Specification produced by the W3C and several other related
specifications; all are fee-free open standards. XML's design goals
emphasize simplicity, generality, and usability over the Internet.
It is a textual data format, with strong support via Unicode for
the languages of the world. Although XML's design focuses on
documents, it is widely used for the representation of arbitrary
data structures, for example in web services. Each of the standards
for WSDL, SOAP and WADL described herein are expressed in XML.
[0025] XSLT: eXtensible Stylesheet Language (XSL) Transformation is
a declarative, XML-based language used for the transformation of
XML documents into other XML documents. The original document is
not changed; rather, a new document is created based on the content
of an existing one. The new document may be serialized (output) by
the processor in standard XML syntax or in another format, such as
HTML or plain text. XSLT is often used to convert XML data into
HTML or XHTML documents for display as a web page: the
transformation may happen dynamically either on the client or on
the server, or it may be done as part of the publishing process.
XSLT is also used to translate XML messages between different XML
schemas, or to make changes to documents within the scope of a
single schema, for example by removing the parts of a message that
are not needed.
[0026] Web Application: a web application (webapp) is an
application that is typically accessed via a web browser over a
network such as the Internet or an intranet. The term may also
refer to a computer software application that is hosted in a
browser-controlled environment (e.g., a Java applet) or coded in a
browser-supported language (such as JavaScript) and reliant on a
common web browser to render the application executable. Web
Applications are usually segregated into logical layers called
"tiers," where every tier is assigned a role. For the examples of
this disclosure, it is assumed a webapp is divided into a client
side tier (presentation) communicating directly with a web browser
and a server side tier, providing the functionality (business
logic) of the application, communicating with web services.
However, one of ordinary skill in the art will recognize that a
webapp may be implemented as a many-tier architecture.
[0027] Referring now to FIGS. 2A-B, an example web service
request/response for each of REST and SOAP are shown. This example
web service operation would get the stock price for a particular
stock symbol. As those of ordinary skill in the art will recognize,
REST is actually the architecture underlying the Web. Therefore,
when comparing REST with SOAP (which is really a protocol, not an
architecture) we classify the RESTful web services based on
different idioms. RESTful web services are invocations of
functionality across the Web that comply with REST architecture. In
contrast, SOAP invocations are done by communicating the function
semantics and syntax (i.e., the operation and parameter names) with
an endpoint. To make a REST request a user navigates to a resource.
This navigation is usually accomplished by an HTTP operation,
typically (although not exclusively) a GET. This is a significant
distinction between REST and SOAP.
[0028] Returning now to FIG. 2A, a RESTful request is simply a URL
as shown in element 210. The corresponding RESTful response in XML
is shown in element 220. FIG. 2B shows the corresponding SOAP-based
response and request. Element 250 shows the request is an XML based
SOAP envelop and element 260 shows an example response that may be
provided by a SOAP-based web service. Note the syntax and URLs used
here are for illustration purposes only.
[0029] Explained next are sample embodiments of a conversion
process. First, an example conversion of a SOAP interface to a
RESTful interface is described. Second, an example of classifying a
RESTful web service and converting the classified RESTful web
service to a SOAP interface is described. Further details of this
classification and conversion methodology can be found in U.S.
patent application Ser. No. 12/650,107 entitled "A Method and
System to Automatically Adapt Web Services from one Protocol/Idiom
to Another Protocol/Idiom" by Vincent Kowalski.
[0030] Referring now to FIG. 3, an example process 300 for
converting from a SOAP interface style to a RESTful interface style
is shown. Process 300 begins at block 310, which depicts an
existing SOAP interface and its corresponding WSDL description.
WSDL is implemented in XML. Therefore, an XSLT transformation may
be applied (block 320) to produce a WADL description of the
interface (block 330). Utilizing the created WADL a new RESTful web
services interface may be generated (block 340). Finally, the new
RESTful web service interface may be made available (exposed) on a
web server at block 350.
[0031] Referring now to FIG. 4, an example process 400 for
converting from a RESTful interface tyle to a SOAP-based interface
style is shown. Process 400 begins at block 410 with an existing
RESTful Web Service. Classification of the exposed interface is
performed at block 420. If the exposed interface is unclassifiable,
the NO prong of 430, a hand-coded WADL may need to be created as
represented by block 450. If the classification is possible, the
YES prong of 430, then an auto-translated WADL may be created at
block 440. In either case the WADL is processed by applying an XSLT
transformation (block 460) to produce a WSDL description at block
470. Finally, at block 480, a SOAP-based Web Service interface may
be made available on the web server.
[0032] Referring now to FIG. 5, sample architecture 500 comprises a
web services endpoint 510 providing a web service for "stock
quotes," web services client 530 configured to make SOAP requests,
web services client 520 configured to make RESTful requests and
generic web services adaptor 540. In this example, Stock Quote
Service Provider (Endpoint) 510 originally provided a SOAP
interface and cannot service requests from RESTful clients such as
client 520. Client 530 may make SOAP requests and receive SOAP
responses via direct communication with endpoint 510 as shown by
element 535. However, for the reasons discussed above,
request/response messages 525 from client 520 require conversion
before client 520 may take advantage of the Stock Quote Service
from endpoint 510. Therefore, in this example, conversion is
performed by generic web services adaptor 540 exposing a RESTful
interface 560 and executing adaptor function 565. In this example,
client 520 requests (525) a stock quote from RESTful interface 560.
RESTful interface 560 (and generic web services adaptor) is not
required to provide the business logic supporting a stock quote
service. RESTful interface 560 receives the request and passes the
request to adaptor function 565. After converting the request into
a style acceptable by endpoint 510, the request is forwarded (570)
to endpoint 510 where all business logic that implements the stock
quote service may be performed. The business logic of endpoint 510
is executed as if the request originated from a SOAP based client.
Upon completion of the business logic, endpoint 510 responds (570)
with a SOAP response to generic web services adaptor 540.
Conversion of this SOAP response may then be performed by adaptor
565 resulting in a RESTful response (525) as required and expected
by original requesting client 520. In this manner, client 520 may
utilize a web service provided by endpoint 510 without an update to
either implementation because of generic web services adaptor
540.
[0033] Building upon the example of FIG. 5 and referring now to
FIG. 6, sample architecture 600 comprises a plurality of endpoint
web service providers 610 and 611, another embodiment of web
services generic adaptor 640, and a plurality of web services
clients such as 620 and 630. In this embodiment, generic web
services adaptor 640 comprises a RESTful interface 660 and adaptor
662 configured to convert RESTful based requests into SOAP based
requests. Generic web services adaptor 640 also comprises a SOAP
interface 665 and adaptor 667 configured to convert SOAP based
requests into RESTful based requests. RESTful requests arrive at
generic web services adaptor computer as indicated by element 641
and SOAP requests arrive as indicated by element 651. Upon receipt,
RESTful requests (641) for a particular web service can be passed
(642) directly to web service endpoint 610 exposing a RESTful
interface or requests can be converted by adaptor 662 into SOAP
based requests and passed (643) to an endpoint 611 exposing a SOAP
interface. Additionally, upon receipt of SOAP based requests (651)
for a particular web service, requests can be passed (652) directly
to web service endpoint 611 exposing a SOAP interface or requests
can be converted by adaptor 667 into RESTful based requests and
passed (653) to an endpoint 610 exposing a RESTful interface. Thus,
in this embodiment all requests from clients are directed to
generic web services adaptor 640 and web application developers may
be provided with greater flexibility because they are not required
to concern themselves with the actual type of web service interface
exposed by a supported web service provider endpoint.
[0034] Note architecture 600 is shown with only two web services
clients and two web service provider endpoints for simplicity. Any
number of web services clients or endpoint service providers may be
supported on any number of computers. Also, it is possible for a
single computer to process activity associated with any combination
of activities reflected in elements 610, 611, 620, 630 and 640.
That is, a single computer can be concurrently configured to
request web services via a SOAP interface and a RESTful web service
(likely different web services provided by distinct service
provider endpoints).
[0035] Based on the disclosed embodiments, generic web services
adaptor may provide even further flexibility for web application
developers. For example, generic web services adaptor may be
configured to provide either complete or partial business logic for
web service provider endpoints that have been decommissioned. Also,
generic web services adaptor may be configured to redirect either
full or partial requests for a web service to a web service
provider other than that originally requested. This may be done to
either support a request more efficiently or to satisfy the request
in a manner other than sending it to the originally requested web
service provider. Of course, security and data integrity may need
to be taken into account for all disclosed embodiments. Methods of
implementing certain security controls are known in the art and are
not directly discussed here.
[0036] Referring now to FIG. 7, an exemplary computing device 700
is shown. One or more exemplary computing devices 700 may be
included in a mainframe computer (not shown) or a standard
distributed computer. Exemplary computing device 700 comprises a
programmable control device 710 which may be optionally connected
to input 760 (e.g., keyboard, mouse, touch screen, etc.), display
770 or program storage device (PSD) 780 (sometimes referred to as a
direct access storage device DASD). Also, included with program
device 710 is a network interface 740 for communication via a
network with other computing and corporate infrastructure devices
(not shown). Note network interface 740 may be included within
programmable control device 710 or be external to programmable
control device 710. In either case, programmable control device 710
will be communicatively coupled to network interface 740. Also
note, program storage unit 780 represents any form of non-volatile
storage including, but not limited to, all forms of optical and
magnetic storage elements including solid-state storage.
[0037] Program control device 710 may be included in a computing
device and be programmed to perform methods in accordance with this
disclosure (e.g., those illustrated in FIGS. 5 and 3). Program
control device 710 comprises a processor unit (PU) 720,
input-output (I/O) interface 750 and memory 730. Processing unit
720 may include any programmable controller device including, for
example, processors of an IBM mainframe (such as a quad-core z10
mainframe microprocessor). Alternatively, in non-mainframe systems
examples of processing unit 720 include the Intel Core.RTM.,
Pentium.RTM. and Celeron.RTM. processor families from Intel and the
Cortex and ARM processor families from ARM. (INTEL CORE, PENTIUM
and CELERON are registered trademarks of the Intel Corporation.
CORTEX is a registered trademark of the ARM Limited Corporation.
ARM is a registered trademark of the ARM Limited Company.) Memory
730 may include one or more memory modules and comprise random
access memory (RAM), read only memory (ROM), programmable read only
memory (PROM), programmable read-write memory, and solid state
memory. One of ordinary skill in the art will also recognize that
PU 720 may also include some internal memory including, for
example, cache memory.
[0038] Aspects of the embodiments are described as a method of
control or manipulation of data, and may be implemented in one or a
combination of hardware, firmware, and software. Embodiments may
also be implemented as instructions stored on a machine-readable
medium, which may be read and executed by at least one processor to
perform the operations described herein. A machine-readable medium
may include any mechanism for tangibly embodying information in a
form readable by a machine (e.g., a computer). For example, a
machine-readable medium (sometimes referred to as a program storage
device or a computer readable medium) may include read-only memory
(ROM), random-access memory (RAM), magnetic disc storage media,
optical storage media, flash-memory devices, electrical, optical,
and others.
[0039] In the above detailed description, various features are
occasionally grouped together in a single embodiment for the
purpose of streamlining the disclosure. This method of disclosure
is not to be interpreted as reflecting an intention that the
claimed embodiments of the subject matter require more features
than are expressly recited in each claim.
[0040] Various changes in the details of the illustrated
operational methods are possible without departing from the scope
of the following claims. For instance, illustrative flow chart
steps or process steps of FIGS. 3 and 4 may be performed in an
order different from that disclosed here. Alternatively, some
embodiments may combine the activities described herein as being
separate steps or combine the logical systems described herein as
being separate computers into one physical computer. Similarly, one
or more of the described steps may be omitted, depending upon the
specific operational environment the method is being implemented
in. In addition, acts in accordance with FIGS. 3 and 4 may be
performed by a programmable control device executing instructions
organized into one or more program modules. A programmable control
device may be a single computer processor, a special purpose
processor (e.g., a digital signal processor, "DSP"), a plurality of
processors coupled by a communications link or a custom designed
state machine. Custom designed state machines may be embodied in a
hardware device such as an integrated circuit including, but not
limited to, application specific integrated circuits ("ASICs") or
field programmable gate array ("FPGAs"). Storage devices, sometimes
called computer readable medium, suitable for tangibly embodying
program instructions include, but are not limited to: magnetic
disks (fixed, floppy, and removable) and tape; optical media such
as CD-ROMs and digital video disks ("DVDs"); and semiconductor
memory devices such as Electrically Programmable Read-Only Memory
("EPROM"), Electrically Erasable Programmable Read-Only Memory
("EEPROM"), Programmable Gate Arrays and flash devices.
[0041] It is to be understood that the above description is
intended to be illustrative, and not restrictive. For example, the
above-described embodiments may be used in combination with each
other. Many other embodiments will be apparent to those of skill in
the art upon reviewing the above description. The scope of the
invention should, therefore, be determined with reference to the
appended claims, along with the full scope of equivalents to which
such claims are entitled. In the appended claims, the terms
"including" and "in which" are used as the plain-English
equivalents of the respective terms "comprising" and "wherein."
* * * * *