KR20050037990A - Web services broker - Google Patents

Abstract

The web service broker method according to the present invention provides an interface between at least one of a service client and a service provider and an enterprise, wherein the service client discovers web services on a service registry and uses a corresponding web service from the service provider. -; Communicating between an enterprise and at least one of a service client and a service provider; And a) converting information from or to the enterprise in a form suitable for at least one of the service client and the service provider, and b) at least one of the service client and the service provider in a form suitable for the enterprise. Performing at least one of converting information from or to at least one.

Description

Web service broker {WEB SERVICES BROKER}

The present invention relates to a web service, and more particularly to a web service broker.

[Related Application]

This application is based on US Provisional Application No. 60 / 374,034, filed April 19, 2002, the entire contents of which are incorporated herein.

One element of the next generation of electronic business systems is collaboration. Currently, collaboration includes a number of e-business automation applications, namely business-to-customer (B2C) or customer-to-customer (C2C) interaction, business-to-business (B2B) integration, It is narrowly interpreted by business logic componentization, business process orchestration, and legacy systems integration. These applications all have some things in common: they collaborate electronically to create an infrastructure that allows them to generate specific businesses. However, there is a limitation that there are no common worldwide frameworks (all people want to use) that all of these distributed applications (services) can work together to discover. Due to these limitations, a lot of investment and effort is being made to create appropriate purpose-oriented collaboration solutions, which are usually tightly coupled and platform / term / merchant / implementation / language (platform / technology / vendor / implementation / language), which is difficult to reuse in a uniform manner and may not be available on the Internet. Creating new collaboration points typically complicates the entire system, reduces stability, and requires more resources to maintain and expand these systems.

1 is a block diagram illustrating an example of independent business interaction.

2 is a block diagram of a web service concept.

3 is a block diagram of a web service concept with a service broker.

4 is a block diagram of a web service broker architecture.

5 is a block diagram of a web service broker architecture for aggregation and assembly.

6 is a block diagram illustrating an example of a computer system that may implement embodiments of the present invention.

7 is a block diagram illustrating another embodiment of a web service broker.

(Summary of invention)

The web service broker method provides an interface between an enterprise and at least one of a service client and a service provider. Here, the service client discovers web services in the service registry and uses the corresponding web service from the service provider, communicates between the enterprise and at least one of the service client and the service provider, and a) Converting information obtained from at least one of the service client and the service provider into a form suitable for at least one of the service client and the service provider.

The computer recording medium includes code executable by a computer to execute a web service broker. The computer recording medium may comprise code for providing an interface between an enterprise and at least one of a service client and a service provider, where the service client discovers web services in a service registry and uses corresponding web services from the service provider. Code for communicating between at least one of the service client and the service provider, a) converting information obtained from the enterprise into a form suitable for at least one of the service client and the service provider, b) in at least one of the service client and the service provider Code for performing at least one of converting the obtained information into a form suitable for the enterprise.

The programmed computer system for performing the web service broker method includes means for providing an interface between an enterprise and at least one of a service client and a service provider. Here, the service client finds web services in the service registry and uses the corresponding web service from the service provider, communicates between the enterprise and at least one of the service client and the service provider, and a) sends the information obtained from the enterprise to the service client and the service. Converting the information obtained from at least one of the service client and the service provider into a form suitable for an enterprise.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, the detailed description and advantages of the present invention will be readily obtained with reference to the accompanying drawings.

Specific terms are used to describe the embodiments of the invention shown in the drawings, which are for clarity of explanation. However, it is not intended that the present invention be limited to the specific terms so selected, and it is to be understood that each specific element includes all technical equivalents that operate in a similar manner.

6 illustrates an example of a computer system that can implement the methods and systems of the present invention. The systems and methods of the present invention may be implemented in the form of software applications running on computer systems such as, for example, mainframes, personal computers (PCs), handheld computers, servers, and the like. The software application may be stored on a recording medium that is locally accessible by the computer system, such as a floppy disk, compact disk, hard disk, etc., and may also be located away from the computer system and wired to a network such as a local area network (LAN), the Internet. Or may be made accessible via a wireless connection.

As shown in FIG. 6, a computer system, generally referred to as system 100, includes a central processing unit (CPU) 102, a memory 104 such as random access memory (RAM), a printer interface 106, and a display device ( 108, a local area network (LAN) data communication controller 110, a LAN interface 112, a network controller 114, an internal bus 116, and one or more input devices 118, such as a keyboard, a mouse, and the like. can do. As shown, system 100 may be connected to a data storage device, such as hard disk 120, via link 122.

As a need arises for an equitable, globally collaborative electronic environment, a new generation of electronic business automation systems and appropriate facilities are being devised. This new approach is called "Web Services (WS)." Here, "web" refers to conventional networking (including LAN to wireless), and "service" refers to electronic applications to distributed applications.

WS is a programmatic interface to the electronic business system that is defined and facilitates service interoperability by operating on various industry standards, including, for example, XML-based standards.

Each WS has a contract that includes a technical contract and a business contract. The technical contract defines the operations and the data types used to perform those operations. The technical contract also defines protocols and appropriate communication models. Business contracts are business-related metadata related to the service, such as category or taxonomy, support phone number, service level agreements, licensing model, etc. Define.

Examples of WS include stock quotes accessible by Universal Resource Locator (URL), product catalogs published on the Internet, Simple Mail Transfer Protocol (SMTP) message channels, Simple Object Access Protocol (SOAP) -based authentication agents, CORBA objects Etc. can be mentioned. All of these are network accessible components that perform specific functions. If properly described and arranged, any of the above components can be found, used and integrated into, for example, a potent business automation system.

In other words, the information technology (IT) industry has evolved from machine code to programming language, to client server programming, and further to object-oriented component models. Now it is evolving into a fluid, loosely coupled, service-based, distributed application that dynamically discovers, uses, and contracts with each other. That is, these applications dynamically "assemble" from distributed (usually independent) parts (services) at runtime to achieve a particular purpose. These are aggregated according to defined standards (eg, "fastest method of execution"), and they can be dynamically reconfigured at runtime, for example if one of the services does not meet the quality requirements.

In addition to the changes that occur in business automation systems with this new trend, user interfaces and interactive devices are also changing. User interfaces are installed to work in the WS environment, so that services can be discovered and implemented according to user actions. Interaction devices can provide support with appropriate hardware, software, and communication facilities.

1 shows an example of collaboration of independent businesses interacting with each other to display a list of the best restaurants near the user's current location on the screen of the wireless device 1. In this example, businesses each do what they do best. For example, wireless communication and geographic location service 2 is provided by a communications facility company for performing certain services, including determining the geographical location of a wireless user. The information portal 4 maintains user profiles and formats the information in a preferred manner. The map database service 6 translates the geographical location of the wireless user into addresses and provides information including the user's proximity to the restaurants. Restaurant guide 8 provides information including restaurant descriptions and rankings. The web service 10 provides a framework that allows user interaction with these dynamic business processes without creating tightly coupled technical implementations and fixed B2B relationships.

WS is a public standards-based approach, and it is possible to begin to globalize electronic business systems to some extent. For this purpose, various public bodies have been created and a set of standards such as XML, UDDI, WSDL, etc. (including legacy standards such as HTTP, TCP / IP, etc.), in collaboration with various industry leaders. Was derived.

WS combines a wide variety of unrelated standards, appliances, software and hardware equipment builders into one global, equitable framework. Thus, in a meaningful way, it becomes possible to create cooperating electronic business systems. In other words, two parties do not require tight integration of proprietary agreements and automated systems in order to cooperate electronically.

WS creates an environment in which services can be registered in a very general and descriptive way, and WS is still comprehensive and IT-enabled. The WS also makes the service available (eg, publishing the WS). WS also allows services to be discovered (wherever they are found), asks for the details needed to use them, and makes the service an asset (to discover / subscribe to WS). A subscription is also sometimes referred to as joining a server. WS also allows users of the service to run the service.

WS is a platform, programming language, merchant, terminology and arbitrary execution model. WS is dynamically discovered, contracted, combined, and executed. WS is loosely coupled and generally organized and distributed. WS does not depend on the evolution of communication facilities. In addition, WS has a characteristic of ubiquitousness. Due to the amount of information exchanged in one fragment and one of the services, there is no particular performance concern.

More specifically, the relationship between each of the elements (and their roles) for providing a successful WS environment is described in FIG. 2. These elements include the public, independent Service Registry (SR) 12, Service Providers (SP) 14 and Service Clients (SC) 16. Service providers 14 register their services with the service registry 12. Service clients 16 may discover and use services.

WS is based on messaging and XML descriptions in a typical networking environment. XML is a very common way to make information universal for use in the Internet age. WS is a framework of XML-based standards that address specific areas and have special meaning. Some of these areas and their standards for each are service registration (to register with SR 12): Universal Discovery, Description and Integration (UDDI), service description: Web Services Description Language (WSDL), service advertisement: ADS ( Advertisement and Discovery of Services, service addressing: Universal Resource Locator (URL), JNDI name, specific local area network (LAN) address, etc. Service invocation: Simple Object Access Protocol (SOAP), URL with parameters, WebDAV, etc. Service Data Abstraction and Data Marshalling: Extensible Markup Language (XML), XML Schema, etc. Presentations and Interactions: Dynamic HyperText Markup Language (DHTML), Wireless Markup Language (WML), PDF, Business-business protocol integration, such as VRML: RosettaNet, ebXML, etc. Common communication protocols: HyperText Transfer Protocol (HTTP), File Transfer Protocol (FTP), and Simple Message Tra nsfer Protocol (other): MQ series, WAP, etc., Common Security: Secure Services Layer (SSL), Digital Certificates (X.509), XML Signature (XSIG), etc., and Common Networking: Transport Communication (TCP / IP) Protocol / Internet Protocol), Domain Name Server (DNS), and the like.

UDDI is used to communicate with the SR 12 which holds business contracts for various services. SR 12 is a configuration on company / department level and / or public registry. WSDL is used to express technical contracts for services. WSDL defines the operations, indicates the data type definitions, and specifies the communication details and protocols for the service. XML schema is used to define the hierarchical data types used in service operations. XML holds the values of SOAP messages between the client and the service. The XML content follows the XML schema. HTTP (and TCP / IP) is used to convey messages between parties. HTTP is the main ubiquitous communication for WS.

WS joins them and adds new standards and concepts, enabling you to create flexible, distributed applications and services. WS is also a very flexible environment. For example, new communication protocols can be introduced without necessarily changing services and applications. WS applications are well isolated from the specifications, allowing the underlying infrastructure to evolve slowly. Also, WS doesn't standardize what services and how they work or can work. Instead, WS provides a way to describe, publish, and use services.

WS applications work in a specific way to provide services to users. This behavior is part of the WS framework. The operations include performing registration, publishing, discovering / subscription of services, and invocation.

To register and discover, the WS interacts with at least one SR 12 via HTTP (with or without SSL) using the Simple Object Access Protocol (SOAP), an XML messaging protocol. SOAP is an envelope definition that maintains requests and responses between clients and services. The Universal Discovery, Description and Integration (UDDI) standard defines the content of communication with SR 12.

UDDI documents describe business and services (electronic or not). Each business may maintain a registration entry with an SR 12 that constitutes a UDDI document hierarchy. The layer contains white pages that define business identities, yellow pages that classify business aspects (such as business classification, serviced partial DUNS numbers, etc.), and technical details of WS (service binding templates). A green page may be included. Green pages can refer directly to a service (such as the URL of a partial catalog), or they can embed / mentioned more detailed specifications such as WS interfaces, data types, security restrictions, and so on.

SR 12 may be replicated between multiple repositories to be global. Examples of global SRs may include uddi.microsoft.com or uddi.ibm.com. In addition, SR 12 may be shared within a company or among multiple participants, for example, via a delegated or dedicated repository.

When registering, the service provider (SP) 14 submits the appropriate UDDI entries to the SR 12 using SOAP UDDI APIs. The submission may also include a reference to the WSDL information and / or the WSDL information, eg in the form of a URL. Registration is a static step in that once information is submitted to SR 12, SR 12 maintains that information. Although entries may be changed, canceled, and / or resubmitted, SR 12 will generally generally make any changes, cancellations, resubmissions to the registrant if the SC 16 issues a question to discover the services. It does not require the back dynamically.

When finding available services, SC 16 retrieves UDDI documents by using SOAP UDDI APIs and requests information from SR 12. SC 16 may include selection criteria in a request to retrieve records for desired business and services. When a request is received from the SC 16, the SR 12 executes an appropriate query against the registration repository to find any suitable registered business and services. Discovery is a dynamic process.

If so, the SP 14 creates an interface that can be used to connect or communicate. For example, SP 14 may begin listing for SOAP requests on a particular URL. Also at this point, the SP 14 may make the WSDL information available if it was previously referenced in the UDDI entry during registration. The WSDL can be dynamically generated according to current WS parameters such as communication protocols that need to be used, for example. This is a dynamic process. The service can be disabled, enabled and reconfigured at any time. The SC 16 intelligently responds to this by, for example, switching to another available service, using different communication protocols, and thus marshalling data.

When subscribing (subscribing), the SC 16 interprets the WS description using the information in the UDDI and WSDL documents when available. The SC 16 generates the necessary interface representations, data marshalling stacks, communication pipes, authentication realms, etc. that can be used for service discovery. The application is generally a dynamic and reconfigurable process, but may be static if, for example, a concise language or technology integration is required.

If so, the SC 16 selects the WS interface, makes the necessary parameters, calls it, and then interprets the result. This is very similar to initiating the method on an Object Oriented component (OO component). In certain cases, such as a concise language-to-WS connection, this can be an OO component. The differences are details that are flexible and will typically be hidden from usage patterns in processors such as web-ready communications, data marshaling, authentication, and the like.

The types of WS can vary and can generally be limited to three different types depending on the control and data flow that define the operations. In general, an e-business has a mix of different types of WSs depending on the purpose they serve.

One type of WS may be an information source. For example, A publishes information to a particular address, makes changes to it, and B subscribes to that information source, retrieves content, and subscribes to changes. In this case, A is passive and B is active. Data flows from A to B.

Another type of WS can be a messaging queue. For example, A sets up an incoming communication channel at a specific address, B sets up an outgoing communication channel to enter information into it, and A listens to and receives information from that channel. It is. In this case, A is passive, B is active, and data flows from B to A.

Another type of WS can be a Component Service. For example, A exposes a set of interfaces to a particular address, implements the processing of requests made to these interfaces, and B launches the interface, passing in and receiving information in requests and responses. In this case, A is passive, B is active, and dataflow is bidirectional.

Making a product catalog available on the web is most likely a WS of information source type to be considered. B2B purchase / invoice processing is most likely considered a WS for messaging queue type. Connecting to geolocation services for accurate location is most likely a WS of component service type.

Any kind of collaborative e-business automation system can be created using the three types of WS listed above. To cover any type of web collaboration, it would be sufficient to have these types of WS types.

As will be appreciated, the WS environment is an efficient and versatile framework for all kinds of electronic collaboration. However, to make the best use of its capabilities, it must be connected to existing technologies, infrastructure, business processes, and so on. This is especially so, as this is the beginning of this IT revolution cycle that builds the foundation and puts the technology framework in place. To do this, the system must affect the accumulated information, reuse and extend the existing system and lead them to a new level of development, which will make them more global. To address this concern, a service broker (SB) as described herein may be introduced into the WS concept described above.

3 shows a service broker applied to the WS concept described above with respect to FIG. As shown in FIG. 3, service broker (SB) 30 is a WS platform for an IT-enabled enterprise 32. SB 30 interprets the service implementation model and automatically creates a technical business contract that conforms to the above-pointed standards. SB 30 subscribes the business contract to the SR 12 of choice, then listens to the SOAP request, processes the SOAP request, and associates the call with a practical implementation in, for example, Java or C ++.

SB 30 may perform a number of different functions and roles. For example, SB 30 may provide a technology foundation for WS activities. This includes the web communication layer, XML data marshaling, SOAP request processor, UDDI communication APIs, WSDL bindings, and so on. The SB 30 integrates enterprise technology to (1) unify the OO model for data and logic, (2) coordinate the disparate technologies, and (3) build sub-substructures (such as EJB or COBRA). Can be united. In addition, SB 30 may provide tools and functions for developing existing (integrated) systems, parts, and components as a WS. This includes accepting WS registration, publishing, implementation requests, and translating all of these into the original implementation activities. In addition, the SB 30 may integrate the external WS to discover the WS within the SR 12 and subscribe to the WS. This may mean associating the WS with any required technology, language, or model so that it may be natural for the target application to use the WS in appropriate terms. In addition, WS integration facility functionality may be provided to isolate dynamically selectable and configurable details such as data marshalling and communication protocols from a target application. In addition, SB 30 may provide tools and functions for WS aggregation. This can include integration of WS, representing them in a common process component model, process modeling tools (eg, UML), coordinated process execution time (workflow-like), and dynamic WS development facilities. In addition, the SB 30 may provide a WS Management Console (WSMC). WSMC defines UDDI entries, subscribes / modifies, maintains local registration replication and common business information, moves entries from one SR repository to another, includes and excludes services, configures communication protocols, Integrate a set of tools for adding security and more. In addition, the SB 30 may provide for selective logging and quality of service (QoS) analysis.

In order to successfully interface existing systems and not duplicate efforts already developed in the underlying technology, SB 30 uses an intermediate infrastructure layer and integration services. This allows business logic, eg implemented as EJBs and hosted on a scalable application server, to be deployed as a set of WS.

To deploy or use WS, technical and implementation details can be hidden. SB 30 provides a "technology insulation" with isolation and abstraction functionality based on standards, XML data marshaling, common networking, and the like. These features coordinate, map, and transform between the actual implementation and the abstract WS representation. For example, a SOAP message can be translated into a method call on an EJB object, and the result can then be represented and returned as XML generated according to a particular agreed upon schema.

To make the SB 30 easier to use, visual tools can be used to smooth and linear the transformation to WS. Since the tools can be used to deploy a new WS, the tools are still provided after the conversion has taken place.

The tools are easy to use, intuitive, and rely heavily on the automated deployment and integration functions provided by the SB 30. For example, to distribute an EJB object to WS, you can browse the visual web representation (page) of that object and request its registration and publication as a WS right from the web page. The rest of the process will be performed automatically by the SB deployment function based on the OO model of the EJB object and its attributes. To subscribe to WS, a user can visually search or browse through the registration information, select the required service, and choose to subscribe. The request will then be passed to the UDDI and SB integration functions to query the additional WSDL to generate the appropriate OO model of WS and register it in the catalog.

An example of the core of a WS broker (SB) 30 according to an embodiment of the present description is shown on FIG. 4. The SB 30 includes a unification, coordination and federation layer (integration) 40, a web services layer (globalization) 42, a WS deployment tool 44, a WS integration tool 46, and a WS management tool 48. Major components such as may be included. Each component will be described in more detail below.

The Unification, Coordination and Federation Layer (40) hosts a unified OO model of specific technologies and implementations (e.g., relational DB or mainframe green screens or EJB objects). Maps (binds) between a unified OO model and a specific technology or language (languages such as C ++, Java or technologies such as ODBC), and activities on specific technologies, implementations and platforms (e.g., correlational DB and Adjusts execution and environment context between span transactional control across CICS, or subscribing to events originating from EJB containers in C ++ code, and sub- (such as EJB, COM, or COBRA). It is responsible for associating the infrastructure into one access and control point.

The web service layer 42 is responsible for abstracting the unified OO models hosted as a WS at layer 40 and isolating them from any technical and section details. Layer 42 performs all standard WS operations such as registration, publication, discovery, subscription, and use. The web service layer 42 includes various functions that form a globalization layer. Functions forming the globalization layer include registration / discovery function 50, publication / processing function 52, subscription / subscription function 54, XML data marshaling function 56 and web communication function 58. do.

The registration / discovery function 50 registers the components (both data and logic) represented by the global OO model as WS and / or implements an automated procedure for retrieving the WS according to the selection criteria provided. Function 50 contacts SR 12 using SOAP over HTTP, creates and subscribes to appropriate UDDI documents, or executes a selected query, and queries UDDI documents describing the WS. In addition, function 50 implements procedures for changing registration information, maintaining business-related entries, implementation of registration entries, and reapplying to another SR repository. In addition, function 50 maintains a copy (catalog) of all registration entries and a relationship to the OO model of original components within the registration database (not shown).

The publication / processing function 52 is responsible for generating the WS technology description (eg, WSDL) and makes the WS interface available for access using the web communication function 58. For example, function 52 may register a SOAP listener for a particular URL so that WS may indicate its Internet client. In addition, function 52 may accept the requests and initiate the necessary activities (process requests) in the original OO model of WS hosted at the integration layer. Layer 52 may use the XML data marshalling function 56 to properly represent data for each side.

The subscription / subscription function 54 queries the technical details for the WS (eg, WSDL), creates a unified OO model for it, and makes it one of the assets available to the integration layer 40. Function 54 then translates the activities associated with the WS OO model into the actual external WS implementation in accordance with the WSDL description. Function 54 uses XML data marshalling function 56 to convert data to and from XML and OO representations, and use web communication function 58 to forward requests to external WS and receive responses. do. It should be noted that the integration layer performs the actual binding of the integrated (subscribed) WS to a specific technology or language. Depending on the target application, the integration layer 40 may generate a static or dynamic binding to the unified OO model of WS.

The XML data marshaling function 56 is used to summarize the OO data model and data types in the XML. Function 56 provides bidirectional translation between the unified layer and the unified OO model used by the universal XML data representation. Function 56 also transform codes the data element relationships. For example, function 56 may represent one object that contains another object as nested elements in XML. The XML data marshaling function 56 supports multiple standards representing data schemas and data types. Function 56 is also used for template-based data marshaling (mapping) using the XSL transformation language, which becomes the standard for this purpose.

The web communication function 58 includes connection and messaging techniques applicable to ordinary networking (eg, the web). Function 58 ensures the security of the communication channel, guaranteed message transmission, non-reputation, and the like. Some public standards that are integrated and supported include HTTP, FTP, SMTP, SSL, X.509, and XSIG. Additional communication mechanisms commonly used may also be provided, such as the MQ series, MSMQ, WQP, and the like.

The tool may include a WS deployment tool 44 that is a visual tool (web-based GUI) for viewing, retrieving, selecting, and making available as a WS the components (data and logic) hosted within the integration layer. . By default, tool 44 automatically deploys WS with the most appropriate parameters, but also allows application in specific requirements, including the selection of published interfaces, security in communication channels, types of calling protocols, and the like. The WS deployment tool 44 uses the publication / processing function 52 and the registration / search function 50. WS deployment tool 44 can also be used to modify WS parameters at runtime to invalidate WS.

Another tool, WS integration tool 46, is a visual processing implementer such as a wizard that allows for retrieval of a WS and subscription to a selected WS according to some criteria. The tool 46 displays the details needed to select the appropriate service when searching for the WS, and shows the final asset (OO model) hosted within the integration layer after joining the WS. The WS integration tool 46 can use the registration / discovery function 50 and the subscription / subscription function 54.

Another tool, WS management tool 48, is the WS management console (WSMC). The tool connects to the announcement / processing function 52 and the subscription / subscription function 54 to inquire about detailed runtime issues regarding the deployed and integrated WS. Tool 48 uses registration / discovery function 50 to monitor SR 12. General runtime information about the WS and SR 12 is indicated by the WSMC. The tool 48 also generates QoS analysis reports for specific WS and SR repositories distributed or integrated.

The other duties of WSMC are the WS templates and commons (UDDI related) maintained by the registration / discovery function 50 to register business entries, register basic business services and information, and move entries from an SR repository to another. To display and edit the registration database of business entries.

Other services performed by the SB 30 are a set and combination of web services. There is no need to implement WS in any particular technology or language. With the transition to a new IT paradigm of universally interfaced network-based services, most of the components needed for any business process are already readily available, so what you need is to connect and coordinate between them to add value services. ) To provide (implementation) where needed. This process will be called WS aggregation and combination. This is a high level of processing that does not necessarily require knowledge of specific skills or languages, but rather relies on knowledge of the relationship between business processing and business components.

In addition to mediating between specific implementations and abstract WS representations, current WS brokers may function to aggregate and combine new WSs from selected existing ones. To do this, the external WS is integrated into a convenient OO model that is easy to manipulate. This can be done with the help of the WS integration tool 46. The modeling tool can be used to define an aggregated WS OO model and can be used to lay out an execution sequence that includes an OO model of integrated external WS components. There can be multiple execution sequences associated with the activities of the aggregated WS, each sequence being a workflow, and can be defined within the workflow period using appropriate visual tools. Integration layer 40 may host the aggregated WS OO model and workflow sequences. Dynamic Web service deployment can be used to automatically deploy aggregated WS. When the aggregated WS is used, the process execution runtime can execute the appropriate workflow sequence, causing the integrated external WS where necessary (via their OO model).

It should be borne in mind that there is still a need to traverse within the core functions of the SB that apply in relation to aggregation and combination. For example, you can provide a newly added value WS based on a hardware security transcoder, and aggregate it with other existing external WS (such as an account database or certificate authority) to provide a new, faster authentication WS.

5 is a block diagram of a web service broker architecture (set and combination). WS aggregation and combination introduces three components into the core of the SB 30. These components include a component / process modeling tool (UML) 60, a process execution runtime 62 (such as a workflow), and a dynamic web service deployment function 64.

The component / process modeling tool (UML) 60 is a visual tool for defining an OO model and processing sequence by showing diagrams and relationship diagrams of OO components. For example, it may be a UML-based modeling tool that integrates the OO component model and interfaces with the integration layer 40 to distribute the final aggregated OO model and processing sequence. The tool can also be used to accept, edit, and modify the aggregated OO model to reflect this change in the integration layer 40.

The process execution runtime 62 derives the process sequence from the aggregated OO model hosted within the integration layer and executes it in the appropriate relationship and order. Process 62 synchronizes and schedules execution to implement the originally designed relationships within component / process modeling tool 60.

The dynamic web service deployment function 64 automatically deploys the aggregated OO model of the new service model as WS. Function 64 implements the default deployment process, in which the WS deployment tool 44 (FIG. 4) will be used to make decisions about making OO components, but otherwise the WS was originally designed as an aggregated WS. It will be used to base dynamic recognition of the OO model (hosted by the integration layer 40). Function 64 may modify an already deployed set WS (eg, using a modeling tool) when the associated OO model changes.

 7 illustrates a web service broker (WSB) as a common component commonly referred to as a common component broker (CCB) 200 that allows existing products and technologies as universally interoperable business components or web services. CCB 200 also provides an implementation neutral model driving architecture and platform for Web services (WS).

Some examples of application scenarios in which the CCB 200 is applicable include allowing existing products for WS platforms such as, for example, .NET or J2EE / JAXP environments, where the existing products are external WS (eg,. NET Hale Storm Calendar Service), or if the new WS is built according to the desired public service contract. In general, many business automation systems, user interface devices, and development tools will have WS rights in the coming years. However, there is currently a desire to authorize existing technologies and products as WS for universal interoperability. CCB 200 describes this need with tools and packaged engines that are not tied to a particular platform and do not require an application server or any other product to run.

CCB 200 may use open source technology. For example, CCB 200 may use the Apache Axis as a common SOAP protocol stack, and Apache Tomcat may be used to perform HTTP communications and the like.

7 shows a diagram of the architecture of CCB 200. The web service broker core 202 maintains a pool of published and subscribed WSs. The published WS may be actively executed at runtime by the calling processor, which may be directly (e.g. in the case of a Java class, etc.) or directly (e.g. in the more extensive OO encapsulation and C ++ implementation, etc.). E) Advantages Mapping to the actual service implementation through IS integration. The subscribed WS is mapped to the runtime as an operational dynamic proxy that, for example, can be invoked by a client-side static proxy using Java RMI.

The following components may be included in the CCB 200 for implementing various features of the present invention. The publishing core 204 processes the request for the Internet protocol, triggers the actual service implementation, and generates a WS description. The publishing core 204 may also include a well-defined set of APIs and a repository data model. The publishing core 204 can handle transaction aggregation, data access, security, and other details. The publishing core can implement trigger plug-ins for advantages IS objects, Java classes, and so on.

The registration core 206 may register the WS in the public / corporate service registry and may retain and synchronize registration information in the repository 208 and the service registry 12.

The subscription core 210 retrieves the WS within the public service registry, queries the WS description, combines the subscribed WS into a language implementation (e.g. Java), issues a request over the Internet protocol, and subscribes to it. Can be sent to WS Subscription core 210 may also include a well-defined set of APIs for handling transactions, security, and other details. Joining a subscribed WS can create a client proxy within Java or an advantage IS connector.

The security core 212 may be, for example, a security system such as an eTrust WAC client, which may publish the publication core 204, the subscription core ( 210 and register core 206. The security core 212 may also encrypt / decrypt and sign / verify the message if necessary.

Repository 208 may be a SQL database and may include, for example, an object-to-relational mapper implemented as an advantage IS connector. Repository 208 holds and organizes information about published and subscribed services, transaction and communication logs, system configuration parameters, and the like. Repository 208 may also serve as the main control center for CCB 200. For example, an application may only authorize a new service implementation descriptor object to the repository 208 to deploy and activate the WS. The CCB 200 can then capture the events from the repository 208.

Web access control (WAC) 214 may be a security system such as an e-trust to provide a centralized policy-based authorization and authentication server. WAC 214 may use an LDAP directory as a repository for the identity of users / groups. The WAC 214 may provide a management tool for security policy management and user / group creation / deletion.

Benefits Enterprise application integration layer 216, such as integration servers, can be used to integrate data sources and provide transaction / connection aggregation, event management, object caching, load balancing, messaging, and wrap C ++ service implementations. have.

Java 218 can drive CCB 200 and can provide access to web service implementations in Java as well as host client proxies for subscribed web services.

The external product 219 can provide a service implementation that maps to or wraps with a C ++ or Java structure. The external product 219 can also consume (use) a client proxy generated for the subscribed web service.

Basic web GUI 220 may be a web-based user interface that allows searching for service implementations (eg, Java or IS IS) and publishing the WS to selected implementations (eg, publishing GUIs). GUI 220 also lists currently published and subscribed services, modifies their run / registration parameters at runtime, monitors current transactions, analyzes communication logs, displays performance graphs, etc. For example, management and configuration GUIs). Global configurations may include service registry specifications, business / category registrations, network proxy information, and the like.

Subscription extension GUI 222 may provide user interface processing such as a wizard that allows a query to a public / enterprise service registry for a particular WS. The system can then generate Java classes or EJB proxies that encapsulate WS for client use. The system can also create a client WS proxy that can be used as an advantage IS object for combining other languages, for example C ++ or VB.

The service contract designer 224 may take a UML (or UML-like) model of the service contract (represented by data structures and interfaces) to generate a WS specification (eg, WSDL). The WSDL specification can then be used as a vertical WS standard for any particular subject area. The WSDL can be provided in a standard body. The designer can then create implementation skeletons in C ++ or Java that conform to the original service contract.

The present invention can be readily implemented using one or more conventional general-purpose digital computers and / or servers programmed according to the present disclosure. Appropriate software coding may be provided by a skilled programmer based on the disclosure of the present invention. The invention may also be implemented by providing application specific integrated circuits or by interconnecting a suitable network of conventional component circuits.

Many additional modifications and variations of the present invention are possible in light of this disclosure.

Claims (12)

As a web service broker method, Providing an interface between at least one of a service client and a service provider and an enterprise, wherein the service client discovers web services on a service registry and uses a corresponding web service from the service provider; Communicating between an enterprise and at least one of a service client and a service provider; And a) converting information from or to an enterprise in a form suitable for at least one of the service client and the service provider; and b) at least one of the service client and the service provider in a form suitable for the enterprise. Performing at least one of converting information from or to at least one of Web service broker method comprising a. The method of claim 1, The enterprise is a web service broker method comprising a software product. The method of claim 2, And the web service broker is provided to enable the software product for a web service platform. The method of claim 3, The web service platform includes at least one of .NET and J2EE / JAXP. A computer recording medium containing computer executable code for implementing a web service broker, comprising: Code for providing an interface between at least one of a service client and a service provider and an enterprise, wherein the service client discovers web services on a service registry and uses a corresponding web service from the service provider; Code for communicating between an enterprise and at least one of a service client and a service provider; And a) converting information from or to an enterprise in a form suitable for at least one of the service client and the service provider; and b) at least one of the service client and the service provider in a form suitable for the enterprise. Code for performing at least one of converting information from or to at least one of Computer recording medium comprising a. The method of claim 5, The enterprise includes a software product. The method of claim 6, And the web service broker is provided to enable the software product for a web service platform. The method of claim 7, wherein The web service platform includes at least one of .NET and J2EE / JAXP. Programmed computer system for performing Web service broker methods, The web service broker method, Providing an interface between at least one of a service client and a service provider and an enterprise, wherein the service client discovers web services on a service registry and uses a corresponding web service from the service provider; Communicating between an enterprise and at least one of a service client and a service provider; And a) converting information from or to an enterprise in a form suitable for at least one of the service client and the service provider; and b) at least one of the service client and the service provider in a form suitable for the enterprise. Performing at least one of converting information from or to at least one of Programmed computer system comprising a. The method of claim 9, The enterprise comprises a programmed computer system. The method of claim 10, And the web service broker is provided to enable the software product for a web service platform. The method of claim 11, The web service platform includes at least one of .NET and J2EE / JAXP.