Patent Application
20180077203
The present invention relates to service oriented architecture (SOA) and information technology (IT) management. More particularly, the present invention relates to inter-domain replication of service information.
Information technology (IT) systems are utilized to manage information within corporations and to manage information for clients of corporations. Service oriented architecture (SOA) may be used to build IT systems. With an SOA architected IT system, certain devices provide services and certain devices consume services of devices that provide services.
A method includes performing an automated conversion of service information comprising endpoint addresses of service providers between first and second independent enterprise information technology (IT) management domains using a federated gateway within each of the first and second independent enterprise IT management domains that bridges the first and second independent enterprise IT management domains; and dynamically performing, in response to at least one service request from the first independent enterprise IT management domain for at least one remote service provider application in the second independent enterprise IT management domain, service provider application endpoint translation using the federated gateway within each of the first and second independent enterprise IT management domains.
A system includes a memory; and a processor programmed to: perform, using the memory, an automated conversion of service information comprising endpoint addresses of service providers between the first and second independent enterprise IT management domains using the federated gateway within each of the first and second independent enterprise IT management domains that bridges the first and second independent enterprise IT management domains; and dynamically perform, in response to at least one service request from the first independent enterprise IT management domain for at least one remote service provider application in the second independent enterprise IT management domain, service provider application endpoint translation using the federated gateway within each of the first and second independent enterprise IT management domains.
A computer program product includes a computer readable storage medium including computer readable program code, where the computer readable program code when executed on a computer causes the computer to: perform an automated conversion of service information comprising endpoint addresses of service providers between first and second independent enterprise information technology (IT) management domains using a federated gateway within each of the first and second independent enterprise IT management domains that bridges the first and second independent enterprise IT management domains; and dynamically perform, in response to at least one service request from the first independent enterprise IT management domain for at least one remote service provider application in the second independent enterprise IT management domain, service provider application endpoint translation using the federated gateway within each of the first and second independent enterprise IT management domains.
The examples set forth below represent the necessary information to enable those skilled in the art to practice the invention and illustrate the best mode of practicing the invention. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the invention and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure and the accompanying claims.
The subject matter described herein provides automated inter-domain replication of service information. A federated gateway within each of multiple independent IT management domains bridges the independent IT management domains. As such, the independent IT management domains are in direct peer interaction. Service information of remote service providers, such as endpoint addresses of remote service providers and security policies, within remote independent IT management domains is automatically converted for use by service consumers in local independent IT management domains. The automated conversion of service information allows service consumer applications executing within one independent IT management domain to use local service definition formats appropriate for use within the local domain to access remote service provider applications with remote service interfaces defined using different remote service definition formats for execution in other independent IT management domains. As such, inter-domain integration of services is managed in an automated manner to allow remote service provider applications to be directly accessed without changing native protocols and security policies within independent service consumer IT management domains.
It should be noted that conception of the present subject matter resulted from recognition of certain limitations associated with service oriented architecture (SOA) and information technology (IT) management. For example, it was observed that many information technology regions/domains (hereinafter “regions” and “region,” or “domains” and “domain,” interchangeably) exist around the world, such as multiple enterprise IT environments, and that each geographic or logical region has its own specific IT management or development process/processes with its own policy implementations that are driven by requirements of local business. It was further observed that system and security management for each region is independent (e.g., silo model) of one another. It was additionally observed that each region generally has its own technical standards, which require batch file transfer or database (DB) replication as the only way to integrate systems among regions. Additionally, it was observed that service information management across domains is carried out manually, and that for service information that is to be shared across domains, manually copying of service information is conventionally performed.
In view of these observations, it was determined that if service information, which is important for ensuring the accuracy of dynamic routing, is managed manually, a problem exists in that the manual management may result in inaccuracy in conversion, and, therefore, management becomes more complex. It was consequently determined that next generation architecture (NGA), as described herein and referred to as automated inter-domain replication of service information, may make IT management systems flexible and agile for business changes and may improve IT management. SOA may be improved using the technology described herein by building an IT system with endpoint address translation components resident within independent IT management domains that may respond to a change in a business environment flexibly and quickly and promote the reuse of services. It was determined that it is valuable for speed and reliability of business decisions to realize the essence of SOA by integrating various domains within an enterprise environment (e.g., local offices of a global enterprise, suppliers, partners, etc.). For that purpose, it is was determined that it is desirable to realize total optimization by integrating global domains with respect to each domain's IT management and development processes that have already been structured/optimized individually (in such a way as not to impair the individual IT management and the individual development processes).
It was additionally determined that when applications are integrated across domains, the number of integrations will significantly increase if each application tries to communicate one by one in an uncontrolled manner. In addition, in such a case, it was determined that it is desirable for each application to implement the service integration individually.
It was additionally determined that the management of service information may be performed in a gateway pattern that is reflected in a service registration and repository (SRR) that may be used to ensure the accuracy of inter-domain dynamic routing. It was additionally determined that a mere copy of service registration information may not be sufficient for service information that is shared among the domains and that it is desirable to convert appropriate information depending on the circumstances for replication. With respect to service replication according to the present subject matter, in order to implement a domain-to-domain (inter-domain) service integration (e.g., service coordination between domains) accurately, the conversion is carried out automatically using endpoint address conversion instead of merely copying in service information management between SRRs deployed in different domains.
It was further determined that an ability to integrate global systems seamlessly by reusing global services would improve IT management. It was additionally determined that several business motivations may be improved by implementation and use of the automated inter-domain replication of service information systems described herein, such as for example, cost reductions, faster adaptation to market expansion, increased efficiency (e.g., real-time business data), and improved company image (e.g., a unified single entity). It was further determined that because each local operation base is completely independent of the others, each local operation base is placed on an equal footing with other remote operation bases. It was further noted that, because each region-directed operation represents an important corporate culture, top-down enforced global common optimization is not desirable. It was also determined that each region should maintain its own IT management and development process that best suits its requirements, and the present subject matter avoids adoption of common standards that would slow down each region's business.
Several technical challenges associated with the present subject matter were also determined and solved. For example, it was determined that if each application tries to communicate one by one to integrate regions, each application has to determine whether the service with which it is trying to integrate is in the same region or in another region. Additionally, it was determined that the number of links increases exponentially due to the occurrence of N*(N−1) mapping. Further, it was determined that routing as well as safety assurance may be used for each link.
The present subject matter improves geographically distributed IT management inter-domain interoperability by providing automated inter-domain replication of service information. The automated inter-domain replication of service information described herein builds a new platform that integrates regions all over the world. The present subject matter establishes an integrated link for exchanging information on a global level. An example of such an integrated link is an enterprise service bus (ESB) that functions as an inter-IT management domain gateway that is deployed in each domain. An inlet/outlet (entrance/exit) for establishing a link is limited to a single point in each domain. Integration between domains is established through the ESBs (also referred to as a federated ESB).
Using the present subject matter, each application does not have to be concerned with whether the service it is trying to integrate is in the same region or in another region (each application always connects to the federated ESB/gateway deployed within its region). As such, each domain is encapsulated to hide its inner components. Using the present subject matter, it is only the linkage component (e.g., the federated ESB/gateway) encapsulated within and operable between domains that is standardized and each region otherwise maintains autonomy. At each domain, any gap (difference) between the overall standard and the specification unique to the region may be bridged by conversion. Management responsibility apportioned to each region is defined within the respective regions.
Integration and reuse of applications/services between geographically or logically distributed local operational bases are implemented and provided with real-time IT management system integration, in addition to the batch file transfer and DB replication. The present subject matter integrates global information while implementing several security measures. For example, in a global enterprise, each region's system is independent even within a single company. Independence from the viewpoint of security is provided even in an intra-network connection. Utilizing the present subject matter, independent systems may be integrated with safety and security.
The present subject matter establishes a global standard of inter-domain service information management, while allowing each region to maintain significant independence. Each region's responsibility of the inter-domain service information management may be defined within each region/domain and separated.
The examples described below illustrate several principles of operation of the technology described herein. For example, the following examples describe, among other things, technology and processing for seamless integration of applications/services, service management for reuse, and security of information integration (authentication and authorization across domains). Asset registration may be performed using appropriate technology for the given implementation, such as intelligent random access memory (iRAM).
The present technology provides a gateway that is built within each domain. Service integration across domains (inter-domain) is established via the individual gateway. A call type (e.g., Request/Response call type) is provided for integration across domains. Conversion processing for inter-domain functionality may be performed at the gateway.
A common and unified security policy is used for inter-domain service integration, such as Security Assertion Markup Language (SAML). Dynamic routing is implemented. In order to call up a target service in a different domain via the gateway (e.g., inter-domain hopping) among various services provided in each domain, using dynamic routing, information on the target service is acquired dynamically and routed for indication of the specific service, the specific place/location where the service should be called up, the specific type of the service, etc. In order to perform dynamic inter-domain routing accurately, the present technology manages specific service information (e.g., an endpoint address where a service is available) within a service registry and repository (SRR), and returns that information to the gateway in reply to an inquiry received from the gateway.
When a single service is called up across domains using inter-domain calling, in many cases it may differ from one domain to another depending on the standardized items of domain-to-domain integration, despite the fact that the “correct” information of service managed in each domain pertains to the same service. For example, assuming that the standardized items mentioned above are adopted, the present technology manages the differences corresponding to each of them.
The “correct” endpoint managed in the SRR of a service consumer domain (a domain in which a service is called) is the gateway endpoint of a domain from which the service is provided (service provider domain), whereas the “correct” endpoint managed in the SRR of the service provider domain is the endpoint of the service provider itself. When a service interaction type that is different from a standard domain-to-domain call is used in an actual service, (e.g., a One-way type), the “correct” call-up service definition managed in the SRR of the service consumer domain is standard definition (e.g., a Request/Response type), whereas the “correct” call-up service definition managed in the SRR of the service provider domain is that of an actual service (e.g., the One-way type). When a security policy that is different from a standard domain-to-domain policy is used in an actual service, (e.g., username token), the “correct” security policy managed in the SRR of the service consumer domain is a standard policy (e.g., SAML), whereas the “correct” security policy managed in the SRR of the service provider domain is that of an actual service (e.g., username token).
In order to manage the above differences to implement inter-domain dynamic routing, the present subject matter provides for automated inter-domain replication of service information in which information used within the respective domains for consumption of services in other domains is converted in a programmatic and automated manner into a form required in the service consumer domain for the respective domain in contrast to merely copying when service information is shared among domains as with conventional technology. The automated inter-domain replication of service information described herein performs conversion as follows: an endpoint is replaced by another endpoint so that a service will be called up by way of a gateway; a service definition is re-written for protocol conversion; and, a piece of security policy information that is to be used for originating a call is replaced by another piece of security policy information. In such a way, the present technology effectively maps between domains at each level of inter-domain integration in an automated manner.
As described above and in more detail below, the present subject provides a solution for achieving both local optimization and total optimization of service information management. The present technology provides for automatically managing correct service information, which is useable for making it possible to establish a flexible and agile system link while placing a high value on the uniqueness of each domain. Specifically, with a focus on service information that is to be shared between domains, for which a mere copy is not acceptable, the present technology for replication by converting the service information based upon the situation instead of merely copying represents a solution that overcomes obstacles of previously existing systems. Further, the present technology provides a solution to the problem of manual management for integration according to previous systems, and offers improved integration across domains in terms of correctness, flexibility, and agility.
The automated inter-domain replication of service information described herein may be performed in real time to allow prompt interoperability between geographically and/or logically distributed IT management domains. For purposes of the present description, real time shall include any time frame of sufficiently short duration as to provide reasonable response time for information processing acceptable to a user of the subject matter described. Additionally, the term “real time” shall include what is commonly termed “near real time”-generally meaning any time frame of sufficiently short duration as to provide reasonable response time for on-demand information processing acceptable to a user of the subject matter described (e.g., within a portion of a second or within a few seconds). These terms, while difficult to precisely define are well understood by those skilled in the art.
As will be described in more detail below in association with
As such, for any of the examples below, it is understood that any aspect of functionality described with respect to any one device that is described in conjunction with another device (e.g., sends/sending, requests/requesting, etc.) is to be understood to concurrently describe the functionality of the other respective device (e.g., receives/receiving, responds/responding, etc.).
A central processing unit (CPU) 202 provides computer instruction execution, computation, and other capabilities within the core processing module 200. A display 204 provides visual information to a user of the core processing module 200 and an input device 206 provides input capabilities for the user.
The display 204 may include any display device, such as a cathode ray tube (CRT), liquid crystal display (LCD), light emitting diode (LED), electronic ink displays, projection, touchscreen, or other display element or panel. The input device 206 may include a computer keyboard, a keypad, a mouse, a pen, a joystick, or any other type of input device by which the user may interact with and respond to information on the display 204.
It should be noted that the display 204 and the input device 206 may be optional components for the core processing module 200 for certain implementations. Accordingly, the core processing module 200 may operate as a completely automated embedded device without direct user configurability or feedback. However, the core processing module 200 may also provide user feedback and configurability via the display 204 and the input device 206, respectively.
A communication module 208 provides interconnection capabilities that allow the core processing module 200 to communicate with other modules within the system 100. A federated enterprise service bus (ESB) 210 is also provided for certain communications, as described within the examples below.
The communication module 208 and the federated ESB 210 may include any electrical, protocol, and protocol conversion capabilities useable to provide the interconnection capabilities. Though the respective communication modules are illustrated as component-level modules for ease of illustration and description purposes, it should be noted that the respective communication modules may include any hardware, programmed processor(s), and memory used to carry out the functions of the communication modules as described above and in more detail below. For example, the communication modules may include additional controller circuitry in the form of application specific integrated circuits (ASICs), processors, antennas, and/or discrete integrated circuits and components for performing communication and electrical control activities associated with the communication modules. Additionally, the communication modules may include interrupt-level, stack-level, and application-level modules as appropriate. Furthermore, the communication modules may include any memory components used for storage, execution, and data processing for performing processing activities associated with the communication modules. The communication modules may also form a portion of other circuitry described without departure from the scope of the present subject matter.
A memory 212 includes an application area 214 that stores and allows execution of applications, such as service consumer applications and service provider applications, as described above and in more detail below. The memory 212 also includes a data storage area 216 that stores data for intermediate and/or long-term storage objectives.
It is understood that the memory 212 may include any combination of volatile and non-volatile memory suitable for the intended purpose, distributed or localized as appropriate, and may include other memory segments not illustrated within the present example for ease of illustration purposes. For example, the memory 212 may include a code storage area, an operating system storage area, a code execution area, and a data area without departure from the scope of the present subject matter.
A federated service registry module 218, a federated security module 220, and an inter-domain service information replication module 222 are also illustrated. The federated service registry module 218, the federated security module 220, and the inter-domain service information replication module 222 provide respectively for service federation, security federation, and automated inter-domain replication of service information processing between encapsulated and independent IT management domains within the core processing module 200, as described above and in more detail below. The inter-domain service information replication module 222, in conjunction with the federated ESB 210, the federated service registry module 218, and the federated security module 220, implements the automated inter-domain replication of service information of the core processing module 200.
Though the federated service registry module 218, the federated security module 220, and the inter-domain service information replication module 222 are illustrated as component-level modules for ease of illustration and description purposes, it should be noted that these modules may include any hardware, programmed processor(s), and memory used to carry out the functions of these module as described above and in more detail below. For example, these modules may include additional controller circuitry in the form of application specific integrated circuits (ASICs), processors, and/or discrete integrated circuits and components for performing communication and electrical control activities associated with the respective devices. Additionally, these modules may include interrupt-level, stack-level, and application-level modules as appropriate. Furthermore, these modules may include any memory components used for storage, execution, and data processing for performing processing activities associated with the modules.
It should also be noted that the federated service registry module 218, the federated security module 220, and the inter-domain service information replication module 222 may form a portion of other circuitry described without departure from the scope of the present subject matter. Further, the federated service registry module 218, the federated security module 220, and the inter-domain service information replication module 222 may alternatively be implemented as one or more applications stored within the memory 212. In such an implementation, the respective module(s) may include instructions executed by the CPU 202 for performing the functionality described herein. The CPU 202 may execute these instructions to provide the processing capabilities described above and in more detail below for the core processing module 200. The respective module(s) may form a portion of an interrupt service routine (ISR), a portion of an operating system, a portion of a browser application, or a portion of a separate application without departure from the scope of the present subject matter.
It should be noted that certain registries described below may be implemented separately from the core processing module 200 and operably interconnected, or may be incorporated into the core processing module 200 without departure from the scope of the present subject matter. Accordingly, all such variations on architecture are considered within the scope of the present subject matter.
The CPU 202, the display 204, the input device 206, the communication module 208, the federated ESB 210, the memory 212, the federated service registry module 218, the federated security module 220, and the inter-domain service information replication module 222 are interconnected via an interconnection 224. The interconnection 224 may include a system bus, a network, or any other interconnection capable of providing the respective components with suitable interconnection for the respective purpose.
While the core processing module 200 is illustrated with and has certain components described, other modules and components may be associated with the core processing module 200 without departure from the scope of the present subject matter. Additionally, it should be noted that, while the core processing module 200 is described as a single device for ease of illustration purposes, the components within the core processing module 200 may be co-located or distributed and interconnected via a network without departure from the scope of the present subject matter. For a distributed arrangement, the display 204 and the input device 206 may be located at a kiosk, or other location, while the CPU 202 and memory 212 may be located at a local or remote server. Many other possible arrangements for components of the core processing module 200 are possible and all are considered within the scope of the present subject matter. Accordingly, the core processing module 200 may take many forms and may be associated with many platforms.
The present example logical architecture may be mapped onto one or more devices, such as the core processing module 200 of
Spanning the Domain A 102 and the Domain B 104 is a logical federated enterprise service bus (ESB) gateway 302 that is implemented via one or more of the federated ESB 210 of
The logical federated ESB gateway 302, and in particular each federated ESB 210, implements an ESB 308 that each provide global connectivity mediation between the independent IT management Domain A 102 and the independent IT management Domain B 104. The logical federated ESB gateway 302, and in particular each federated ESB 210, also implements a security gateway 310 that provides proxy services between the independent IT management Domain A 102 and the independent IT management Domain B 104.
The security gateway 310 within each domain also provides proxy services between a local ESB 312 that coordinates application mediation and bridges routing between service consumers 314 and 316, and service providers 318 within the respective independent IT management domains. The service consumers 314 and 316, and service providers 318, represent the consumer applications and the service provider applications of the elements 110, 112, and 114, described in association with
The logical federated service registry gateway 304, and in particular each federated service registry module 218, implements a local runtime service registry 320. Routing information for integration is provided by the logical federated ESB gateway 302 to the service registry 320. The logical federated service registry gateway 304, and in particular each federated service registry module 218, also implements a governance service registry 322 that logically spans (e.g., bridges) service registration between the independent IT management Domain A 102 and the independent IT management domain B 104. Service promotion is performed by the governance service registry 322. As described above, services and service interfaces available within the respective domains may be automatically converted for use within the other domain(s). For purposes of the present description, this conversion may be considered promotion of the respective remote service for access via the local domain by registration of the respective converted service interface within the respective runtime service registry 320. The respective ESB 308 within each domain, and in particular the global connectivity mediation, may perform endpoint lookup and token type lookup within the respective runtime service registry 320. Accordingly, automated inter-domain replication of service information across and between independent IT management domains may be performed and services may be made available in formats and via protocols defined within the respective independent IT management domains.
The logical federated security gateway 306, and in particular each federated security module 220, implements a local access/identity manager module 324 that logically spans (e.g., bridges) security policy information between the independent IT management Domain A 102 and the independent IT management Domain B 104. Security management for integration is provided by the logical federated security gateway 306 by the access/identity manager module 324, such as authentication, authorization, and exchange of security tokens. The respective security gateway 310 within each domain, and in particular the respective proxies, may perform token validation and token exchange via the respective access/identity manager module 324.
As such, the respective independent IT management Domain A 102 and the independent IT management Domain B 104 may be configured for interoperability using the automated inter-domain replication of service information described herein. Service interfaces defined within a domain using particular interfaces and protocols may be automatically converted for consumption within other domains using the automated inter-domain replication of service information described herein.
Further, security management inside each domain is autonomous, and only the linkage component across the domains is standardized. Automatic conversion is executed on the gateway therebetween for integration, which provides federated security. An enterprise service bus (ESB), which functions as a gateway, is deployed in each domain. An inlet/outlet (entrance/exit) for establishing a link is limited to a single point. Integration between domains is established through the ESBs, which provides a federated ESB. A runtime service registry is deployed in each domain in order to store service information that is used for dynamic routing and to respond to an inquiry sent from the gateway. A global governance service registry is deployed in each domain. The global governance service registries share the service information with each other across domains, and each of them copies and converts (promotes) service information into the runtime service registry in each domain, which provides a federated service registry.
When a service consumer, such as one of the service consumers 314, (shown as “Application 314” in Domain A 102 of
The architectural interconnection (gateway) 300 makes an inquiry to the runtime service registry 320 operating within the logical federated service registry gateway 304 (not shown within
The service definition information that is to be used for the service call in conjunction with the request is transferred to the logical federated security gateway 306 (not shown in
When the logical federated security gateway 306 (not shown in
The service definition information that is to be used for the service call in conjunction with the request is transferred to the access/identity manager 324 operating within the logical federated security gateway 306 (not shown in
In order to provide the flow described above, service information managed at the respective runtime service registries 320 of each domain, is different. Service information managed at the runtime service registry 320 of the domain, such as the Domain A 102, in which a service is called up (service consumer domain) may be different from service information managed at the runtime service registry 320 of the domain, such as the Domain B 104, from which the service is provided (service provider domain). In the above example, differentiation is provided for each of the endpoint information that is used for the service call, the service definition information that is used for the service call, and the security policy information that is used for the service call. As such, identity federation, service promotion, and routing is performed between independent and encapsulated IT management domains utilizing the automated inter-domain replication of service information described herein.
A governance service registry 322 is deployed in each domain. The governance service registry 322 provides management responsibility and ensures that management responsibility is apportioned to each domain. Endpoint information is sent (promoted) from the governance service registry 322 to the runtime service registry 320 at the responsibility of each domain. Service information is exposed from one domain to others by sharing the information from the respective domain's governance service registry 322 with other domains. The runtime environment of a domain is not allowed to be accessed from any other domains. An inlet/outlet (entrance/exit) for integration is limited to provide independence and autonomy for the respective domains.
The service information exposed to other domains, the original endpoint (provider domain) value is changed to an appropriate value for the consuming domain. The original endpoint points to the service provider's address to call the service. However, the endpoint exposed to other domains points to the gateway address of the provider's domain because the gateway is the only entrance from other domains to the provider's domain. Changing the endpoint value automatically when the endpoint is exposed to other domains provides smooth integration among independent domain gateway patterns.
It should additionally be noted that the respective runtime service registries 320 may be implemented using WebSphere® service registry and repository (WSRR).
Even for the same service, information utilized in each domain may differ. The present subject matter provides technology to manage such different information correctly and methodically, to provide for replication among global governance service registries, and to convert service information into a form consumable by the requesting domain via automated replication instead of merely copying. For example, a service endpoint may be re-written so that a service will be called up within the consumer domain by way of a gateway using service definition formats and protocols of the consuming domain (rather than the native provider domain service definition formats and protocols), and conversion of service calls to the native provider definition formats and protocols is performed in an automated manner without requiring changes to the consumer domain for the particular service.
Several aspects for realizing automated replication are represented within the present description. Example aspects including definition of a standard for domain-to-domain integration, automated conversion methodology, and replication methodology represent several of the aspects solved by the present subject matter. These example aspects are expanded upon within the following paragraphs.
Regarding definition of a standard for domain-to-domain integration, automated replication may be realized as a result of converting information that is unique to each domain into a standard for domain-to-domain integration (link between domains) and sharing that converted information, wherein such unique information is defined by a service provider. For this purpose, it is appropriate to define a standard for domain-to-domain integration so that it may be referred to at the time of conversion. Items that are helpful for definition are, for example, an identifier (ID), a name of the particular standardization used (Name), a target object (Target) of standardization (e.g., web services description language (WSDL)), a particular operation (Operation) of the definition (e.g., replacement, addition, deletion, etc.), items (Item) of standardization (e.g., extensible markup language path language (XPATH®) in WSDL when WSDL is employed), and a standardization value (Value), among others.
The following items represented within Table 1 are defined in the above example.
Within Table 1 above, several value elements (Value column) are represented symbolically due to page size limitations (e.g., Value1, etc.). For purposes of the present examples, these value elements may include the following information values, in pseudo syntax format.
For the value Value0 (note that this is a stored value referenced within Table 1 above):
Value0=dddd.dddd.dddd.dddd
For the value Value1 (note that this is a stored value referenced within Table 1 above):
Value1=<namespace of the token profile>
For the value Value2 (note that this is a stored value referenced within Table 1 above):
For the value Value3 (note that this is a stored value referenced within Table 1 above):
For the value Value4 (note that this is a stored value referenced within Table 1 above):
For the value Value5 (note that this is a stored value referenced within Table 1 above):
Value5=<wsdl:output message=“tns:operationResponseMsg” name=“operationResponse”/>
Regarding automated conversion methodology, a copy of an object of an original service interface as a conversion target is created. The definition of a standard for domain-to-domain integration is then evaluated from the top. Applicable items in the target object are converted automatically within the designated conversion operation.
For example, in the above example, as a first step, a copy of WSDL managed in its own domain is created. Then, S001 is evaluated to replace the host name designated at /definitions/service/port/ address/location by the defined value. As a result of the above change, the location is converted from a location pointing to the actual service provider in the original service interface into a location pointing to the gateway inside its own domain.
As such, for S001, for purposes of the present example, it is assumed that the original location is:
<soap:address location=“http://aaa.aaa.aaa.aaa/bbb/ccc”/>
As can be seen from the pseudo syntax below, the value Value0 is used such that the conversion may be in a form as follows:
<soap:address location=“http://dddd.dddd.dddd.dddd/bbb/ccc”/>
S002 is thereafter evaluated to replace the type of a security policy designated at /definitions/Policy/SupportingTokens/Policy by the defined value. As a result of the above change, the type is converted from a security policy type used in its own domain in the original security policy type into a type standardized for domain-to-domain integration.
As such, for S002, for purposes of the present example, it is assumed that the original security policy type is:
As can be seen from the pseudo syntax below, the value Value1 is used such that the conversion may be in a form as follows:
S003 is then evaluated. If the defined item does not exist at each of /definitions/binding/operation, /definitions/types/schema, /definitions, and /definitions/portType/operation, the value is added. As a result of the above change, the operation is converted from an operation having service definition for One-way calling into an operation having service definition for Request/Response calling that is standardized for domain-to-domain integration.
As such, for S003, for purposes of the present example, it is assumed that the original service definition is:
As can be seen from the pseudo syntax below, the value Value2 is used such that the conversion may be in a form as follows:
Regarding replication methodology, service information that has been subjected to a change from the global governance service registry of the service provider domain into the global governance service registry of the service consumer domain (i.e., service information conforming to the standard for domain-to-domain integration) is copied when appropriate, thereby ending the process of automated replication. By this approach, it is possible to correctly and confidently manage different information required in each domain even for the same service.
Authentication among domains may be considered mandatory. It is not each user, but each domain that is authenticated on the integration (it may be considered a precondition that each user has been authenticated inside its domain before the integration). Only domain certifications are exchanged among domains. Each domain is authenticated by the security token signed with the certification.
Authorization among domains may be considered an application selectable feature. Each user's access may be controlled with role-based authorization. All user identifiers (IDs) are exchanged among domains. Service level authorization may be defined by any standard appropriate for a given implementation, such as WS-Trust and implemented by products. Service operation level authorization may also be utilized.
At block 806, the process 800 converts the service definition of the remote service provider to a standardized service definition format that is used for integration between the two independent IT management domains. At block 808, the process 800 converts a security policy of the remote service provider to a standardized security policy that is used for integration between the two independent IT management domains. At block 810, the process 800 promotes the converted service interface to the runtime service registry 320 of the logical federated service registry gateway 304 within the Domain A 102. The process 800 returns to decision point 802 to await identification of another remote service provider for integration.
At block 906, process 900 obtains a converted standardized service definition for the remote service provider. At block 908, the process 900 obtains a converted standardized security policy. At block 910, the process 900 transfers the service definition information to a logical federated security gateway 306, such as the security gateway 310 within the Domain A 102, for routing.
At block 912, in cooperation with the access/identity manager 324 operating within the logical federated security gateway 306, the process 900 converts the security policy for the service call to a format compatible with remote service provider. At block 914, the service call is routed to the service endpoint.
At decision point 916, the process 900 waits for a response to the service call to be received. As described above, for purposes of the present examples, it is assumed that the service consumers 314 within the Domain A 102 utilize a Request/Response protocol. In response to determining that a response to the service call has been received, the process 900 performs processing of the received response at block 918. The process 900 returns to decision point 902 and iterates as described above.
At block 1006, the process 1000 obtains a local service definition for the local service provider application. At block 1008, the process 1000 obtains a local security policy for the local service provider application. At block 1010, the process 1000 transfers the service definition information to the access/identity manager 324 operating within the logical federated security gateway 306 to hand over the processing of the service call. At block 1012, the process 1000, in cooperation with the access/identity manager 324, performs processing for conversion into the security policy that is to be used for the service call. At block 1014, the process 1000 transmits the service call to the local service provider endpoint.
At decision point 1016, the process 1000 makes a determination as to whether a response has been received from the local service provider endpoint. In response to determining that a response has been received from the local service provider endpoint, the process 1000 formats and transmits the response to the security gateway 310 operating within the architectural interconnection (gateway) 300 of the Domain A 102 for processing and delivery to the service consumer that originated the service call. The process 1000 returns to decision point 1002 and iterates as described above.
As described above in association with
Those skilled in the art will recognize, upon consideration of the above teachings, that certain of the above examples are based upon use of a programmed processor, such as CPU 202. However, the invention is not limited to such example embodiments, since other embodiments could be implemented using hardware component equivalents such as special purpose hardware and/or dedicated processors. Similarly, general purpose computers, microprocessor based computers, micro-controllers, optical computers, analog computers, dedicated processors, application specific circuits and/or dedicated hard wired logic may be used to construct alternative equivalent embodiments.
As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as JAVA™, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Aspects of the present invention have been described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers.
Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modems and Ethernet cards are just a few of the currently available types of network adapters.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a,” “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiment was chosen and described in order to best explain the principles of the invention and the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15067908 | Mar 2016 | US |
| Child | 15818696 | US | |
| Parent | 14542256 | Nov 2014 | US |
| Child | 15067908 | US | |
| Parent | 13890820 | May 2013 | US |
| Child | 14542256 | US | |
| Parent | 13424970 | Mar 2012 | US |
| Child | 13890820 | US |
