JP2006526189A - Web service broker - Google Patents

Abstract

The web service broker method provides an interface between an enterprise and at least one of a service client and a service provider, the service client discovering a web service on a service registry and from the service provider. Using a corresponding web service to communicate between the enterprise and at least one of the service client and service provider, and (a) information from or to the enterprise to the service client And (b) information appropriate to or from at least one of the service client and service provider is converted to a form suitable for at least one of the service provider and service provider. Na Converted into Omu, performs at least one of, encompasses that.

Description

  The present invention relates to web services, and more particularly to web service brokers.

  One element for the next generation of electronic business systems is collaboration. Currently, collaboration is based on a number of electronic business automation applications: business-to-customer (B2C) or customer-to-customer (C2C) interaction, business-to-business (B2B) integration, business logic componentization, business process orchestration, legacy system integration, etc. Narrowly dealt with. All of these applications have something in common in that they collaborate electronically to form the infrastructure for doing a business. However, one limitation of this is that a common global framework (everyone uses) that all these distributed applications (services) can interoperate and discover each other. Lacks what agrees.

  This limitation has generated considerable investment and effort to form a suitable goal-oriented collaboration solution, which is usually tightly coupled and is platform / technology / vendor / implementation / language -Is dependent, difficult to reuse in a uniform manner, may not be ready for use on the Internet, etc. Creating a new collaboration point typically increases the overall system complexity, reduces reliability, and requires additional resources to maintain and expand such a system.

  The web service broker method provides an interface between an enterprise and at least one of a service client and a service provider, the service client discovering a web service on a service registry and corresponding from the service provider Using a web service to communicate between the enterprise and at least one communicating with at least one of the service client and service provider, and (a) to or from the enterprise Information into a form suitable for at least one of the service client and service provider, and (b) information from or to at least one of the service client and service provider The Converted to the appropriate form with respect Ntapuraizu, performs at least one of, encompasses that.

  A computer recording medium includes code executable by a computer to implement a web service broker. The computer recording medium is a code that provides an interface between an enterprise and at least one of a service client and a service provider, wherein the service client discovers a web service on a service registry and from the service provider. A code for using the corresponding web service, a code for communicating between the enterprise and at least one of the service client and service provider, and (a) information from or to the enterprise To a form suitable for at least one of the service client and service provider, and (b) information from or to at least one of the service client and service provider. Converted to the appropriate form with respect to prize has the code, for performing at least one of.

  A programmed computer system for implementing a web service broker method provides an interface between an enterprise and at least one of a service client and a service provider, wherein the service client is a web service on a service registry. And using a corresponding web service from the service provider to communicate between the enterprise and at least one of the service client and service provider, and (a) from the enterprise or Converting information to it into a form suitable for at least one of the service client and service provider, and (b) at least one of the service client and service provider. Converted to the appropriate form of La or information to it with respect to the enterprise, to perform at least one of, it encompasses that.

  In describing embodiments of the present invention illustrated in the drawings, specific terminology will be used for the sake of convenience. However, it is to be understood that the invention is not intended to be limited to the specific terms so selected, and that each element includes all technical equivalents that operate in a similar manner. It is.

  FIG. 6 shows an example of a computer system capable of implementing the method and system of the present invention. The system and method of the present invention can be implemented in the form of a software application running on a computer system such as a mainframe, personal computer (PC), handheld computer, server, etc., for example. The software application can be stored on a recording medium that is locally accessible by a computer system, such as a floppy disk, compact disk, hard disk, etc., or remote from the computer system and, for example, It can be accessible to a network such as a local area network or the Internet via a hardwired or wireless connection.

  As shown in FIG. 6, a computer system generally referred to as a system 100 includes a central processing unit (CPU) 102, a memory 104 such as a random access memory (RAM), a printer interface 106, a display unit 108, and (LAN) local An area network data transmission 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, etc. can be included. As shown, the system 100 can be connected to a data storage device, such as a hard disk 120, via a link 122.

  A need for a fair global electronic collaboration environment will be realized, and a new generation of electronic business automation systems and appropriate infrastructure are being developed. The new approach is known as “web service”. “Web” means normal networking (from LAN to wireless) and “service” means an electronic interface into a distributed application.

  A web service is a programmatic interface to an electronic business system that is defined and operates based on various industry standards, including, for example, XML-based standards that ensure interoperability.

  Each WS has a contract that includes a technical contract and a business contract. A technical contract defines the operations and the data types used to perform these operations. The technical contract also defines the protocol and the appropriate communication mode. A business contract defines business related metadata around the service. For example, categories or classifications, support phone numbers, service level agreements, licensing models, etc.

  Examples of web services (WS) include stock quotes accessible via a universal resource locator (URL), product catalogs published on the Internet, simple mail transfer protocol (SMTP) message channel, simple object access protocol ( (SOAP) based authentication agents, CORBA objects, etc. can be included. All of these are components accessible by a network that implements certain functionality. If properly described and organized, any of the above components can be discovered, used, and collected, for example, in a dynamic business automation system.

  In other words, the information technology (IT) industry has evolved from machine code to programming languages, then to client-server programming, and then to object-oriented component models. It is now evolving into a distributed application based on loosely coupled services that are flexible to discover, use, and contract with each other dynamically. That is, these applications are dynamically (assembled) from parts (services) distributed at runtime (and generally independent) to achieve certain goals. They can be assembled according to defined criteria (eg “the fastest way to do it”) and they are, for example, when one of the services does not meet quality requirements It can be reconfigured dynamically at runtime.

  In addition to the changes that occur to business automation systems with this new trend, user interfaces and interaction devices are also changing. The user interface can be built into work in a WS environment so that the user interface can discover and invoke services according to user actions. The interaction device can provide support with appropriate hardware, software, and communication infrastructure.

  FIG. 1 shows one example of independent business collaborations that interact with each other to display a list of preferred restaurants close to the user's current location on the screen of the wireless device 1. In this example, each business does what it does best. For example, the wireless communication and positioning service 2 is provided by a communication infrastructure company to implement certain services that include determining the geographical location of wireless users. The information portal 4 maintains user profile and format information in a suitable manner. The map database service 6 converts the wireless user's geographic location into an address and provides information that includes the user's proximity to the restaurant. Restaurant guide 8 provides information including restaurant descriptions and rankings. The web service 10 provides a framework for this dynamic business process and user interaction to take place without creating a static B2B relationship or a tightly coupled technical implementation.

  Web services are an approach based on public standards, which have begun to globalize electronic business systems to that extent. To that end, several public institutions were formed, and a set of efforts such as XML, UDDI, WSDL, etc. (and legacy standards such as HTTP, TCP / IP, etc.) were made by several industry leaders working together. The standard was formed.

  WS combines multiple generally unrelated standards, organizations, software and hardware infrastructure builders into one global and equitable framework. Therefore, it is possible to form a collaborative electronic business system in a meaningful manner. That is, it does not require a proprietary agreement and close integration for the two parties to collaborate electronically.

  WS forms an environment for registering services in a very general and descriptive manner, but it is comprehensive and IT-enabled. It also makes the service available (eg, publish it). It also makes it possible to find a service (wherever it is), query for the details necessary to use it, and make the service an asset (find / subscribe it) Do). Subscriptions are also sometimes referred to as fast for services. The WS also allows the service to be used (calls the service).

  WS is unaware of platforms, programming languages, vendors, technologies, and implementation models. WS is dynamically discovered, contracted, bound, and aroused. WS is a loosely coupled universally organized and distributed. WS can also interact through normal networking using coarse-grained messaging. This means that it does not depend on the evolution of the communication infrastructure. Furthermore, it is ubiquitous. There are no significant performance concerns due to the amount of information exchanged in one fragment and the granularity of the service.

  Next, in more detail, the relationship between each of the elements (and roles) for providing a successful WS environment is shown in FIG. These elements include a public, global, independent service registry (SR) 12, service provider (SP) 14, and service client (SC) 16. The service provider 14 registers these services in the service registry 12. The service client 16 can discover and use these services.

  WS is based on XML description and messaging in a normal networking environment. XML is a very common way to make information universal for the development of the Internet age. WS is a standard framework based on XML that has a special meaning and addresses an area. Some of these areas and standards for each are service registration (to register with SR12): UDDI (Universal Discovery Description and Integration), service description: WSDL (Web Service Description Language), service advertisement: ADS ( Advertisement and discovery of service), service addressing: URL (universal resource locator), JNDI name, specific LAN (local area network) address, etc., service call: SOAP (simple object access protocol), URL with parameters, WebDAV, Etc., Service Data Abstraction and Data Marshalling: XML ), XML schema, etc. Presentation and interaction: DHTML (dynamic hypertext markup language), WML (wireless markup language), PDF, VRML, etc. Business-to-business process integration: RosettaNet, ebXML, etc. Common communication protocols: HTTB (Hypertext Transfer Protocol), FTP (File Transfer Protocol) and SMTP (Simple Message Transfer Protocol), others: MQSeries, WAP, etc. Common Security: SSL (Secure Service Layer), X. 509 (digital signature), XSIG (XML signature), etc. and common networking: TCP / IP (Transport Communication Protocol / Internet Protocol), DNS (Domain Name Service), etc.

  UDDI is used to communicate to SR 12 that holds business contracts for multiple services. The SR 12 can be set up at the company / department level and / or can be a public registry. WSDL is used to represent a technical contract for a service. WSDL defines operations, references data type definitions, and specifies protocol and communication details for services. XML schema is used to define hierarchical data types used in service operations. XML holds the value in the SOAP message between the client and the service. XML content follows the XML schema. HTTP (and TCP / IP) is used to carry messages between parties. HTTP is the main ubiquitous communication method for WS.

  WS brings them together and adds new standards and concepts to form a framework for flexible and distributed applications and services. WS is also a very flexible environment. For example, new communication protocols can be introduced without the need to change services and their applications. WS applications are well separated from specific ones, making it possible to deploy the underlying infrastructure. Furthermore, WS does not standardize what services do or can do and how and how they can do. Instead, WS provides a way to describe, publish and use services.

  WS applications operate in some manner to provide user services. This operation is part of the WS framework. This operation includes registration, publishing, discovery / subscription and service invocation.

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

  UDDI documents describe businesses and their services (electronic or not). Each business can maintain a registration entry with SR 12 consisting of a UDDI document hierarchy. This hierarchy includes white pages that define business identities, yellow pages that categorize business aspects (such as business classification, serviced part D-U-N-S numbers, etc.), WS technical details ( A green page describing a service binding template) can be included. The green page can directly reference the service (like the URL of the parts catalog), or embed or reference more detailed specifications such as WS interface, data type, security constraints, etc.

  SR12 is global and can be replicated across several repositories. An example of global SR is uddi. Microsoft. com or uddi. ibm. com etc. The SR 12 can also be shared within a company or among several participants, for example via a delegated or private repository.

  When registering, the service provider (SP) 14 submits the appropriate UDDI entry to the SR 12 using the SOAP UDDI API. This submission can also include WSDL information and / or references to WSDL information, for example in the form of a URL. Registration or registration is a static step in the sense that once information is submitted to SR 12, SR 12 maintains that information. The entry may be changed, canceled and / or resubmitted, but SR12 typically changes, cancels, or changes from the registrant, for example when the SC 16 is running a query to discover the service. There is no dynamic request for resubmission.

  When finding an available service, the SC 16 retrieves the UDDI document by using the SOAP UDDI API to request information from the SR 12. SC 16 may include selection criteria in its request to retrieve records about the desired business and their services. When the request is received from the SC 16, the SR 12 runs appropriate queries against the registration repository to find valid registered businesses and services. Discovery is a dynamic process.

  When publishing, SP 14 makes the interface available for connection or communication. For example, the SP 14 begins listening for a SOAP request for a URL. In this regard, the SP 14 may also make the WSDL information available if it was previously referenced in the UDDI entry during the registration period. WSDL can be generated dynamically depending on the current WS parameters such as the communication protocol that needs to be used. This is a dynamic process. Services can be disabled, enabled, and reconfigured at any time. The SC 16 can respond to this intelligently, for example by switching to another available service using different communication protocols and thus organizing the data.

  When making a subscription (binding), the SC 16 interprets the WS description using UDDI and the information in the WSDL document if available. SC16 forms the necessary interface representation, data organizing stack, communication pipe, authentication scope, etc., which can be used for service invocation. Subscription is usually a dynamic and reconfigurable process, but it can also be static if, for example, precise language or technology integration is required.

  When calling, the SC 16 selects the WS interface, builds the necessary parameters, makes a call and then interprets the result. This is very similar to invoking methods for OO (object oriented) components. In some cases, such as fine language to WS binding, it can be an OO component call. However, the difference is flexible, web-ready communications, data organization, authentication and other processes, the details of which are usually hidden from usage patterns.

  There are various types of WS and they can usually be divided into three different types depending on the control and data flow that define their operation. Typically, one electronic business has a mix of different types of WS depending on the purpose for which it functions.

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

  Another type of WS may be a messaging queue. For example, A establishes an incoming communication channel at an address, B establishes an outgoing communication channel and pushes information into it, and A listens and listens for information from that channel. In this case, A is passive and B is active, and data flows from B to A.

  Another type of WS may be a component service. For example, A exposes a set of interfaces at an address and performs the processing of requests made to those interfaces, B invokes the interface, passes and receives and responds to information in the request. In this case, A is passive, B is active, and data flows in both directions.

  Making the product catalog available on the web is almost considered to be the information source type WS. The B2B purchase / billing process is almost considered to be a messaging queue type WS. Contacting the positioning service for your exact location is almost considered a component service type WS.

  Any kind of collaborative electronic business automation system can be built using the three types of WS listed above. Having these types of WS types is sufficient to cover any type of web collaboration.

  As can be seen from the above, the WS environment is an efficient and diverse framework for all kinds of electronic collaboration. However, to fully use its power, it should be related to existing technologies, infrastructure, business processes, etc. This is especially true because it is the beginning of these IT evolution cycles and it is possible to build the foundation and organize the technical framework. To do this, the system should leverage the accumulated knowledge and reuse and extend existing systems to bring them to the next level of deployment, which makes them more universal Let it be. To address these concerns, a service broker (SB) as described herein can be introduced into the WS concept described above.

  FIG. 3 illustrates a service broker applied to the WS concept described above with respect to FIG. As shown in FIG. 3, the service broker (SB) 30 is a WS platform for the IT enabled enterprise 32. The SB 30 analyzes the service implementation model and automatically forms technical and business contracts that conform to the standards described above. The SB 30 submits the business contract to the selected SR 12, then listens for the SOAP request, processes the SOAP request, and relays the call to the actual implementation, for example in Java or C ++.

  The SB 30 may perform many different functions and roles. For example, the SB 30 may provide a technical basis for WS activities. This may include web communication layers, XML data reduction, SOAP request processors, UDDI communication APIs, WSDL bindings, and the like. The SB 30 integrates enterprise technologies (1) unifies the OO model for data and logic, (2) coordinates between different technologies, and (3) links sub-infrastructure (EJB or CORBA). The SB 30 can also provide tools and equipment for deploying existing (integrated) systems, parts and components as WS. This may include registering the WS, publishing it, accepting the call request and converting them all back to the original implementation activity. The SB 30 can also integrate an external WS to discover and subscribe to the WS in the SR 12. This means binding WS with the required technology, language or model to be natural to the target application in order to use WS in the appropriate terminology. WS integration facility functions can also be provided to separate dynamically selectable and configurable details such as data organization and communication protocols from the target application. The SB 30 can also provide tools and equipment for the WS set. This includes WS integration that represents them in a generic process component model, process modeling tools (eg, UML), forced process execution runtimes (such as workflows) and dynamic WS deployment facilities. It is possible. The SB 30 can also provide a WS management console (WSMC). WSMC defines and submits / modifies UDDI entries, maintains local registration replicas and common business information, redeploys (moves) entries from one SR repository to another, includes and excludes services In some cases, a set of tools necessary for configuring a communication protocol, imposing security, and the like are incorporated. The SB 30 can also provide selective logging and quality of service (QoS) analysis.

  In order to effectively interface existing systems and not to repeat the efforts already invested in the basic technology, the SB 30 utilizes intermediate infrastructure layers and integration services. This allows, for example, business logic to be implemented as an EJB and hosted in a scalable application server to deploy as a set of WSs.

  Technology and implementation details can be hidden to deploy or use WS. SB30 provides “technology isolation” with separation and abstraction facilities based on standards, XML data reduction, common networking, and so on. These facilities work together to map and convert between the actual implementation and the abstract WS representation. For example, a SOAP message can be converted to a method call on an EJB object, and the result can be expressed and returned as XML generated according to some agreed upon schema. In order to make the SB 30 readable, a visual tool can be used to make the conversion to WS smooth and linear. Tools are still provided after the transition occurs. This is because they can be used for new WS deployments.

  The tool is easy to use and intuitive, and relies heavily on the automated deployment and integration facilities provided by SB30. For example, in order to develop an EJB object as a WS, it may be required to browse the visual web representation (page) of the object and publish it as a WS right from its registration and web page. The rest of the process is automatically performed by the SB deployment facility based on the OO model of the EJB object and its attributes. To subscribe to WS, the user can visually search or browse registration information, select the required service and select a subscription for it. The request is passed to the SB integration facility, which queries UDDI and then WSDL to form the appropriate OO model for WS and register it in the catalog.

  One example of a core of a WS broker (SB 30) according to one embodiment of the present invention is shown in FIG. The SB 30 can include the following main components: unification / cooperation / linkage layer (integration) 40, web service layer (universalization) 42, WS deployment tool 44, WS integration tool 46, WS management tool 48 mag. Each component will be described in more detail.

  The unification / cooperation / linkage layer 40 hosts a unified OO model of a specific technology and implementation (for example, relational DB, mainframe green screen, EJB object, etc.), and the unified OO model and a specific technology or language. Mapping (binding) to and from (to and / or from languages like C ++, Java or technologies like ODBC), coordinating execution and environment context between activities in specific technologies, implementations and platforms (For example, cross-border control across relational DB and CICS, or subscription for events originating from EJB containers in C ++ code), sub-infrastructure (EJB, COM or CORB The such) as responsible for coordination to a single point of access and control.

  The web service layer 42 is responsible for abstracting the unified OO model hosted at layer 40 as a WS and separating them from any technology and implementation details. Layer 42 performs all standard WS operations such as registration, publishing, discovery, subscription and use. The web service layer 42 includes various facilities that form a generalization layer. The facilities that make up the generalization layer include a registration / discovery facility 50, a publish / process facility 52, a subscription / call facility 54, an XML data organization facility 56, and a web communication facility 58.

  The registration / discovery facility 50 implements an automated procedure for registering a component (both data and logic) represented by a universal OO model as a WS and / or finds a WS according to supplied selection criteria. The facility 50 contacts the SR 12 using SOAP over HTTP, generates and submits an appropriate UDDI document or runs a select query and queries the UDDI document describing the WS. Facility 50 also implements procedures for changing registration information, maintaining business-related entries, canceling registration entries, and resubmitting to another SR repository. The facility 50 also maintains a replica (catalog) of all registration entries and relationships to the original OO model of the component in the registration database (not shown).

  The publish / process facility 52 generates a WS technology description (eg, WSDL) and uses the web communication facility 58 to make the WS interface available for access. For example, the facility 52 allows an Internet client to register a SOAP listener for a URL to represent WS. Facility 52 is also capable of accepting requests and initiating necessary activities (request processing) in WS's original OO model hosted at the integration layer. Facility 52 uses XML data organization facility 56 to properly represent the data for each side.

  Subscription / call facility 54 queries technical details about WS (eg, WSDL), forms a unified OO model for it, and uses it as one of the assets available to integration layer 40. I will let you. The facility 54 then causes the activity associated with the WS OO model to be converted into an actual external WS call according to the WSDL description. Facility 54 uses XML data reduction facility 56 to convert the data to and from XML and OO representations, which uses web communication facility 58 to propagate the request to the external WS and receive the response. It should be noted that the integration layer performs the actual binding of the integrated (subscribed) WS for a particular technology or language. Depending on the target application, the integration layer 40 can form static or dynamic bindings to the WS unified OO model.

  The XML data organization facility 56 is used to abstract the OO data model and data types in XML. Facility 56 provides bi-directional conversion between the unified OO model used by the integration layer and the universal XML data representation. Facility 56 also transcodes data element relationships appropriately. For example, the facility 56 can represent one object containing another object as a nested element in XML. The XML data organization facility 56 supports multiple standards representing data schemas and data types. Facility 56 is also used for template-based data organization (mapping) using the XSL transformation language, which is the standard for that purpose.

  The web communication facility 58 encapsulates connectivity and messaging technologies applicable to ordinary networking (eg, web). The facility 58 ensures the security of the communication channel, such as guaranteed delivery of messages, non-reputability. Some public standards that are incorporated and supported are HTTP, FTP, SMTP, SSL, X. 509, including XSIG. Additional commonly used communication mechanisms such as MQ Series, MSMQ, WAP, etc. can also be provided.

  The tool can include a WS deployment tool 44 that observes, browses, selects and makes them available as WSs hosted in the integration layer (data and logic). Visual tool (web-based GUI). By default, the tool 44 automatically deploys WS with the most appropriate parameters, but also allows for the application of specific conditions including published interface selection, communication channel security, paging protocol type, etc. To do. The WS deployment tool 44 uses a publish / process facility 52 and a registration / discovery facility 50. The WS deployment tool 44 can also be used to modify WS parameters and cancel the WS at runtime.

  Another tool, the WS integration tool 46, is a visual process implementation such as a wizard that allows WS discovery based on certain criteria, subscription to the selected WS. Tool 46 displays the details necessary to select the appropriate service when discovering WS and shows the last asset (OO model) hosted in the integration layer after subscribing to WS. The WS integration tool 46 can use a registration / discovery facility 50 and a subscription / call facility 54.

  Another tool, the WS management tool 48, is a WS management console (WSMC). The tool contacts the publish / process facility 52 and subscription / call facility 54 to query runtime details about the deployed and integrated WS. Tool 48 uses registration / discovery facility 50 to monitor SR 12. General runtime information about WS and SR12 is displayed by WSMC. The tool 48 also generates QoS analysis reports for specific deployed or integrated WS and SR repositories.

  Other responsibilities of WSMC are typically maintained by the registration / discovery facility 50 to register business entries, register basic business services and information, move entries from one SR repository to another, etc. Display and edit registration database of business entries and WS templates (UDDI related).

  Another service that SB 30 may perform is web service aggregation and assembly. It is not required to implement WS with a specific technology or language. When a transition occurs for a new IT paradigm for services based on universally interfaced networks, it turns out that most of the components required for a business process are already readily available. And all that is needed is to connect and coordinate between them and provide (realize) value-added services when necessary. This process can be referred to as WS aggregation and assembly. This is a high-level process that does not necessarily require knowledge of any particular technology or language, but relies on knowledge of business processes and business component relationships.

  In addition to brokering or brokering between a particular implementation and an abstract WS representation, the WS broker can take on the functions of new WS aggregation and assembly from selected existing ones. To do this, the external WS is integrated into a convenient OO model that can be easily handled. This can be done with the help of the WS integration tool 46. A modeling tool can be used to define an aggregated WSOO model and lay out an execution sequence involving an integrated external WS component OO model. There may be multiple execution sequences associated with the aggregated WS activity, each activity being a workflow and defined in workflow terms using an appropriate visual tool. The integration layer 40 can host the aggregated WSOO model and workflow sequence. The dynamic web service deployment facility can be used to automatically deploy an aggregated WS. If aggregated WS is used, the process execution runtime can execute the appropriate workflow sequence and invoke an integrated external WS if necessary (via their OO model). ).

  It should be noted that there may still be a need to move forward in the core functions of SB applied in connection with assembly and assembly. For example, a person provides a new value-added WS based on a hardware security transcoder and assembles it along with other existing external WS (account DB or certification authority) into a new fast authentication WS There is a case.

  FIG. 5 is a block diagram of the web service broker architecture (aggregation and assembly). WS assembly and assembly introduces three components into the core of SB30. These components include a component / process modeling tool (UML) 60, a process execution runtime (workflow-like) 62, and a dynamic web service deployment facility 64.

  The Component / Process Modeling Tool (UML) 60 is a visual tool for defining OO models and processing sequences by drawing OO component diagrams and relationship maps. It can be, for example, a UML based modeling tool that incorporates an OO component model and interfaces to the integration layer 40 to develop the final assembled OO model and processing sequence. This tool can also be used to deimport the assembled OO model, edit and modify it, and then reflect the changes to the integration layer 40.

  The process execution runtime 62 takes process sequences from the aggregated OO models hosted at the integration layer 40 and executes them in the appropriate context and order. Process 62 synchronizes and schedules its execution to implement the originally designed relationship in component / process modeling tool 60.

  The dynamic web service deployment facility 64 automatically deploys an aggregated OO model composed of new service components as a WS. Facility 64 implements a default deployment process for which WS deployment tool 44 (FIG. 4) would otherwise be used, but in this case decisions regarding having the OO component as WS are aggregated. It is based on dynamic recognition of an OO model (hosted by the integration layer 40) that is originally designed as a WS. The facility 64 can modify the WS that has already been deployed and aggregated if the associated OO model changes (eg, by a modeling tool).

  FIG. 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 to be universally interoperable business components or web services. Show. CCB 200 also provides a web service (WS) platform and implementation-neutral model driven structure.

  Some examples of application scenarios to which CCB 200 can be applied are where a new WS may be the desired public if the existing product benefits from integrating with an external WS (eg, NET Health Calendar Service). When it is to be constructed according to the service contract, for example: Includes enabling existing products for WS platforms such as NET or J2EE / JAXP environments. In general, over the years, there is a probability that many business automation systems, user interface devices, and development tools will be WS enabled. However, it is currently desirable to enable existing technologies and products for universal interoperability as WS. CCB 200 addresses this need with packaged engines and tools that are not tied to a particular platform and do not require application servers or other products to run.

  The CCB 200 can use open source technology. For example, the CCB 200 can use Apache Axis as a common SOAP protocol stack, and may use Apache Tomcat to implement HTTP communication or the like.

  FIG. 7 shows a diagram of the CCB 200 architecture. The web service broker core 202 maintains a pool of published and subscribed WSs. The published WS can be used to implement the actual service implementation either directly (eg, in the case of Java classes, etc.) or via, for example, Advantage IS integration (eg, for broader OO encapsulation and C ++ implementations). Dynamically enabled at runtime by the call processor mapped to the The subscribed WS is mapped into a dynamic proxy that can run at runtime, and the client-side static proxy can be called using, for example, Java rmi.

  The following components can be included in the CCB 200 to implement various aspects of the present invention. The publishing core 204 processes requests across Internet protocols, invokes the actual service implementation, and generates a WS description. The publishing core 204 can also include a set of well-defined APIs and repository data models. The publishing core 204 can handle transaction sets, data connections, security, and other details. This publishing core can implement call plug-ins for Advantage IS objects, Java classes, and the like.

  The registration core 206 can register the WS in the public / company service registry and maintain and synchronize the registration information in the repository 208 and in the service registry 12.

  Subscription core 210 finds WS in public service registry, queries WS description, binds subscribed WS to language implementation (eg, Java) and generates request via Internet protocol To the subscribed WS. Subscription core 210 may also include a set of well-defined APIs to handle transactions, security, and other details. Binding a subscribed WS may generate a client proxy in a Java or Advantage IS connector.

  The security core 212 may be a security system such as an eTrust WAC client that integrates with the publishing core 204, the subscription core 210, and the registration core 206 to perform an authentication / authorization procedure.

  The repository 208 can be an SQL database and can include an object-to-relational mapper implemented, for example, as an Advantage IS connector. The repository 208 is capable of maintaining and organizing information about published and subscribed services, transactions and communication logs, system configuration parameters, and the like. The repository 208 can also function as the main control center for the CCB 200. For example, an application can simply drop a new service implementation descriptor object into the repository 208 for deployment and activate WS. CCB 200 can then pick up the event from repository 208.

  Web Access Control (WAC) 214 can be a security system such as eTrust to provide an authorization and authentication server based on a centralized policy. The WAC 214 can use the LDAP directory as a repository of user / group identities. The WAC 214 provides a management tool for security policy management and user / group creation / deletion.

  Use enterprise application integration layer 216 such as Advantage Integration Server to unify data sources and provide transaction / connection collection, event management, object caching, load balancing, messaging, wrap C ++ service implementation, etc. Is possible.

  Java 218 can run 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 mapped or wrapped by a C ++ or Java skeleton. The external product 219 can also consume (use) the client proxy generated for the subscribed web service.

  The basic web GUI 220 can be a web-based user interface, which browses service implementations (eg, Java or Advanced IS) and selects selected implementations (eg, publishing GUI). It is possible to publish the WS that it has. GUI 220 also lists currently published and subscribed services, modifies their execution / registration parameters at runtime, monitors current transactions, analyzes communication logs, displays performance graphs, etc. (E.g., management and configuration GUI). The global configuration can include service registration specifications, business / category registration, network proxy information, and the like.

  The subscription extension GUI 222 can be provided as a wizard-like user interface process that allows to query the public / company service registry for a particular WS. The system can generate Java classes or EJB proxies, which encapsulate WS for client use. The system may also allow the client WS proxy to be used, for example as an Advantage IS object, for binding to C ++ or VB or other languages, for example.

  The service contract designer 224 can take a UML (or UML-like) model of a service contract (represented by a data structure and interface) and create a WS definition (eg, WSDL). This WSDL definition can be used as a vertical WS standard for any particular subject area. WSDL can be submitted against standard bodies. The designer can generate an implementation skeleton in Java or C ++ that matches the original service contract.

  The invention can be conveniently implemented using one or more conventional general purpose digital computers and / or servers programmed in accordance with the teachings of the present disclosure. The appropriate software coding can be adjusted by skilled programmers based on the teachings of the present disclosure. The present invention can also be realized by adjusting application specific integrated circuits or by interconnecting appropriate networks of conventional component circuits.

  Numerous additional modifications and variations of the present invention are possible in light of these teachings.

The block diagram which showed one example of the independent business interaction. The block diagram which showed the web service concept. The block diagram which showed the web service concept which has a service broker. Block diagram showing the web service broker architecture. 1 is a block diagram illustrating a web service broker architecture for aggregation and assembly. 1 is a block diagram showing an example of a computer system capable of realizing an embodiment of the present invention. The block diagram which showed an example of another Example of a web service broker.

Claims (12)

In the web service broker method,
Providing an interface between an enterprise and at least one of a service client and a service provider, wherein the service client discovers a web service on a service registry and uses a corresponding web service from the service provider;
Communicating between the enterprise and at least one of the service client and service provider;
(A) converting information from or to the enterprise into a form suitable for at least one of the service client and service provider; and (b) of the service client and service provider. Performing at least one of converting information from or to at least one into a form suitable for the enterprise;
A web service broker method that encompasses that.   2. The web service broker according to claim 1, wherein the enterprise includes a software product.   3. The web service broker of claim 2, wherein the web service broker is provided to enable the software product to a web service platform.   4. The web service platform according to claim 3, wherein the web service platform is. A web service broker having at least one of NET and J2EE / JAXP. In a computer recording medium containing code executable by a computer for implementing a web service broker,
Code that provides an interface between an enterprise and at least one of a service client and a service provider, wherein the service client discovers a web service on a service registry and uses the corresponding web service from the service provider;
Code for communicating between the enterprise and at least one of the service client and service provider;
(A) converting information from or to the enterprise into a form suitable for at least one of the service client and service provider; and (b) of the service client and service provider. Code for performing at least one of converting information from or to at least one into a form suitable for said enterprise
A computer recording medium.   6. The computer recording medium according to claim 5, wherein the enterprise has a software product.   7. The computer storage medium of claim 6, wherein the web service broker is provided for enabling the software product to a web service platform.   8. The web service platform according to claim 7, wherein the web service platform is. A computer recording medium having at least one of NET and J2EE / JAXP. In a programmed computer system for implementing a web service broker method,
Providing an interface between an enterprise and at least one of a service client and a service provider, wherein the service client discovers a web service on a service registry and uses a corresponding web service from the service provider;
Communicating between the enterprise and at least one of a service client and a service provider;
(A) converting information from or to the enterprise into a form suitable for at least one of the service client and service provider; and (b) of the service client and service provider. Performing at least one of converting information from or to at least one into a form suitable for the enterprise;
A programmed computer system that encompasses that.   10. A programmed computer system according to claim 9, wherein the enterprise comprises a software product.   11. The programmed computer system of claim 10, wherein the web service broker is provided to enable the software product to a web service platform.   12. The web service platform according to claim 11, wherein the web service platform is. A programmed computer system having at least one of NET and J2EE / JAXP.