Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q30/00—Commerce
  • G06Q30/02—Marketing; Price estimation or determination; Fundraising

Definitions

• the present disclosure relates to web services and, in particular, to a web services broker.
• a web service broker method comprises providing an interface between an enterprise and at least one of a service client and a service provider, the service client discovering web services on a service registry and using corresponding web services from the service provider, communicating between the ente ⁇ rise and the at least one of the service client and the service provider and performing at least one of a) converting information from/to the ente ⁇ rise to a form appropriate for the at least one of the service client and the service provider and b) converting information from/to the at least one of the service client and the service provider to a form appropriate for. the ente ⁇ rise.
• a computer recording medium includes computer executable code for implementing a web service broker.
• the computer recording medium comprises code for providing an interface between an ente ⁇ rise and at least one of a service client and a service provider, the service client discovering web services on a service registry and using corresponding web services from the service provider, code for communicating between the ente ⁇ rise and the at least one of the service client and the service provider and code for performing at least one of a) converting infonnation from/to the ente ⁇ rise to a form appropriate for the at least one of the service client and the service provider and b) converting information from/to the at least one of the service client and the service provider to a form appropriate for the ente ⁇ rise.
• a programmed computer system for performing a web service broker method comprises providing an interface between an ente ⁇ rise and'at least one of a service client and a service provider, the service client discovering web services on a service registry and using corresponding web services from the service provider, communicating between the ente ⁇ rise and the at least one of the service client and the service provider and performing at least one of a) converting infonnation from/to the ente ⁇ rise to a form appropriate for the at least one of the service client and the service provider and b) converting information from/to the at least one of . the service client and the service provider to a form appropriate for the ente ⁇ rise.
• Figure 1 is a block diagram of an example of independent business interaction
• Figure 2 is a block diagram of a Web Services concept
• Figure 3 is a block diagram of a Web Services concept with a Service Broker
• Figure 4 is a block diagram of a Web Services Broker Architecture
• Figure 5 is a block diagram of a Web Services Broker Architecture for aggregation and assembly
• Figure 6 is a block diagram of an example of a computer system capable of implementing embodiments of the present disclosure.
• Figure 7 is a block diagram of an example of another embodiment of a web services broker.
• Figure 6 shows an example of a computer system which may implement the method and system of the present disclosure.
• the system and method of the present disclosure may be implemented in the form of a software application running on a computer system, for example, a mainframe, personal computer (PC), handheld computer, server etc.
• the software application may be stored on a recording media locally accessible by the computer system, for example, floppy disk, compact disk, hard disk, etc., or may be remote from the computer system and accessible via a hard wired or wireless connection to a network, for example, a local area network, or the Internet.
• system 100 may include a central processing unit (CPU) 102, memory 104, for example, Random Access Memory (RAM), a printer interface 106, a display unit 108, a (LAN) local 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, for example, a keyboard, mouse etc.
• CPU central processing unit
• RAM Random Access Memory
• printer interface 106 for example, a printer interface 106
• display unit 108 for example, a printer interface 106
• display unit 108 for example, a (LAN) local 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, for example, a keyboard, mouse etc.
• LAN local area network data transmission controller
• LAN interface 112 a local area network data transmission controller
• network controller 114 for example, a keyboard, mouse etc.
• input devices 118 for example, a keyboard, mouse etc.
• Web Services refers to commonplace networking (from LANs to Wireless) and “Services” refers to electronic interfaces into distributed applications.
• Web Services are programmatic interfaces to electronic business systems that are defined and operate based on various industry standards including, for example, XML-based standards, ensuring interoperability.
• Each WS has a contract including a technical contract and a business contract.
• the technical contract defines operations and data types used to carry out those operations.
• the technical contract also defines protocols and appropriate communication modes.
• the business contract defines business-related metadata around the service. For example, category or taxonomy, support phone number, Service Level Agreements, licensing model, etc.
• Examples of Web Services may include a stock quote accessible with a Universal Resource Locator (URL), a product catalog published on the Internet, a Simple Mail Transfer Protocol (SMTP) message channel, a Simple Object Access Protocol (SOAP) based authentication agent, a CORBA object, etc. All of these are network-accessible components that implement certain functionality. If appropriately described and marshaled, any of the above components can be discovered, used and aggregated into, for example, a dynamic business automation system.
• URL Universal Resource Locator
• SMTP Simple Mail Transfer Protocol
• SOAP Simple Object Access Protocol
• IT information technology
• client-server programming client-server programming
• object-oriented component models object-oriented component models.
• service-based distributed applications dynamically discover, use and contract each other.
• these applications are dynamically "assembled” from distributed (and largely independent) parts (services) at runtime to achieve a certain goal. They can be assembled according to a defined criteria (for example, "fastest way to get it done") and they can dynamically reconfigure at runtime if, for instance, one of the services does not meet a quality requirement.
• User interfaces and interaction devices are also going to change.
• User interfaces can be built to work in the WS environment so that they can discover and invoke services according to user actions.
• Interaction devices can provide support with appropriate hardware, software and communication infrastructure.
• Figure 1 depicts an example of a collaboration of independent businesses interacting with each other to display, on a screen of a wireless device 1, a list of preferred restaurants that are near the user's current location.
• each business does what it does best.
• the Wireless Communication and Geo Positioning Services 2 are provided by a communication infrastructure company for performing certain services including determining a geographic position of the wireless user.
• Infonnation Portal 4 maintains user profiles and formats the infonnation in a preferred way.
• Map Database Service 6 translates the geographic position of the wireless user into addresses and provides information including the proximity of the user to restaurants.
• Restaurant Guide 8 provides information including restaurant descriptions and rankings.
• Web Services 10 provide the framework for this dynamic business process and user interaction to take place without creating static B2B relationships or tightly coupled technological implementation.
• Web Services is a public standards-based approach, and it has become possible to start globalizing e-business systems to that extent. To this end, several public organizations have been created, where the joint effort of several industry leaders has resulted in a set of standards like XML, UDDI, WSDL, etc. (as well as legacy standards like HTTP, TCP/IP, etc.)
• WS combines multiple, largely unrelated, standards, organizations, software and hardware infrastructure builders into one global unbiased framework. It thus becomes possible to create collaborating electronic business systems in a meaningful way. That is, it does not require proprietary agreements and tight integration of the automation systems for two parties to collaborate electronically.
• WS creates an environment to register services in a very generic and descriptive way, yet it is comprehensive and IT-enabled. It also makes services available (e.g., publish it). It also allows services to be found (wherever they may be), interrogate details needed to use it and make the service an asset (discover/subscribe on it). Subscription may also sometimes be referred to as binding to a service. WS also allows the use of the service (invoking the service).
• WS are platform, programming language, vendor, technology and implementation model agnostic. WS are dynamically discovered, contracted with, bound to, and invoked. WS are loosely coupled, universally marshaled and decentralized. WS also can interact via commonplace networking using coarse-grained messaging. This means no dependency on the evolution of communication infrastructure. In addition, it is ubiquitous. There are no significant performance concerns due to the amount of infonnation being exchanged in one fragment and granularity of the seivices. Now, more specifically, the relationships between each of the elements (and their roles) for providing a successful WS environment are depicted in Figure 2. The elements include public, global and independent Service Registry (SR) 12, Service Providers (SP) 14 and Service Clients (SC) 16. Service Providers 14 register their services with Service Registry 12. Service Clients 16 can then discover and use those services.
• SR Service Registry
• SP Service Providers
• SC Service Clients
• WS is based on XML descriptions and messaging in the commonplace-networking environment.
• XML is a very general way to make information universal for Internet-era deployment.
• WS is a framework of XML-based standards that have special meaning and address certain areas. These areas and some of the standards for each include Service Registration (for registering with SR 12): UDDI (Universal Discovery, Description and Integration), Service Description: WSDL (Web Services Description Language), Service Advertisement: ADS (Advertisement and Discovery of Services), Service Addressing: URL (Universal Resource Locator), J DI name, specific LAN (Local Area Network) address, etc., Service Invocation: SOAP (Simple Object Access Protocol), URL with parameters, WebDAV, etc..
• UDDI Universal Discovery, Description and Integration
• Service Description WSDL (Web Services Description Language)
• Service Advertisement ADS (Advertisement and Discovery of Services)
• Service Addressing URL (Universal Resource Locator), J DI name, specific LAN (Local Area Network
• XML Extensible Markup Language
• 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 HTTP (HyperText Transfer Protocol), FTP (File Transfer Protocol) and SMTP (Simple Message Transfer Protocol), other: MQ Series, WAP, etc.
• Common Security SSL (Secure Services Layer), X.509 (Digital Certificates), XSIG (XML Signature), etc.
• Common Networking TCP/IP (Transport Communication Protocol/Internet Protocol), DNS (Domain Name Service), etc.
• UDDI is used to communicate to SR 12 which holds business contracts for multiple services.
• SR 12 can be setup on a co ⁇ orate/department level and/or be a public registry.
• WSDL is used to express the technical contract for a service.
• WSDL defines operations, refers to data type definitions and specifies protocols and communication details for a service.
• XML schema is used to define hierarchical data types used in service operations. XML holds values in SOAP messages between a client and a service. XML contents are according to XML Schema.
• HTTP and TCP/IP is used to carry the messages between parties. HTTP is a primary, ubiquitous communication method for WS.
• WS brings these together and adds new standards and concepts to create a framework for flexible, distributed applications and services.
• WS is also a very flexible environment. For example, new communication protocols may be introduced without necessarily changing services and their applications.
• WS applications are isolated well enough from the specifics to allow the underlying infrastructure to evolve.
• WS does not standardize what seivices would or could do and how. Instead, WS provides a way to describe, publish and use the services.
• WS applications operate in a certain way to provide user services. This operation is a part of the WS framework. The operation includes carrying out registration, publishing, discovery/subscription and invocation of a service.
• WS interact with the at least one SR 12 over the HTTP (with or without SSL) using Simple Object Access Protocol (SOAP), which is an XML messaging protocol.
• SOAP is an envelope definition that holds requests and replies between a client and a service.
• UDDI Universal Discovery, Description and Integration
• UDDI documents describe businesses and their services (electronic or not). Each business can maintain a registration entry with SR 12 that consists of a UDDI document hierarchy.
• the hierarchy may include White Pages which define the business identity; Yellow Pages which categorize business aspects (like business taxonomy, serviced part D-U-N-S numbers, etc.); and Green Pages which describe technical details of the WS (service binding template). Green Pages may refer to the service directly (like a URL of a parts catalog) or embed/refer to a more detailed specification of WS interfaces, data types, security constraints, etc.
• SR 12 may be global, being replicated across several repositories. Examples of global SRs include uddi.microsoft.com or uddi.ibm.com. SR 12 may also be shared within a company or among several participants via, for example, a delegated or private repository.
• the Service Provider (SP) 14 submits appropriate UDDI entries using SOAP UDDI APIs to the SR 12.
• the submission may also include WSDL information and/or a reference to WSDL infonnation in the form of, for example, a URL.
• Registration is a static step in the sense that once information is submitted to SRI 2, the SR 12 maintains the information.
• entries may be changed, revoked and/or resubmitted, the SR 12 does not generally dynamically request any changes, revocations, resubmissions, etc. from the registrant when, for example, a SC 16 runs a query to discover services.
• SC 16 retrieves UDDI documents by using SOAP UDDI APIs to request the information from the SR 12.
• the SC 16 may include selection criteria in the requests for retrieving records about desired businesses and their services.
• SR 12 runs an appropriate query against its registration repository to find any suitable registered businesses and their services. Discovery is a dynamic process.
• SP 14 When publishing, SP 14 makes its interfaces available to connect or communicate to. For example, SP 14 may start listening for SOAP requests on a certain URL. At this point, SP 14 may also make WSDL infonnation available if, for example, it was referenced in the UDDI entry earlier during registration. WSDL may be dynamically generated depending on current WS parameters like, for example, a communication protocol that needs to be used, etc. This is a dynamic process. Service may be disabled, enabled and reconfigured at any time. SC 16 may intelligently react to this by, for example, switching to another available service, using a different communication protocol, marshalling data accordingly, etc.).
• SC 16 When subscribing (binding), SC 16 inte ⁇ rets the WS description using information in the UDDI and the WSDL documents when available. SC 16 creates necessary interface representation, data marshalling stack, communication pipe, authentication realm, etc. which may be used for service invocation. Subscription is generally a dynamic, reconfigurable process, but it may also become static, if, for example, tight language or technology integration is required.
• SC 16 When invoking, SC 16 chooses a WS interface, builds necessary parameters, makes a call and then inte ⁇ rets a result. This is very similar to invoking a method on an 00 (Object Oriented) component. In certain cases, such as tight language-to-WS binding, it may be an OO component invocation. The difference is, though, in the process of flexible, Web-ready communication, data marshalling, authentication, etc., details of which would usually be hidden from the usage pattern.
• 00 Object Oriented
• the types of WS may vary and may generally be qualified into three different types, depending on the control and data flow that defines their operations. Usually one e-business would have a mix of different types of WS depending on the pu ⁇ ose they serve.
• WS One type of WS would be an Information Source. For example, A publishes information at a certain address and makes changes to it, B subscribes to the information source, retrieves content and pools for changes. In this case, A is passive and B is active. Data flows from A to B.
• WS might be a Messaging Queue. For example, A establishes an incoming communication channel at a certain address, B establishes an outgoing communication channel and pushes infonnation into it, A listens and accepts information from the channel. In this case A is passive and B is active, data flows from B to A.
• WS might be a Component Service.
• A exposes a set of interfaces at a certain address and implements processing of requests made to those interfaces, B invokes interfaces, passes and receives information in requests and replies.
• B is active, data flow is bi-directional.
• Any kind of collaborative e-business automation system can be built using WS of the three types listed above. It would be sufficient to have these types of WS types to cover any type of Web collaboration.
• the WS environment is an efficient and versatile framework for electronic collaboration of all kinds.
• it should be related to existing technologies, infrastructures, business processes, etc. This is particularly true since it can be said that this is the beginning of this IT evolution cycle, of laying the foundation and putting the technology framework in place.
• a system should leverage accumulated knowledge, reuse and extend existing systems to bring them to the next level of deployment, which will make them more universal.
• SB Service Broker
• FIG. 3 depicts a Service Broker applied to the WS concept described above with respect to Figure 2.
• the Service Broker (SB) 30 is the WS platform for IT-enabled ente ⁇ rises 32.
• SB 30 analyzes a service implementation model and automatically creates technical and business contracts that comply to the above-noted standards.
• SB 30 submits business contracts to the SR 12 of choice and then listens to SOAP requests, processes the SOAP requests and relays calls to the actual implementation in, for example, Java or C++.
• SB 30 may perform many different functions and roles.
• the SB 30 may provide a technology foundation for WS activities. This might include a Web communication layer, XML data marshalling, SOAP request processor, UDDI communication APIs, WSDL binding, etc.
• the SB 30 may integrate ente ⁇ rise technologies to (1) unify OO models for data and logic, (2) coordinate between separate technologies, (3) federate sub-infrastructures (like EJB or CORBA).
• SB 30 may also provide tools and facilities for deploying existing (integrated) systems, parts and components as WS. This might include registration of a WS, publishing it, accepting invocation requests and translating all that back into original implementation activities.
• SB 30 may also integrate external WS to discover WS in the SR 12 and subscribe to the WS.
• SB 30 may also provide tools and facilities for WS aggregation. This may include integration of WS, representing them in the common process component model, a process modeling tool (e.g., UML), a coordinated process execution runtime (Workflow-like) and dynamic WS deployment facility. SB 30 may also provide a WS Management Console (WSMC).
• WSMC WS Management Console
• the WSMC might incoiporate a set of tools needed to define and submit/change UDDI entries, maintain local registration replica and common business information, redeploy (move) entries from one SR repository to another, include and exclude services, configure communication protocols, impose security, etc.
• the SB 30 may also provide selective logging and quality of service (QoS) analysis.
• QoS quality of service
• SB 30 utilizes an intermediate infrastructure layer and integrated services. This allows, for instance, business logic implemented as EJBs and hosted in a scalable Application Server to be deployed as a set of WS.
• SB 30 provides "technology insulation” with isolation and abstraction facilities that are based on standards, XML data marshalling, common networking, etc. These facilities coordinate, map and translate between actual implementation and abstract WS representation. For instance, a SOAP message may be translated into a method call on an EJB object, and the result can then be represented and returned as XML generated according to certain agreed schema.
• the SB 30 may include the following main components, Unification, Coordination and Federation Layer (Integration) 40, Web Services Layer (Universalization) 42, a WS Deployment Tool 44, a WS Integration Tool 46 and a WS Management Tool 48. Each component will now be described in more detail.
• the Unification, Coordination and Federation Layer 40 is responsible for hosting a unified OO model of specific technologies and implementation (e.g., relational DB or mainframe green screens or an EJB object, etc.); mapping (binding) between unified OO model and specific technology or language (to and from languages like C++, Java, or technologies like ODBC); coordinating execution and environment context between activities in particular technologies, implementations and platforms (for instance, span transactional control across relational DB and CICS, or in C++ code subscribe to an event originating from an EJB container); and federating sub-infrastructures (like EJB, COM or CORBA) into one point of access and control.
• technologies and implementation e.g., relational DB or mainframe green screens or an EJB object, etc.
• mapping binding
• mapping between unified OO model and specific technology or language
• specific technology or language to and from languages like C++, Java, or technologies like ODBC
• the Web Services Layer 42 is responsible for abstraction of the unified OO models hosted in layer 40 as WS and isolating them from any technology and implementation details. Layer 42 carries out all standard WS operations such as registration, publishing, discovery, subscription and use.
• the Web Services Layer 42 includes various facilities that form a Universalization Layer.
• the facilities forming the Universalization Layer include Registration Discovery Facility 50, Publishing/Processing Facility 52, Subscription/Invocation Facility 54, XML Data Marshalling Facility 56 and Web Communication Facility 58.
• Registration/Discovery Facility 50 implements automated procedures for registering a component (both data and logic) represented by a universal OO model as a WS and/or finds WS according to supplied selection criteria.
• Facility 50 contacts the SR 12 using SOAP over the HTTP, generates and submits appropriate UDDI documents or runs a selection query and interrogates UDDI documents that describe the WS.
• Facility 50 also implements procedures for changing the registration information, maintaining business-related entries, revocation of registration entries and resubmitting to another SR repository.
• Facility 50 also maintains a replica (catalog) of all the registration entries and their relationships to the original OO model of components in a registration database (not shown).
• Publishing/Processing Facility 52 takes care of generating WS technical description (e.g., WSDL) and uses Web Communication Facility 58 to make WS interfaces available for access.
• Facility 52 might register a SOAP listener for a certain URL to represent WS to the Internet client.
• Facility 52 can also accept requests and initiate necessary activities (process requests) in the original OO model of the WS hosted in the Integration Layer.
• Facility 52 uses XML Data Marshalling Facility 56 to properly represent data for each side.
• Subscription/Invocation Facility 54 interrogates technical details about the WS (e.g., WSDL), creates a unified OO model for it and makes it one of the assets available to the Integration Layer 40. Facility 54 then translates activities related to the WS OO model into actual external WS invocation according to the WSDL description. Facility 54 uses XML Data Marshalling Facility 56 to convert data to and from XML and OO representation, and it uses Web Communication Facility 58 to propagate requests to the external WS and receive replies. It should be noted that the Integration Layer does the actual binding of the integrated (subscribed) WS to the particular technology or language. Depending on the target application, Integration Layer 40 can create static or dynamic binding to the unified OO model of the WS.
• WSDL Technical details about the WS
• Facility 54 then translates activities related to the WS OO model into actual external WS invocation according to the WSDL description.
• Facility 54 uses XML Data Marshalling Facility 56 to convert data to and from XML and OO representation, and it uses
• XML Data Marshalling Facility 56 is used to abstract OO data models and data types in XML. Facility 56 provides bi-directional translation 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, Facility 56 can represent an object that contains another object as nested elements in XML. XML Data Marshalling Facility 56 supports multiple standards that represent data schemas and data types. Facility 56 is also used for template-based data marshalling (mapping) using, XSL Transformations language, which is becoming standard for that pu ⁇ ose.
• Web Communication Facility 58 encapsulates connectivity and messaging technologies applicable to commonplace networking (e.g., the Web). Facility 58 ensures security of the communication channel, guaranteed delivery of messages, non-reputability, etc. Some public standards that are inco ⁇ orated and supported include HTTP, FTP, SMTP, SSL, X.509 and XSIG. Additional commonly used communication mechanisms may also be provided such as MQ Series, MSMQ, WAP, etc.
• the tools may include a WS Deployment Tool 44 which is a visual insfrument (Web- based GUI) to view, browse and select components (data and logic) hosted in the Integration Layer and to make them available as WS.
• Tool 44 deploys WS automatically with best suitable parameters, but also allows application of specific requirements including selection of published interfaces, security on the communication channel, type of invocation protocol, etc.
• WS Deployment Tool 44 uses Publishing/Processing facility 52 and Registration/Discovery Facility 50.
• WS Deployment Tool 44 may also be used to modify WS parameters at runtime and revoke WS.
• WS Integration Tool 46 is a Wizard-like visual process implementation that allows discovery of a WS according to certain criteria, and subscription to the selected WS.
• Tool 46 displays details needed to select an appropriate service when discovering WS and shows the final asset (OO model) hosted in the Integration Layer after subscribing to a WS.
• the WS Integration Tool 46 may use Registration/Discovery Facility 50 and Subscription/Invocation Facility 54.
• WS Management Tool 48 is the WS Management Console (WSMC). This tool contacts Publishing/Processing Facility 52 and Subscription/Invocation Facility 54 to inten-ogate runtime details about deployed and integrated WS. Tool 48 uses Registration Discovery Facility 50 to monitor the SR 12. Generic runtime infonnation about WS and SR 12 is displayed by WSMC. Tool 48 also generates QoS analysis reports for particular deployed or integrated WS and SR repository.
• WSMC WS Management Console
• Another responsibility of the WSMC is to display and edit the registration database of common business entries and WS templates (UDDI-related) that are maintained by the Registration/Discovery Facility 50 to register business entry, register basic business services and information, move entries from one SR repository to another, etc.
• UDDI-related common business entries and WS templates
• SB 30 Another service that SB 30 might perfonn is Web Services Aggregation and Assembly. It is not required to implement WS in a specific technology or language. As a transition occurs to the new IT paradigm of universally interfaced network based services, it will be found that most of the needed components for certain business process may already be readily available, and all it takes is to connect and coordinate between them and provide (implement) added value services where necessary. This process may be called WS Aggregation and Assembly. This is a high- level process that does not necessarily require knowledge of any particular technology or language, but rather, relies on knowledge of business process and business component relationships.
• the present WS Broker may take the function of aggregation and assembly of new WS from the selected existing ones.
• external WS are integrated into a convenient OO model that can be easily manipulated. This can be done with the help of the WS Integration Tool 46.
• a Modeling Tool can be used to define aggregated WS OO model and lay out the execution sequences involving OO models of the integrated external WS components. There can be multiple execution sequences associated with aggregated WS activities, with each one being a workflow and defined in workflow terms using appropriate visual tools.
• Integration Layer 40 may host the aggregated WS OO model and workflow sequences.
• a Dynamic Web Service Deployment Facility can be used to automatically deploy aggregated WS. When an aggregated WS is used, a process execution runtime can carry out appropriate workflow sequences and invokes, where necessary, integrated external WS (via their OO models).
• FIG. 5 is a block diagram of a Web Services Broker Architecture (Aggregation and Assembly).
• the WS Aggregation and Assembly introduces three components to the core of SB 30. These components include Component Process Modeling Tool (UML) 60, Process Execution Runtime (Workflow-like) 62 and Dynamic Web Service Deployment Facility 64.
• UML Component Process Modeling Tool
• UML Process Execution Runtime
• Dynamic Web Service Deployment Facility 64 Dynamic Web Service Deployment Facility
• the Component Process Modeling Tool (UML) 60 is a visual instrument to define OO models and processing sequences by drawing diagrams and relationship maps of OO components. It may be, for example, a UML-based modeling tool that interfaces to the Integration Layer 40 to inco ⁇ orate OO component models and deploy the final aggregated OO model and processing sequences. This tool may also be used to import back the aggregated OO model, edit and modify it, and then reflect changes to the Integration Layer 40.
• Process Execution Runtime 62 takes processing sequences from the aggregated OO model hosted in the Integration Layer 40 and executes them in appropriate context and order.
• Process 62 synchronizes and schedules the execution to implement relationships originally designed in the Component/Process Modeling Tool 60.
• Dynamic Web Service Deployment Facility 64 automatically deploys aggregated OO models of new service components as WS.
• Facility 64 implements default deployment processes that WS Deployment Tool 44(Fig. 4) would otherwise be used for, but in this case a decision about making an OO component a WS is based on dynamic recognition of the OO model (hosted by the Integration Layer 40) to be originally designed as an aggregated WS.
• Facility 64 is able to modify already deployed aggregated WS when the related OO model changes (for example, with a modeling tool).
• FIG. 7 depicts a Web Services Broker (WSB) as a Common Component, referred to generally as Common Component Broker (CCB) 200 that enables existing products and technologies as universally interoperable business components or Web Services.
• CCB 200 also offers platform and implementation neutral model-driven construction of the Web Services
• Examples of some of the application " scenarios for which CCB 200 would be applicable include enabling an existing product for a WS platform such as, for example, .NET or J2EE/.I AXP environment; when an existing product will benefit from integrating with external WS (e.g. .NET Hailstonn Calendar service); when a new WS is to be constructed according to a desired Public Service Contract, etc.
• a WS platform such as, for example, .NET or J2EE/.I AXP environment
• external WS e.g.NET Hailstonn Calendar service
• CCB 200 addresses this need with packaged engines and tools that are not tied to any specific platform and do not require an application server or any other products to run.
• CCB 200 can make use of open source technologies.
• CCB 200 may make us of, Apache Axis as a common SOAP protocol stack, Apache Tomcat might be used to carry out the HTTP communication, etc.
• Figure 7 depicts a diagram of the architecture of the CCB 200.
• Web Services Broker Core 202 maintains a pool of published and subscribed WS. Published WS are dynamically enabled at runtime by call processors which are mapped into the actual service implementation either directly (e.g., for cases such as a Java class, etc.) or via, for example, Advantage IS integration (e.g., For more extensive OO encapsulation and for C++ implementations, etc,).
• the subscribed WS are mapped at runtime into operable dynamic proxies which client-side static proxies can call using, for example, Java RMI.
• Publishing core 204 processes requests over Internet protocols, invokes actual service implementation, generates WS descriptions.
• Publishing core 204 may also include a set of well-defined APIs and a repository data model.
• Publishing core 204 may take care of transaction aggregation, data connections, security and other details.
• the Publishing core may implement invocation plug-ins for Advantage IS objects, Java classes, etc.
• Registration core 206 may register WS in a public/co ⁇ orate service registry and may maintain and synchronizes the registration information in the repository 208 and in the service registry 12.
• Subscription core 210 can discover WS in a public service registry, interrogate WS description, bind subscribed WS to a language implementation (such as, for example, Java), generate and send requests over Internet protocols to the subscribed WS.
• Subscription core 210 may also include a set of well-defined APIs for taking care of transactions, security and other details. Binding a subscribed WS may generate a client proxy in Java or an Advantage IS connector.
• Security core 212 can be security system such as, for example, an eTrust WAC client that integrates with the Publishing core 204, Subscription core 210 and Registration core 206 to carry out authentication/authorization procedures. Security core 212 may also encrypt/decrypt and sign/verify messages if desired.
• Repository 208 may be an SQL database and may include an object-to-relational mapper implemented as, for example, an Advantage IS connector. Repository 208 may keep and organize infonnation about published and subscribed services, transaction and communication logs, system configuration parameters, etc. Repository 208 may also function as a main control center for the CCB 200. For example, an application can simply drop a new service implementation descriptor object into Repository 208 to deploy and activate a WS. CCB 200 can then pick the events up from the Repository 208.
• Web Access Control (WAC) 214 may be a security system such as eTrust for providing a centralized policy-based authorization and authentication server.
• WAC 214 may use an LDAP Directoiy as a repository of user/group identities.
• WAC 214 may provide administrative tools for security policy administration and creation/deletion of users/groups, etc.
• An Enteiprise Application Integration layer 216 such as an Advantage Integration Server may be utilized to unify data sources and provide transaction/connection aggregation, event management, object caching, load balancing, messaging, wrap C++ service implementations, etc.
• Java 218 may run CCB 200 and provide access to Web Service implementations in Java as well as host client proxies for the subscribed Web Services.
• External products 219 may provide service implementations mapped to/wrapped by C++ or Java skeletons. External products 219 may also consume (use) client proxies generated for subscribed Web Services.
• Basic Web GUI 220 may be a Web-based user interface that allows browsing for service implementation (e.g., Java or Advantage IS) and publishing a WS with a selected implementation (e.g., a Publishing GUI). GUI 220 may also allow listing currently published and subscribed services, modify their execution/registration parameters at runtime, monitor current transactions, analyze communication logs, display performance graphs, etc. (e.g., an Administration and Configuration GUI).
• Global configuration may include service registry specification, business/categories registration, network proxy information, etc.
• a Subscription Extension GUI 222 may be provided as a wizard-like user interface process that allows querying public/coiporate service registries for a specific WS.
• the system can then generate Java class or an EJB proxy that encapsulates a WS for the client use.
• the system may also be able to make the client WS proxy available as, for example, an Advantage IS object for binding to other languages such as C++ or VB, etc.
• a Service Contract Designer 224 can take a UML (or UML-like) model of a Service Contract (expressed in data structures and interfaces) and create a WS definition (e.g., WSDL).
• the WSDL definition can then be used as vertical WS standards for any particular subject area.
• WSDL can be submitted to standards bodies.
• a designer can then generate an implementation skeleton in Java or C++ that conforms to an original service contract.
• the present disclosure may be conveniently implemented using one or more conventional general purpose digital computers and/or servers programmed according to the teachings of the present disclosure.
• Appropriate software coding can be prepared by skilled programmers based on the teachings of the present disclosure.
• the present disclosure may also be implemented by the preparation of application specific integrated circuits or by interconnecting an appropriate network of conventional component circuits. Numerous additional modifications and variations of the present disclosure are possible in view of these teachings.

Applications Claiming Priority (3)

Publications (2)

Family

ID=36910761

Family Applications (1)

Country Status (3)

Citations (1)

• 2003
  • 2003-04-18 AU AU2003253597A patent/AU2003253597A1/en not_active Abandoned
  • 2003-04-18 BR BRPI0309392-1A patent/BR0309392A/pt unknown
  • 2003-05-19 EP EP03816940A patent/EP1535181A4/de not_active Withdrawn

Patent Citations (1)

Non-Patent Citations (3)

Also Published As

Similar Documents

Legal Events