Title of Invention	SYSTEM FOR MANAGING SERVICES
Abstract	A data processing system having at least a processor and accessible memory, the said system comprising: means adopted to receive a selection of a deployment domain (300); means adopted to receive an instruction to associate an object(510) with the deployment domain(300); means adopted to choose a method necessary to associate the object with the deployment domain(300); and means adopted to perform the method, characterized in that method is chosen according to pre-defined mappings of metadata(330) to an underlying platform.

Title of Invention

SYSTEM FOR MANAGING SERVICES

Abstract

A data processing system having at least a processor and accessible memory, the said system comprising: means adopted to receive a selection of a deployment domain (300); means adopted to receive an instruction to associate an object(510) with the deployment domain(300); means adopted to choose a method necessary to associate the object with the deployment domain(300); and means adopted to perform the method, characterized in that method is chosen according to pre-defined mappings of metadata(330) to an underlying platform.

Full Text	FORM 2 THE PATENTS ACT, 1970 (39 of 1970) & THE PATENTS RULES, 2003 COMPLETE SPECIFICATION (See section 10, rule 13) "SYS1TEM FOR MANAGING SERVICES" ELECTRONIC DATA SYSTEMS CORPORATION Of 5400 Legacy Drive, H3-3A-05, Piano, TX 75024, USA The following specification particularly describes the invention and the manner in which it is to be performed. Original 643./MUMNP/05 GARNTED 14-02-2007 TECHNICAL FIELD OF THE INVENTION The present invention is directed, in general, to data processing system services management. BACKGROUND OF THE INVENTION In the area of conventional business service 'development, there are, in general, three major roles, each role having specific tools to address its needs. Application architects are primarily concerned with defining the contracts of the business services to meet the business requirements. An application contract consists of one or more interface definitions, reflecting the right level of interface granularity and service behavior such as operations exposed and their inputs and outputs. An important aspect of the architect's task here is to ensure that existing interface types are reused so that multiple interface types and messages are not reinvented to fulfill similar requirements. Once the correct interfaces have been defined, the application developers are ready to implement those interfaces. This often involves writing code that implements business logic. The developers also have to be able to unit^test the code that they have just written. 2 Finally, once the code has been developed, it can be given to the system administrators for configuration, deployment and management. They can then configure the runtime execution environment for the newly developed service and deploy the application. Once deployed, the application can then be managed through the means available in the environment. In the conventional development model, the applications are developed from scratch. This allows the users to perform top-down design and leverage the full capabilities of the available technologies since no baggage needs to be carried from the past. Currently, there are 5 major phases of the lifecycle of the business services. In the model phase, the application architects design the interfaces for the business services to be developed. Once the interfaces have been designed, the business logic is developed by the developers of the system. The system architects then configure the runtime for the business service and the administrators then deploy and manage the business services. , In many cases, the business services already exist but are not manageable. These services may be either 3rd party off-the-shelf (COTS) applications or custom applications developed in-house or by system integrators. This style of development is bottom-up development where the interfaces are actually constructed based on existing applications. The architects first use introspection to rev.erse engineer metadata from the 3 existing applications. These applications may exist in. one of many supported technologies such as Java classes, CORBA, EJB's, existing web services or COTS packages such as SAP or Siebel. Introspection would result in one-to-one interface generation. However, in real world, these interfaces may need to be refactored. Refactoring involves either suppressing some of the operation in an interface, creating brand new ones, combining two or more interfaces (contract aggregation) or splitting a contract into two or more contracts (contract dissemination). It should be noted that the existing applications could also be web services. The process should however be no different than that for 3rd party COTS or custom applications supporting a particular technology. Business logic generally does not change in nature. However, the underlying technologies are changing very rapidly. For example, there are a number of new standards that are being developed to address various aspects of distributed business services. Many standards do not have any sort of industry consensus and many areas have competing standards. However, the applications have to be developed today. Typically, the business services are written to provide all the other necessary functionality, such as security and others (application infrastructure services) that do not actually contribute to the business behavior itself. As the standards and technologies for these other services (application infrastructure services) evolve, the business services have to be modified and enhanced in order to take advantage of them. Furthermore, in the current state of the art, the 4 configuration and deployment of these services is specific to a particular underlying environment and the underlying products. There is, therefore, a need in the art for an improved system and method for composing, configuring, deploying, and managing business services in a data processing system and data processing system network. 5 SUMMARY OF THE INVENTION To address the above-discussed deficiencies of the prior art, it is a primary object of the present invention to provide an improved system and method for business services development and management in a data processing system and data processing system network. The preferred embodiment provides a system and method for composing, configuring, deploying, and managing services in a data processing system and data processing system network. This system provides deployment domains to define a logical set of business services that have similar requirements for an application infrastructure. A deployment --domain is created, and a graphical user interface allows a user to compose, configure, deploy, and manage services within the deployment domain and associated hosts using a drag-and-drop interface. The foregoing has outlined rather broadly the features and technical advantages of the present invention so that those skilled in the art may better understand the detailed , description . of the invention that follows. Additional features and advantages of the invention will be described hereinafter that form the subject of the claims of the invention. Those skilled in the art will appreciate that they may readily use the conception and the specific embodiment disclosed as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. Those skilled in the art will also realize that such equivalent constructions do not depart from the spirit and scope of the invention in its broadest form. 6 Before undertaking the DETAILED DESCRIPTION OF THE INVENTION below, it may be advantageous to set forth definitions of certain words or phrases used throughout this patent document: the terms "include" and "comprise," as well as derivatives thereof, mean inclusion without limitation; the term "or" is inclusive, meaning and/or; the phrases "associated with" and "associated therewith," as well as derivatives thereof, may mean to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, or the like; and the term "controller" means any device, system or part thereof that controls at least one operation, whether such a device is implemented in hardware, firmware, software or some combination of at least two of the same. It should be noted that the functionality associated with any particular controller may be centralized or distributed, whether locally or remotely. Definitions for certain words and phrases are provided throughout this patent document, and those of ordinary skill in the art will understand that such definitions apply in many, if not most, instances to prior as well as future uses of such defined words and phrases. 7 BRIEF DESCRIPTION OF THE DRAWINGS For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, wherein like numbers designate like objects, and in which: FIGURE 1 depicts a block diagram of the relationships between service layers in accordance with a preferred embodiment of the present invention; FIGURE 2 depicts a block diagram relating a development and deployment lifecycle with data objects and service objects in accordance with a preferred embodiment of the present invention; FIGURE 3 depicts a block diagram of a runtime environment in accordance with a preferred embodiment of the present invention; FIGURE 4 illustrates a federated metadata storage and access system in accordance with a preferred embodiment of the present invention; FIGURE 5 depicts a virtual composition environment in accordance with a preferred embodiment of the present invention; FIGURE 6 depicts a block diagram of a virtual container accordance with a preferred embodiment of the present invention; and 8 DETAILED DESCRIPTION OF THE INVENTION FIGURES 1 through 7, discussed below, and the various embodiments used to describe the principles of the present invention in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the invention. Those skilled in the art will understand that the principles of the present invention may be implemented in any suitably arranged device. The numerous innovative teachings of the present application will be described with particular reference to the presently preferred embodiment. Definitions: Following are short definitions of the usual meanings of some of the technical terms which are used in the present application. (However, those of ordinary skill will recognize whether the context requires a different meaning.) Additional definitions can be found in the standard technical dictionaries and journals. Business Service Contract - A business service contract describes the business service exposed. This normally contains information such as operations provided by the service, their inputs and outputs. Business Service Implementation - A business service implementation is the software code required strictly to implement the above mentioned business behavior. This does not include other capabilities such as providing security or managing transactions. 9 Application Infrastructure Services - Application Infrastructure Services are all those services that themselves do not contribute to the business behavior, however they are necessary for the correct operation of the business service. These services can be added, removed or replaced without changing the business behavior of the business service. Virtual Container - A virtual container couples a business service implementation with one or more application infrastructure services and provides the definition for a complete business service. This definition exists in metadata and contains all the metadata that customizes the specific usage of application infrastructure services inside the said virtual container. Physical Business Service - A physical business service is the platform specific programming code that can be generated according to the previously discussed definition ' of the virtual container. This code can then be compiled and deployed in the underlying platform specific manner. Web Services will soon be providing complex and mission critical services to business partners and internal customers by providing a viable alternative to most application integration scenarios. 10 The disclosed embodiments provide a system and method for composing, configuring, deploying, and managing services in a data processing system and data processing system network. This system provides deployment domains to define a logical set of business services that have similar requirements for an application infrastructure. A deployment domain is created, and within it is contained a set of metadata that defines available hosts, application infrastructure services, and deployed business services. The metadata is managed by a federated metamodel system. A visual composition environment allows composition of a virtual container that couples the business service in question with the application level infrastructure services that it needs. The code generators can then generate platform specific code for the virtual, container. All this can be packaged for easy shipment. The packaged business services can then be easily deployed on any of the machines available to the system. The disclosed embodiments include a method and system for describing the underlying application services infrastructure, a virtual execution environment for business services implementations and a system to integrate the two in a loosely coupled way through metadata so that the two can evolve independently and still stay compatible. In the preferred embodiment, a deployment domain is created, and a graphical user interface allows a user to compose, configure, deploy, and manage services within the deployment domain and associated hosts using a drag-and-drop interface. 11 Furthermore, once the metadata has been defined, it becomes very easy to provide user interface based tools that allow construction of a business service by visually composing an execution environment for the already-built business service implementation. The implementation itself does not know about the kind of the environment in which it will be deployed. Because of this, the implementation can be deployed in execution environments that provide vastly different quality of service. The preferred embodiment includes the following features: The ability to build business service implementations without any knowledge of the underlying infrastructure environment. The ability to describe a deployment environment without any knowledge of what kind of business services will be deployed in it. The ability to enhance an infrastructure environment by providing custom application infrastructure services. These services, by implementing abstract interfaces, can be plugged into any supported infrastructure environment. These application infrastructure services provide discrete non-business related services and do not make any assumptions about who is going to use them and how will they be used. The ability to construct a virtual container, once the business service implementations have been developed, that integrates them with preexisting infrastructure services and allows for better management. 12 The ability to describe various components and provide plug-and-play development and deployment using a metadata foundation. Figure 1 illustrates these objectives further. A management framework 120 hides the underlying application server environment 140 from the business service implementation 110 and augments the underlying environment by providing the ability to add and integrate application infrastructure services. Further, an implementation framework 130 can be provided that even provides implementation services 150 such as a database management system. The preferred embodiment provides a platform that provides a level of abstraction, much higher than the one that is provided by application servers and other web services platforms currently available. This platform brings the development, configuration, deployment and management capabilities to the business services. The lifecycle shown in Figure 2 relates to either doing new development or introspecting existing application for the purpose of converting them into managed business services. As described above, the lifecycle includes the model or introspection phase 205, in which the application architects design the interfaces for the business services to be developed or introspect an existing service. In the case of new development, once the interfaces have been designed, the skeleton of business service implementation can be generated and then developed by the developers. In case of existing service, once the existing service has been introspected, a gateway implementation can be 13 automatically generated 210. The system architects then configure 215 the runtime for the • business service. Finally, the administrators then deploy 220 and manage 225 the business services. One disclosed feature of the preferred embodiment is a federated meta-model 230 that stores and provides access to the metadata describing the business services themselves and their infrastructure. This metadata describes the interface of the business service itself, the metadata about those infrastructure services, and the metadata about the virtual container that couples a business service implementation with one or more infrastructure . services along with their uniquely customized properties. The preferred embodiment is designed to expose a level of abstraction higher than those provided by industry standards 240. The standards and technologies in the web services area are changing very rapidly. As a result, the business services that leverage those standards run the risk of becoming outdated very quickly. The preferred embodiment exposes a higher level interface that can be generated by the metadata itself. This results in more stable and longer-lasting applications. The preferred embodiment provides the horizontal platform that can be used to build the vertical solutions that are more specific to industries in the form of industry specific templates 250. These solutions do not have to be complete themselves. In fact, most likely these solutions will be partial solutions designed to be extended for particular business problems. 14 Once the business services have been created, they can be orchestrated 260 using business service orchestration tools. These orchestrations themselves can be manifested as web services, thus forming a recursive relationship. Figure 3 describes the runtime environment for which the business services are configured and in which they are deployed. This architecture is described here at the logical level and can have one or more physical manifestations, in accordance with the disclosed or claimed embodiments. A deployment domain 300 is a mechanism for partitioning a large IT environment into smaller logical clusters of machines and applications so that these different clusters can be configured differently -from each other. In this ease,, these deployment domains serve to logically separate environments with different requirements domain. For example, there may be a deployment domain called internal applications. This domain may be configured with a specific "security service. Another domain may be for business partners and may be configured with a different kind of security service. Additionally, this domain may also be configured with a management service, e.g., to bill the users for usage of the business service. The deployment domain serves to define the scope of the infrastructure services that it is composed of and the business services that are deployed in it. The deployment domain defines the logical boundaries and scope of the infrastructure and business services within it. It is a logical partition of a large 15 computing environment which consists of many physical machines. The metadata data related to the deployment domain defines that logical partition. One or more physical machines can be configured for a deployment domain and one or more application infrastructure services can be made part of the fabric that is a deployment domain. Each server machine, called a host, that is configured to participate in one or more deployment domains will contain a core software service. The metadata that describes a host can include such items as most name, host's IP address, vthe core directory path on the host for the application, etc. Since there is a many-to-many relationship between the hosts and deployment domains, a list of hosts can exist independently of the deployment domains. When a host is configured for a deployment domain, it has to be able to run all of the business services deployed in that domain. The application infrastructure services do not have to run on the host because they can themselves be remote. An application infrastructure service is defined as a service that provides a discrete non-business level service. Some examples of infrastructure services are security services, transaction services, service monitoring, load balancing, fault tolerance, and messaging service. An infrastructure may also provide some other services such as reliable delivery or asynchronous messaging. These services 'can also be much higher level; services such as accounting- & billing services, service 16 level agreement management services and user profile management services. The best way to characterize an application infrastructure service or differentiate it from a business service is that business service in itself performs a business function, such as procurement or a human resource system. In contrast, an infrastructure service provides secondary functionality that is not part of the business functions itself. The metadata of an infrastructure service consists of property sheets with each property sheet containing one or more related properties. For example, a security service may contain five sheets for general properties, authentication, authorization, message integrity, and message confidentiality. Each sheet contains properties that allow customization of the underlying infrastructure service for this specific use. Since these properties are specific to the underlying service, their interpretation is left completely up to the service itself and its plugin. Furthermore, since the property values are specific to the specific usage of this service, these properties need only be defined once a virtual service container is configured with this service. Once an infrastructure service has been written or purchased, it has to be made part of one or more deployment domains so that it can be used. This is accomplished by defining an abstract plugin interface. This interface allows the deployment management tools and runtime software to plugin an infrastructure service into the deployment domain and allows the service to be used at 17 runtime. The tools that allow the user to visually configure the virtual service container may allow mechanisms to "drag" the infrastructure service and "drop" it on the virtual service container on a canvass. The tools can at this time present the required set of properties • to be defined for the service- for this particular container. This is accomplished by requesting the plugin to provide its customizable property sheets so that they can be filled. At runtime, the virtual container receives the requests sent to the business service and invokes plugs for all the application infrastructure services configured for this container. The plugin can then retrieve the metadata and use it to perform the work. If the actual infrastructure service is implemented as a set of libraries, then the plugin can invoke those libraries or if it represents a remote service then it can communicate with that remote service in a manner that is specific to that infrastructure service. In any case, the runtime is not aware of the details of the operation - it simply invokes the plugin and passes it the runtime invocation-related data. Each infrastructure service is therefore required to implement the plugin interface as a precondition to it becoming part of an infrastructure. An infrastructure service may provide different plugins for different deployment domains. The location and other necessary information required to load the plugin is part of the metadata of the infrastructure service. 18 A business service implementation is an implementation of the business behavior that a service is expected to provide. This behavior should be implementable in a manner independent of how it is accessed. For example, it should be possible to implement the business logic for a procurement service without being specific to Jave Platform 2 Enterprise Edition (J2EE)-based access or Microsoft .NET based access. However, once the service has been constructed, it may be deployed in a virtual container 320 that is specific to the underlying platform. This virtual container then decouples the service implementation from the infrastructure in which it is deployed. This virtual service container 320 is conceptually similar to a J2EE container to the extent in that it provides the several needed services such as transaction and database management. However, unlike J2EE like containers, these services are not fixed but can be added, removed and updated. The virtual container 320 of the preferred embodiment, is a higher level concept. It views an environment as a collection of discrete higher level services and recognizes the need for business services to be integrated with those higher level services. It limits its scope to the infrastructure level services and does not provide those services that are needed for implementing the business logic, such as database management. The container is called "virtual" because it itself is a platform independent definition rather than a physical implementation. It is described in terms of metadata. The metadata for the container describes the 19 business service implementation that is it hosting. This service was built using the development tools and its definition is part of the development metadata. In an integrated system of tools, the deployment tool may retrieve this definition from the development metadata repository. The metadata for the container also describes one or more application infrastructure services required by the virtual container. When a virtual container is created, it is created for a particular deployment domain. This deployment domain is already preconfigured with one or more infrastructure-level services. The deployment engineer can select from those infrastructure services and integrate them into the container using visual mechanisms such as dragging and dropping them on the container. At this time, the tools may invoke the plugin and bring up the set of properties necessary to correctly use the infrastructure-level service. Once the virtual container has been defined, there is enough metadata to generate a physical implementation of the virtual container, build it, package it and transfer the required binaries to the host. Once this is done, the business•service is ready to be deployed and used. When the code is generated, it is generated according to some pre defined mappings of the metadata to the underlying platform. So for example, the physical implementation for .NET platform may be quite different from the physical implementation for J2EE. These mappings define what elements of the metadata generate what kind of code for the underlying platform. 20 Many underlying platforms either need to add software code that is specific to them or require certain information in various configuration files for the applications to function properly. For example, an application infrastructure service using microsoft's implementation of WS-Security specification requires certain information to be placed into the .NET specific configuration files. Also, some application infrastructure services may need to insert specific programming code in the generated code. For example, a load balancing service may need to insert specific programming code in the generated container code as well as the generated client proxy to properly exploit its capabilities. For this reason, the code generators involve the application infrastructure service plugs in the code generation process. When code generation starts, it also loads the plugs for the infrastructure services being used by the container. All code to be generated, whether it is language code or configuration code is represented in XML. The code generator, first creates XML documents for all the code that it wants to generate. It then invokes the infrastructure service plugs and provides them an opportunity to add code specific to theta by passing the XML documents representing the code to be generated. Once all the plugs have added their code, the code generator converts the XML documents back into either language specific code or configuration code, as necessary. This way, the code generation process can be kept completely independent of a particular infrastructure service while still allowing them to customize the generated code. 21 The separation between the business service implementation and the underlying environment provides two benefits. First, it allows the underlying application infrastructure and the business service implementation itself to evolve independent of each other. Secondly, this allows the physical manifestation of the hosted service to leverage fully the capabilities offered by various infrastructures. This is explained in more detailed below, but simply put it means that the virtual container 320, through metadata 330 and visual tools, can be visually composed to integrate one or more services offered by the underlying infrastructure. Since this integration is performed through the virtual container and at configuration time, it does not become part of the service implementation itself. The same procurement service can then be configured and deployed in two different deployment domains providing different levels of service. Once the container has been configured and its software code has been generated and built, a package can be created that includes all the necessary .- platform specific binary assemblies required for this service. This package is then placed in a master vault. At this point, a visual deployment tool can provide some mechanism such as drag-and-drop to deploy this business service on any machine that is part of the deployment domain. If a host is then dragged and dropped on the virtual container, its package is collected from the master vault and brought over to the machine being dragged and dropped. This package is then opened up and its contents are extracted. These contents are then configured in a manner that is specific to the underlying platform. 22 The actual addressable and accessible service is then provided by the physical form of the virtual container 320 which can be specific to the underlying environment. The traditional definition of management services tools 310 are network managers. The management services and tools described here have more application level context than the system level context. Some examples of management tools are business service monitoring tools, service level agreement (SLA) management tools, fault tolerance tools, application event handling, billing and accounting services or user profile management. Various application infrastructure services may provide their own management tools that will use the data collected by their plugins. The most fundamental and core capability of this architecture is the metadata 330. The metadata described here is logical metadata. Logically, each deployment domain 300 has its own instance of metadata 330. This metadata describes the deployment domain itself in terms of the infrastructure services that it is able to offer and the virtual service containers 320 that are deployed in it. As a general rule, the exact form that the metadata is stored in is not important. The platform can choose an XML format, a relational database or some binary form. Figure 4 illustrates a federated metadata storage and access system with various possible clients of the metadata. The development tools will require metadata that describes the team development environment and will allow 23 sharing of development artifacts. One exemplary implementation of the metadata architecture is illustrated below. The metadata has been described above as a part of other elements. It is useful to note that the two kinds of metadata that are relevant here are configuration/deployment metadata and operational metadata. The configuration/deployment metadata is used by the configuration and deployment tools as well as by the runtime system. This data will not change often but will rather be accessed concurrently by large number of users. A configuration metadata server should preferably offer extensive" caching features where the data is handed out with a time-to-live parameter indicating how long the client can use the data before being required to refresh it. Operational metadata is used by one or more infrastructure services such as a monitoring service, load balancing service, and fault-tolerance service. This data tends to change very frequently and the tools that present this data, for viewing and analysis, may be required to refresh based on user preferences. The following is an exemplary case use in accordance with the preferred embodiment. Here, we look at a typical use case scenario of a large bank that serves consumer loan market. The bank has a large internal IT organization, responsible for delivering the business serv.ices to its users. The IT organization has to overcome the challenges of building applications that will survive 24 the changing technology. Furthermore, the enterprise considers the conformance of industry standards as its strategic goal. The, two initial applications that have been identified have different needs. The first application is an Online Loan Approval System. Although the logic for credit-approval already exists in the form, of many small systems, the bank wants to build a new system that uses that logic but re-implements it in a more consolidated and scalable manner. Previously, the bank employed a large loan approval department that received the loan requests either through fax or telephone and used these multiple systems to score the applicant's credit history and make the loan decisions. However, the bank wants to make this system available online so that the applicant's could themselves apply for the loan. In addition to its potential clients, the bank may also decide later on to make this system available to its smaller business partners to get credit history of clients and to provide services such as credit risk scoring. For those services, the bank may charge those business partners on a per-transaction basis. The second system is an application, called Customer Service Online system, that will allow bank's consumer loan clients to get the status of their accounts, directly without going through customer service. This information already exists in a legacy J2EB system that is deployed in the internal secure network. The bank wants to build a front-end web service to this system. 25 In order to meet its strategic technical objectives, the bank has standardized on toolkit in accordance with the preferred embodiment. The bank also has a well-structured group that runs its data centers. The data center has system architects and system administrators who collectively run the managed environment for all the bank's applications. As. is with any system, the normal steps of requirements gathering and requirements analysis are performed. These steps are no different than any other application development project. However, once the requirements have been analyzed, the application architect will transform the requirement for the Online Loan Approval System into a business interface. This business interface becomes the contract that has to be implemented. The logic that implements this business interface is termed as the business logic that has to be developed. The application architects use a off-the-shelf modeling tool to model the service contract. This contract identifies the operations (business functions) that the service exposes, defines a type system that defines the data required as inputs or is returned as outputs by those operations. This business interface is critical data because it defines the Contract between this business service and its users. Once the application architects have stabilized the business contract, they extract contract information from the modeling tools and generate metadata in a metadata repository, in accordance with the preferred embodiment. 26 The development team then takes this business contract and conducts a detailed design and develops the business logic. The development team decides to use C# as the development language and the implementation is developed as C# assembly. The development team only focuses on implementing the business logic as required by the business contract. They do not address other key issues such as security, billing or scalability. Their efforts are strictly focused on building one or more assemblies that implement the business logic. Once the implementation has been built and tested in stand-alone mode, an implementation package is created that contains the necessary metadata and DLLs and is handed over to the data center that is responsible for deploying and managing bank' s applications . The customer service system presents a different scenario than the first one. The bank really does not want to change the exiting system. The system works well and already has all the necessary functions required to fulfill the task. However, this system was purchased by the bank from a 3rd party and provides no way for bank to expose it to external users and is not manageable. The application architects have decided to use a system in accordance with the preferred embodiment to build a front-end gateway service that will expose the functionality of this system to the external users and will conform to the strategic goals of the bank in being standards compliant and be manageable. 27 This process is very simple. The introspection capabilities of the preferred embodiment are used to analyze the J2EE interfaces exposed by the existing applications. From these, then one or more functions are selected and system then automatically generates the required metadata, populates the metadata repository and then generates a gateway implementation that can delegate requests to the existing system. As in the previous case, this gateway implementation is then packaged in JAR files , and an implementation package is created. This implementation package is then handed over to the data center that is -responsible for configuring, deploying and managing bank's applications. Once the data center receives an implementation package, it is ready to configure the service. It is assumed that by this time the minimal metadata that describes the service interface has been defined in the metadata repository. The data center already has several different deployment domains configured. The data center also uses several infrastructure services such as Security. For some of its infrastructure services, the vendors provided toolkit-compatible plug-ins and for others the data center wrote its own. In either case, those infrastructure services are properly configured for the preferred embodiment and fit in its plug-and-play architecture. Configuring a business service involves several different steps that allow a business service implementation to be transformed into a managed and hosted web service. 28 The business service implementation provided to the data center is an implementation package that contains one or more DLLs or JAR files that implement the business behavior. These implementations lack the appropriate environment required to make the business service addressable and hostable and they also lack the necessary infrastructure capabilities such as security. The first step that the system architects do is to define a virtual container. This virtual container extends the metadata describing the service contract with metadata relating to the desired infrastructure services. This metadata will be used later on to create a physical web service that will provide a proper execution environment for the business logic implemented by the developers and will provide the flexible management environment required by the data center to perform its functions. During this process, the system architects also decide what infrastructure level capabilities (security, transactions, etc.) are required for this business service. They then use the drag-and-drop facilities available in the visual composition environment of the preferred embodiment to create this container. As new infrastructure services are dragged onto the virtual container, these infrastructure services plugs are invoked by the graphical environment and at this time, these plugs populate the metadata with a set of properties that they would like to be customized. The graphical environment then presents those properties in a property editor and lets the system architect provide unique values of those properties. They 29 can also customize the container itself by setting its logging levels as well as choose the correct QoS parameters such as various delivery modes. Once the virtual container has been configured, the system architects can select the target platform for this web service. For example, if the business implementation is written in Java, then the potential target platforms can be any of the J2EE environments supported by the installation. Alternatively, if the implementation was provided in DLLs, then the target platform can be Microsoft's .NET environment. Once the target platform has been selected, the composer tool can generate the code necessary for a web service that can be physically deployed and managed and then build that code along with the provided implementation into an executable. The composer then creates a deployment package that contains all the necessary DLLs or the JAR files required for deployment. This package is then automatically placed in a master vault that is managed by the system of the preferred embodiment. All machines that are configured in the data center have an agent service running on them. These agents cooperate with each other to transfer packages in and out of the master vault and configure particular underlying target platforms.for business services. Once a deployable package has been created for a web service, the composer tool can be used to drag different hosts on a business service. This drag-and-drop operation triggers the actual deployment process. 30 When a host is dragged on a business service, the SOA Agent • running on that host retrieves the deployment package from the master vault, unpackages it on that machine, performs the steps necessary to configure the underlying environment and makes the web service addressable. A web service can be undeployed from a host by selecting that host in composer tool and simply deleting it from there. This results in all traces of that package being removed from the machine. One a service has been deployed, it can be easily managed. Whenever, a request is sent to that service, the physical container provided by the runtime environment receives it. The runtime environment then executes all the necessary infrastructure services configured for this container and then invokes the business implementation provided by the user. When it gets the response from the business service implementation, it re-invokes any necessary infrastructure services and sends the response back to the caller. As the technology changes, ' the infrastructure services can change. The system architects can use the composer tool to slowly transition the deployed business services from an old or obsolete module to a new module by simply removing the old plug from the business service and using drag-and-drop to configure the business service with new plug. The preferred embodiment automatically removes older DLLs or JARs from the physically deployed services and copies the new ones for the new plug. The business 31 services adjust to the new infra-structure service without the typical need for interruption and modification. To continue the bank example, after the Online Loan Approval service has been deployed, the bank decides to make that service available to its business partners for a price. An internal infrastructure level billing service is developed (along with its toolkit compatible plug) and configured. The system architects simple drag this infrastructure service on the Online Loan Approval service, without modifying the business implementation or bringing the service down. The preferred embodiment automatically modifies the metadata, reconfigures the deployed services and the runtime environment starts using this new infrastructure service when requests are sent to the business service. One specific feature of the preferred embodiment is a visual composition environment. The preferred embodiment uses visual tools to generate metadata. These tools can present the core metadata in a tree structure as shown in Figure 5. Figure 5 shows an exemplary user interface 500 for a visual composition environment in accordance with the preferred embodiment. GUI interface 500 is divided into multiple areas, including available objects area 510, active object identifier 540, related objects area 520, and properties area 530. Available objects area 510 shows all objects that are available to be configured or deployed, including hosts, infrastructure services, service implementations, 32 and deployment domains. The folder named "hosts" contains the list of all available hosts in the entire managed space. The information that is visible for each host in this list can be such as the name of the server and its machine address. The folder named "infrastructure services" contains a list of all available infrastructure services. This information preferably does not contain anything more than the name of the service and its description and purpose. These are all the infrastructure services available to be deployed. The folder named "implementation services" contains all the implementation packages that have been made available. Each of these contain the related metadata describing the service contract as well as the binaries that contain the actual implementation of that service contract behavior. It is also possible to further group the service implementations. The folder named "deployment domains" contains the deployment domains underneath it. Each deployment domain can have a folder of its own. Each deployment domain furthermore has one folder for each virtual container in it. The folder for the virtual container all the infrastructure services that it is configured with and all the hosts that it is deployed on. Active object identifier 540 shows which object is currently active. Here, "Domain 1" is the active object; this label will change to correspond to whichever object the user is acting upon. This area is actually 33 sensitive to whether a deployment domain is selected or a virtual container is selected. Related objects area 520 shows all objects, grouped according to type, which are currently associated with the active object. In this example, because deployment domain "Domain 1" is the active objects, the related objects area 520 shows all hosts, infrastructure services, and virtual containers for business services that are currently deployed in Domain 1. In this example, both Host 1 and Host 2 are associated with Domain 1, and the Security and Package Tracking services are deployed in Domain 1. Note that if, for example, "Host 1" were the active object 540, then the related objects area 520 would display all deployment domains, infrastructure services, and virtual containers related to Host 1. Whatever type of object is showing as the active object 540, the other types of objects will be show in the related objects area 540. Finally, properties area 530 is used to define and modify the properties for any object. When an object is selected anywhere in the user interface 500, any customizable properties related to that object will be shown in properties area 530. The user may then edit these properties as appropriate. Using interface 500, the user can select an active object 540, then drag and drop objects between the available objects 510 and the related objects area 520. When an object is dragged from the available objects area 510 Into the related objects area 520, the system will then 34 perform all necessary file generation and configuration, as defined by the appropriate properties, to actually form the logical relationship between the dropped object and the active object. This process is described in more detail elsewhere in this disclosure, and the implementation is within the abilities of one of skill in the art. For example, if the "Online Catalog" service implementation were dragged into the related objects area 520 when the active object 540 is "Domain 1," then the system will automatically generate all necessary binaries, and transfer and install them as appropriate, to deploy the Online Catalog service in the Domain 1 deployment domain. In the same manner, if an object is dragged out of the related objects area 520, then the system will remove its logical relationship with the active object. Dp to this level, the elements are those that 4xist in global space. These are elements or pieces of metadata that are not specific to a deployment domain. Further into the deployment domain, the metadata becomes more specific. One or more hosts can be prepared to host a deployment domain. Similarly, a single deployment domain can span multiple hosts. All the hosts configured for a specific deployment domain appear in the folder belonging to that deployment domain. These nodes may contain data such as the working area to store different deployment packages containing different binaries and configuration files belonging to the infrastructure as well as business services in that deployment domain. 35 An infrastructure service can be configured in multiple deployment domains and a single deployment domain will have multiple infrastructure services. This relationship is similar to the many-to-many relationship that the hosts have to a deployment domain. When an infrastructure service is configured for a deployment domain, its related software, such as its plugins, is physically transferred to all the hosts that are configured for the domain. When a new virtual service container is created, it is ready to be deployed to any of the physical machines. Each container has a folder of its own underneath the deployment domain folder. The list of hosts that appear here are the hosts where this container is physically deployed and the list of infrastructure services are the ones that his container is configured to use. By organizing the information like this, a visual tool of the preferred embodiment can use drag-and-drop capabilities to compose the virtual service container. Figure 6 shows an exemplary virtual container represented on a canvas. In this figure, the larger outside cylinder is the virtual service container 600. The smaller cylinders inside the larger one represent the plugins 610 for the infrastructure services. At the end of the chain is the business service implementation 620 that the virtual service container is hosting. Using this representation, the user can drag and drop infrastructure services, configured for that domain, from either the tree structure or a graphical palette. Similarly, the container 36 can be dragged onto a host in that domain, thus triggering the physical deployment. Another feature is the unique customization of the use of the configured infrastructure properties through a system of property sheets. When a virtual container is configured with an infrastructure service, at that time the preferred embodiment loads the plug of the infrastructure service and invokes the plug, providing it the empty collection of property sheets. The plug responds by populating this collection with property sheets that contain properties that it is interested in. The runtime system and the composition tools do not know anything about these properties. One the plug has populated the property collections with properties specific to it, the composition tools presents those properties in a property editor that allows the user to provide unique values for those properties. These properties are then saved with the other metadata and can be changed later on. Each collection contains one or more property sheets and each property sheet contains one or more properties. This organization of properties allows for a more readable and understandable organization of the properties. Another feature of the preferred embodiment is the code-generation capability. Once a container has been configured, its definition is complete. However, it is not yet ready to be physically deployed because it is only a definition at this point. However, since now the definition is complete, the user can select a target environment such as .NET or an EJB server. Once the target environment has been selected a code generation scheme can 37 Another feature of the preferred embodiment is software configuration capability. Once the code for the virtual service container has been generated, compiled, and packaged, the container can be placed into a packaged state. At this point, a host can be dragged on the container. This will cause the software configuration facility to perform separate steps: - It can transfer the deployment package that contains all the related files to.the target host machine; - These files can then be unpackaged on that machine by this facility automatically and placed into the specific directories structure required by the underlying platform; - In the case of web services, the web server can be configured to know about the web service. Similarly in case of an J2EE, the EJB server can be configured to know about the service; and - The configuration files can be placed into the proper areas. Once these steps have been performed, the virtual service container has been transformed into a physical service that can be invoked. At a later time, when updates are made available for either the business service implementation or the infrastructure services plugs, the corresponding packages can be updated and these updates can be propagated to all the machines where the physical business services are deployed. 38 be selected to generate software code that maps the definition of the virtual container to the computer facilities offered by the underlying target platform. This code can then be compiled and linked with the runtime environment required by the platform and a package is created. Various color coding schemes can be used to describe the state that the container is in. The possible stages identified include configured, packaged, and deployed. The code generation software can additionally generate smart proxies that perform the equivalent of the virtual service container for the client. These smart proxies integrate the infrastructure services as defined by the business service for the client. For example, a business service may require the client application to authenticate itself against the security infrastructure service and send only the authentication token to the business service. A smart proxy will retrieve the metadata for the client and invoke the infrastructures configured for the virtual container that are relevant for the client environment. These plugs can then prompt the client for any data that they might require and use the runtime environment to send that data to the virtual container along with the rest of the request data. Just as the virtual service container can be packaged into a distributable unit, the smart proxies can also be packaged into a distributable unit. These units can then be separately provided to those who are interested in building client applications to those business services. 39 Figure 7 shows a flowchart of an exemplary process in accordance with the preferred embodiment. In this process, the user accesses a user interface and selects a deployment domain (step 705) . The user then drags an icon representing a host system into the deployment domain area depicted on the user interface (step 710) . In response, the host is associated with that deployment domain and any other objects in the deployment domain (labeled DD in figure, step 715). The user drags an icon representing an infrastructure service (labeled IS in figure) into the deployment domain area depicted on the user interface (step 720. In response, the infrastructure service is associated with the deployment domain and any other objects within the deployment domain (step 725). The user drags an icon representing a service implementation (labeled SI in figure) into the deployment domain area depicted on the user interface (step 730), thus starting the definition of a virtual container, and optionally specifies properties for the virtual container (step 735) . In response, the service implementation is associated with the deployment domain and any other objects within the deployment domain (step 740). The user then drags one or more infrastructure services from within this domain onto the virtual container (labeled VC in figure, step 745), and optionally specifies the properties for the. infrastructure services (step 750). In response, the system associates this infrastructure service with the virtual container (step 755). 40 The system then evaluates any new or changed associations (step 760). The system generates any code necessary to implement the associations (step 765), and transmits and installs the generated code as necessary (step 770) . In this way, the user is able to fully manage the deployment domain, and to deploy and manage the hosts and services within it, all using a simple and intuitive user interface. It should be noted that in the exemplary process described above, and other processes described herein, not all steps must be performed at any given time. Furthermore, many of the process steps described above may be performed in any order, or repeated, without changing the nature of the process or the advantages it provides. It should also be noted, as discussed above, that a similar method can be used when a host or service is first selected, then other services, hosts, or a deployment domain is then associated with that host or service using the drag-and-drop technique above. Similarly, the implementing code will then be generated and installed by the system. Those skilled in the art will recognize that, for simplicity and clarity, the full structure and operation of all data processing systems suitable for use with the present invention is not being depicted or described herein. Instead, only so much of a data processing system as is unique to the present invention or necessary for an understanding of the present invention is depicted and described. The remainder of the construction and operation 41 of data processing system may conform to any of the various current implementations and practices known in the art. It is important to note that while the present invention has been described in the context of a fully functional system, those skilled in the art will appreciate that at least portions of the mechanism of the present invention are capable of being distributed in the form of instructions contained within a machine usable medium in any of a variety of forms, and that the present invention applies equally regardless of the particular type of instruction or signal bearing medium utilized to actually carry out the distribution. Examples of machine usable mediums include: nonvolatile, hard-coded type mediums such as read only memories (ROMs) or erasable, electrically programmable read only memories (EEPROMs), user-recordable type mediums such as floppy disks, hard disk drives and compact disk read only memories (CD-ROMs) or digital versatile disks (DVDs), and transmission type mediums such as digital and analog communication links. Although an exemplary embodiment of the present invention has been described in detail, those skilled in the art will understand that various changes, substitutions, variations, and improvements of the invention disclosed herein may be made without departing from the spirit and scope of the invention in its broadest form. None of the description in the present application should be read as implying that any particular element, step, or function is an essential element which must be included in the claim scope: THE SCOPE OF PATENTED 42 WE CLAIM: 1. A data processing system having at least a processor and accessible memory, the said system comprising: means adopted to receive a selection of a deployment domain (300); means adopted to receive an instruction to associate an object(510) with the deployment domain(300); means adopted to choose a method necessary to associate the object with the deployment domain(300); and means adopted to perform the method, characterized in that method is chosen according to pre-defined mappings of metadata(330) to an underlying platform. 2. The data processing system as claimed in claim $, wherein the object is a host data processing system. 3. The data processing system as claimed in claiml, wherein the object is a service implementation software module. 4. The data processing system as claimed in claim $, wherein the object is an infrastructure service software module. 5. The data processing system as claimed in claim $, wherein the selection is received in a graphical user interface (500). 6. The data processing system as claimed in claim $, wherein the instruction is made by dropping an icon representing the object onto a graphical user interface screen portion associated with the deployment domain (300). 7. The data processing system as claimed in claim \|, further comprising means for receiving property information associated with the object. Dated this the 29th day of June, 2005

Full Text

FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
"SYS1TEM FOR MANAGING SERVICES"
ELECTRONIC DATA SYSTEMS CORPORATION
Of 5400 Legacy Drive, H3-3A-05, Piano, TX 75024, USA
The following specification particularly describes the invention and the manner in which it is to be performed.
Original
643./MUMNP/05
GARNTED
14-02-2007

TECHNICAL FIELD OF THE INVENTION
The present invention is directed, in general, to data processing system services management.
BACKGROUND OF THE INVENTION
In the area of conventional business service 'development, there are, in general, three major roles, each role having specific tools to address its needs.
Application architects are primarily concerned with defining the contracts of the business services to meet the business requirements. An application contract consists of one or more interface definitions, reflecting the right level of interface granularity and service behavior such as operations exposed and their inputs and outputs.
An important aspect of the architect's task here is to ensure that existing interface types are reused so that multiple interface types and messages are not reinvented to fulfill similar requirements.
Once the correct interfaces have been defined, the application developers are ready to implement those interfaces. This often involves writing code that implements business logic. The developers also have to be able to unit^test the code that they have just written.
2

Finally, once the code has been developed, it can be given to the system administrators for configuration, deployment and management. They can then configure the runtime execution environment for the newly developed service and deploy the application. Once deployed, the application can then be managed through the means available in the environment.
In the conventional development model, the
applications are developed from scratch. This allows the users to perform top-down design and leverage the full capabilities of the available technologies since no baggage needs to be carried from the past.
Currently, there are 5 major phases of the
lifecycle of the business services. In the model phase,
the application architects design the interfaces for the
business services to be developed. Once the interfaces
have been designed, the business logic is developed by the
developers of the system. The system architects then
configure the runtime for the business service and the
administrators then deploy and manage the business
services. ,
In many cases, the business services already exist but are not manageable. These services may be either 3rd party off-the-shelf (COTS) applications or custom applications developed in-house or by system integrators.
This style of development is bottom-up development where the interfaces are actually constructed based on existing applications. The architects first use introspection to rev.erse engineer metadata from the
3

existing applications. These applications may exist in. one of many supported technologies such as Java classes, CORBA, EJB's, existing web services or COTS packages such as SAP or Siebel. Introspection would result in one-to-one interface generation. However, in real world, these interfaces may need to be refactored. Refactoring involves either suppressing some of the operation in an interface, creating brand new ones, combining two or more interfaces (contract aggregation) or splitting a contract into two or more contracts (contract dissemination).
It should be noted that the existing applications
could also be web services. The process should however be no different than that for 3rd party COTS or custom applications supporting a particular technology.
Business logic generally does not change in nature. However, the underlying technologies are changing very rapidly. For example, there are a number of new standards that are being developed to address various aspects of distributed business services. Many standards do not have any sort of industry consensus and many areas have competing standards. However, the applications have to be developed today. Typically, the business services are written to provide all the other necessary functionality, such as security and others (application infrastructure services) that do not actually contribute to the business behavior itself. As the standards and technologies for these other services (application infrastructure services) evolve, the business services have to be modified and enhanced in order to take advantage of them. Furthermore, in the current state of the art, the
4

configuration and deployment of these services is specific to a particular underlying environment and the underlying products.
There is, therefore, a need in the art for an improved system and method for composing, configuring, deploying, and managing business services in a data processing system and data processing system network.
5

SUMMARY OF THE INVENTION
To address the above-discussed deficiencies of the prior art, it is a primary object of the present invention to provide an improved system and method for business services development and management in a data processing system and data processing system network.
The preferred embodiment provides a system and method for composing, configuring, deploying, and managing services in a data processing system and data processing system network. This system provides deployment domains to define a logical set of business services that have similar requirements for an application infrastructure. A deployment --domain is created, and a graphical user interface allows a user to compose, configure, deploy, and manage services within the deployment domain and associated hosts using a drag-and-drop interface.

The foregoing has outlined rather broadly the features and technical advantages of the present invention so that those skilled in the art may better understand the detailed , description . of the invention that follows. Additional features and advantages of the invention will be described hereinafter that form the subject of the claims of the invention. Those skilled in the art will appreciate that they may readily use the conception and the specific embodiment disclosed as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. Those skilled in the art will also realize that such equivalent constructions do not depart from the spirit and scope of the invention in its broadest form.
6

Before undertaking the DETAILED DESCRIPTION OF THE INVENTION below, it may be advantageous to set forth definitions of certain words or phrases used throughout this patent document: the terms "include" and "comprise," as well as derivatives thereof, mean inclusion without limitation; the term "or" is inclusive, meaning and/or; the phrases "associated with" and "associated therewith," as well as derivatives thereof, may mean to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, or the like; and the term "controller" means any device, system or part thereof that controls at least one operation, whether such a device is implemented in hardware, firmware, software or some combination of at least two of the same. It should be noted that the functionality associated with any particular controller may be centralized or distributed, whether locally or remotely. Definitions for certain words and phrases are provided throughout this patent document, and those of ordinary skill in the art will understand that such definitions apply in many, if not most, instances to prior as well as future uses of such defined words and phrases.
7

BRIEF DESCRIPTION OF THE DRAWINGS
For a more complete understanding of the present
invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, wherein like numbers designate like objects, and in which:
FIGURE 1 depicts a block diagram of the relationships between service layers in accordance with a preferred embodiment of the present invention;
FIGURE 2 depicts a block diagram relating a development and deployment lifecycle with data objects and service objects in accordance with a preferred embodiment of the present invention;
FIGURE 3 depicts a block diagram of a runtime
environment in accordance with a preferred embodiment of the present invention;
FIGURE 4 illustrates a federated metadata storage and access system in accordance with a preferred embodiment of the present invention;
FIGURE 5 depicts a virtual composition environment in accordance with a preferred embodiment of the present invention;
FIGURE 6 depicts a block diagram of a virtual container accordance with a preferred embodiment of the present invention; and
8

DETAILED DESCRIPTION OF THE INVENTION
FIGURES 1 through 7, discussed below, and the various embodiments used to describe the principles of the present invention in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the invention. Those skilled in the art will understand that the principles of the present invention may be implemented in any suitably arranged device. The numerous innovative teachings of the present application will be described with particular reference to the presently preferred embodiment.
Definitions: Following are short definitions of the usual meanings of some of the technical terms which are used in the present application. (However, those of ordinary skill will recognize whether the context requires a different meaning.) Additional definitions can be found in the standard technical dictionaries and journals.
Business Service Contract - A business service
contract describes the business service exposed. This normally contains information such as operations provided by the service, their inputs and outputs.
Business Service Implementation - A business service implementation is the software code required strictly to implement the above mentioned business behavior. This does not include other capabilities such as providing security or managing transactions.
9

Application Infrastructure Services - Application Infrastructure Services are all those services that themselves do not contribute to the business behavior, however they are necessary for the correct operation of the business service. These services can be added, removed or replaced without changing the business behavior of the business service.
Virtual Container - A virtual container couples a business service implementation with one or more application infrastructure services and provides the definition for a complete business service. This definition exists in metadata and contains all the metadata that customizes the specific usage of application infrastructure services inside the said virtual container.
Physical Business Service - A physical business service is the platform specific programming code that can be generated according to the previously discussed definition ' of the virtual container. This code can then be compiled and deployed in the underlying platform specific manner.
Web Services will soon be providing complex and
mission critical services to business partners and internal customers by providing a viable alternative to most application integration scenarios.
10

The disclosed embodiments provide a system and method for composing, configuring, deploying, and managing services in a data processing system and data processing system network. This system provides deployment domains to define a logical set of business services that have similar requirements for an application infrastructure. A deployment domain is created, and within it is contained a set of metadata that defines available hosts, application infrastructure services, and deployed business services. The metadata is managed by a federated metamodel system. A visual composition environment allows composition of a virtual container that couples the business service in question with the application level infrastructure services that it needs. The code generators can then generate platform specific code for the virtual, container. All this can be packaged for easy shipment. The packaged business services can then be easily deployed on any of the machines available to the system.
The disclosed embodiments include a method and system for describing the underlying application services infrastructure, a virtual execution environment for business services implementations and a system to integrate the two in a loosely coupled way through metadata so that the two can evolve independently and still stay compatible.
In the preferred embodiment, a deployment domain is created, and a graphical user interface allows a user to compose, configure, deploy, and manage services within the deployment domain and associated hosts using a drag-and-drop interface.
11

Furthermore, once the metadata has been defined,
it becomes very easy to provide user interface based tools that allow construction of a business service by visually composing an execution environment for the already-built business service implementation. The implementation itself does not know about the kind of the environment in which it will be deployed. Because of this, the implementation can be deployed in execution environments that provide vastly different quality of service.
The preferred embodiment includes the following features:
The ability to build business service
implementations without any knowledge of the underlying infrastructure environment.
The ability to describe a deployment environment without any knowledge of what kind of business services will be deployed in it.
The ability to enhance an infrastructure environment by providing custom application infrastructure services. These services, by implementing abstract interfaces, can be plugged into any supported infrastructure environment. These application infrastructure services provide discrete non-business related services and do not make any assumptions about who is going to use them and how will they be used.
The ability to construct a virtual container, once the business service implementations have been developed, that integrates them with preexisting infrastructure services and allows for better management.
12

The ability to describe various components and provide plug-and-play development and deployment using a metadata foundation.
Figure 1 illustrates these objectives further. A management framework 120 hides the underlying application server environment 140 from the business service implementation 110 and augments the underlying environment by providing the ability to add and integrate application infrastructure services. Further, an implementation framework 130 can be provided that even provides implementation services 150 such as a database management system.
The preferred embodiment provides a platform that provides a level of abstraction, much higher than the one that is provided by application servers and other web services platforms currently available. This platform brings the development, configuration, deployment and management capabilities to the business services.
The lifecycle shown in Figure 2 relates to either
doing new development or introspecting existing application for the purpose of converting them into managed business services. As described above, the lifecycle includes the model or introspection phase 205, in which the application architects design the interfaces for the business services to be developed or introspect an existing service. In the case of new development, once the interfaces have been designed, the skeleton of business service implementation can be generated and then developed by the developers. In case of existing service, once the existing service has been introspected, a gateway implementation can be
13

automatically generated 210. The system architects then configure 215 the runtime for the • business service. Finally, the administrators then deploy 220 and manage 225 the business services.
One disclosed feature of the preferred embodiment
is a federated meta-model 230 that stores and provides access to the metadata describing the business services themselves and their infrastructure. This metadata describes the interface of the business service itself, the metadata about those infrastructure services, and the metadata about the virtual container that couples a business service implementation with one or more infrastructure . services along with their uniquely customized properties.
The preferred embodiment is designed to expose a
level of abstraction higher than those provided by industry standards 240. The standards and technologies in the web services area are changing very rapidly. As a result, the business services that leverage those standards run the risk of becoming outdated very quickly. The preferred embodiment exposes a higher level interface that can be generated by the metadata itself. This results in more stable and longer-lasting applications.
The preferred embodiment provides the horizontal platform that can be used to build the vertical solutions that are more specific to industries in the form of industry specific templates 250. These solutions do not have to be complete themselves. In fact, most likely these solutions will be partial solutions designed to be extended for particular business problems.
14

Once the business services have been created, they can be orchestrated 260 using business service orchestration tools. These orchestrations themselves can be manifested as web services, thus forming a recursive relationship.
Figure 3 describes the runtime environment for which the business services are configured and in which they are deployed. This architecture is described here at the logical level and can have one or more physical manifestations, in accordance with the disclosed or claimed embodiments.
A deployment domain 300 is a mechanism for partitioning a large IT environment into smaller logical clusters of machines and applications so that these different clusters can be configured differently -from each other. In this ease,, these deployment domains serve to logically separate environments with different requirements domain. For example, there may be a deployment domain called internal applications. This domain may be configured with a specific "security service. Another domain may be for business partners and may be configured with a different kind of security service. Additionally, this domain may also be configured with a management service, e.g., to bill the users for usage of the business service. The deployment domain serves to define the scope of the infrastructure services that it is composed of and the business services that are deployed in it.
The deployment domain defines the logical boundaries and scope of the infrastructure and business services within it. It is a logical partition of a large
15

computing environment which consists of many physical machines. The metadata data related to the deployment domain defines that logical partition.
One or more physical machines can be configured for a deployment domain and one or more application infrastructure services can be made part of the fabric that is a deployment domain. Each server machine, called a host, that is configured to participate in one or more deployment domains will contain a core software service.
The metadata that describes a host can include
such items as most name, host's IP address, vthe core directory path on the host for the application, etc.
Since there is a many-to-many relationship between the hosts and deployment domains, a list of hosts can exist independently of the deployment domains. When a host is configured for a deployment domain, it has to be able to run all of the business services deployed in that domain. The application infrastructure services do not have to run on the host because they can themselves be remote.
An application infrastructure service is defined as a service that provides a discrete non-business level service. Some examples of infrastructure services are security services, transaction services, service monitoring, load balancing, fault tolerance, and messaging service. An infrastructure may also provide some other services such as reliable delivery or asynchronous messaging. These services 'can also be much higher level; services such as accounting- & billing services, service
16

level agreement management services and user profile management services.
The best way to characterize an application infrastructure service or differentiate it from a business service is that business service in itself performs a business function, such as procurement or a human resource system. In contrast, an infrastructure service provides secondary functionality that is not part of the business functions itself.
The metadata of an infrastructure service consists of property sheets with each property sheet containing one or more related properties. For example, a security service may contain five sheets for general properties, authentication, authorization, message integrity, and message confidentiality. Each sheet contains properties that allow customization of the underlying infrastructure service for this specific use. Since these properties are specific to the underlying service, their interpretation is left completely up to the service itself and its plugin. Furthermore, since the property values are specific to the specific usage of this service, these properties need only be defined once a virtual service container is configured with this service.
Once an infrastructure service has been written or purchased, it has to be made part of one or more deployment domains so that it can be used. This is accomplished by defining an abstract plugin interface. This interface allows the deployment management tools and runtime software to plugin an infrastructure service into the deployment domain and allows the service to be used at
17

runtime. The tools that allow the user to visually configure the virtual service container may allow mechanisms to "drag" the infrastructure service and "drop" it on the virtual service container on a canvass. The tools can at this time present the required set of properties • to be defined for the service- for this particular container. This is accomplished by requesting the plugin to provide its customizable property sheets so that they can be filled.
At runtime, the virtual container receives the requests sent to the business service and invokes plugs for all the application infrastructure services configured for this container. The plugin can then retrieve the metadata and use it to perform the work. If the actual infrastructure service is implemented as a set of libraries, then the plugin can invoke those libraries or if it represents a remote service then it can communicate with that remote service in a manner that is specific to that infrastructure service. In any case, the runtime is not aware of the details of the operation - it simply invokes the plugin and passes it the runtime invocation-related data.
Each infrastructure service is therefore required to implement the plugin interface as a precondition to it becoming part of an infrastructure. An infrastructure service may provide different plugins for different deployment domains. The location and other necessary information required to load the plugin is part of the metadata of the infrastructure service.
18

A business service implementation is an implementation of the business behavior that a service is expected to provide. This behavior should be implementable in a manner independent of how it is accessed. For example, it should be possible to implement the business logic for a procurement service without being specific to Jave Platform 2 Enterprise Edition (J2EE)-based access or Microsoft .NET based access. However, once the service has been constructed, it may be deployed in a virtual container 320 that is specific to the underlying platform. This virtual container then decouples the service implementation from the infrastructure in which it is deployed.
This virtual service container 320 is conceptually similar to a J2EE container to the extent in that it provides the several needed services such as transaction and database management. However, unlike J2EE like containers, these services are not fixed but can be added, removed and updated. The virtual container 320 of the preferred embodiment, is a higher level concept. It views an environment as a collection of discrete higher level services and recognizes the need for business services to be integrated with those higher level services. It limits its scope to the infrastructure level services and does not provide those services that are needed for implementing the business logic, such as database management.
The container is called "virtual" because it itself is a platform independent definition rather than a physical implementation. It is described in terms of metadata. The metadata for the container describes the
19

business service implementation that is it hosting. This service was built using the development tools and its definition is part of the development metadata. In an integrated system of tools, the deployment tool may retrieve this definition from the development metadata repository.
The metadata for the container also describes one or more application infrastructure services required by the virtual container. When a virtual container is created, it is created for a particular deployment domain. This deployment domain is already preconfigured with one or more infrastructure-level services. The deployment engineer can select from those infrastructure services and integrate them into the container using visual mechanisms such as dragging and dropping them on the container. At this time, the tools may invoke the plugin and bring up the set of properties necessary to correctly use the infrastructure-level service.
Once the virtual container has been defined, there is enough metadata to generate a physical implementation of the virtual container, build it, package it and transfer the required binaries to the host. Once this is done, the business•service is ready to be deployed and used. When the code is generated, it is generated according to some pre defined mappings of the metadata to the underlying platform. So for example, the physical implementation for .NET platform may be quite different from the physical implementation for J2EE. These mappings define what elements of the metadata generate what kind of code for the underlying platform.

20
Many underlying platforms either need to add
software code that is specific to them or require certain
information in various configuration files for the
applications to function properly. For example, an
application infrastructure service using microsoft's
implementation of WS-Security specification requires
certain information to be placed into the .NET specific
configuration files. Also, some application infrastructure
services may need to insert specific programming code in
the generated code. For example, a load balancing service
may need to insert specific programming code in the
generated container code as well as the generated client
proxy to properly exploit its capabilities. For this
reason, the code generators involve the application
infrastructure service plugs in the code generation
process. When code generation starts, it also loads the
plugs for the infrastructure services being used by the
container. All code to be generated, whether it is
language code or configuration code is represented in XML.
The code generator, first creates XML documents for all the
code that it wants to generate. It then invokes the
infrastructure service plugs and provides them an
opportunity to add code specific to theta by passing the XML
documents representing the code to be generated. Once all
the plugs have added their code, the code generator
converts the XML documents back into either language
specific code or configuration code, as necessary. This
way, the code generation process can be kept completely
independent of a particular infrastructure service while
still allowing them to customize the generated code.
21

The separation between the business service implementation and the underlying environment provides two benefits. First, it allows the underlying application infrastructure and the business service implementation itself to evolve independent of each other. Secondly, this allows the physical manifestation of the hosted service to leverage fully the capabilities offered by various infrastructures. This is explained in more detailed below, but simply put it means that the virtual container 320, through metadata 330 and visual tools, can be visually composed to integrate one or more services offered by the underlying infrastructure. Since this integration is performed through the virtual container and at configuration time, it does not become part of the service implementation itself. The same procurement service can then be configured and deployed in two different deployment domains providing different levels of service.
Once the container has been configured and its software code has been generated and built, a package can be created that includes all the necessary .- platform specific binary assemblies required for this service. This package is then placed in a master vault. At this point, a visual deployment tool can provide some mechanism such as drag-and-drop to deploy this business service on any machine that is part of the deployment domain. If a host is then dragged and dropped on the virtual container, its package is collected from the master vault and brought over to the machine being dragged and dropped. This package is then opened up and its contents are extracted. These contents are then configured in a manner that is specific to the underlying platform.

22

The actual addressable and accessible service is then provided by the physical form of the virtual container 320 which can be specific to the underlying environment.
The traditional definition of management services tools 310 are network managers. The management services and tools described here have more application level context than the system level context. Some examples of management tools are business service monitoring tools, service level agreement (SLA) management tools, fault tolerance tools, application event handling, billing and accounting services or user profile management.
Various application infrastructure services may provide their own management tools that will use the data collected by their plugins.
The most fundamental and core capability of this architecture is the metadata 330. The metadata described here is logical metadata. Logically, each deployment domain 300 has its own instance of metadata 330. This metadata describes the deployment domain itself in terms of the infrastructure services that it is able to offer and the virtual service containers 320 that are deployed in it.
As a general rule, the exact form that the metadata is stored in is not important. The platform can choose an XML format, a relational database or some binary form.
Figure 4 illustrates a federated metadata storage and access system with various possible clients of the metadata. The development tools will require metadata that describes the team development environment and will allow
23

sharing of development artifacts. One exemplary implementation of the metadata architecture is illustrated below.
The metadata has been described above as a part of other elements. It is useful to note that the two kinds of metadata that are relevant here are configuration/deployment metadata and operational metadata.
The configuration/deployment metadata is used by the configuration and deployment tools as well as by the runtime system. This data will not change often but will rather be accessed concurrently by large number of users. A configuration metadata server should preferably offer extensive" caching features where the data is handed out with a time-to-live parameter indicating how long the client can use the data before being required to refresh it.
Operational metadata is used by one or more infrastructure services such as a monitoring service, load balancing service, and fault-tolerance service. This data tends to change very frequently and the tools that present this data, for viewing and analysis, may be required to refresh based on user preferences.
The following is an exemplary case use in accordance with the preferred embodiment. Here, we look at a typical use case scenario of a large bank that serves consumer loan market. The bank has a large internal IT organization, responsible for delivering the business serv.ices to its users. The IT organization has to overcome the challenges of building applications that will survive
24

the changing technology. Furthermore, the enterprise considers the conformance of industry standards as its strategic goal.
The, two initial applications that have been identified have different needs. The first application is an Online Loan Approval System. Although the logic for credit-approval already exists in the form, of many small systems, the bank wants to build a new system that uses that logic but re-implements it in a more consolidated and scalable manner. Previously, the bank employed a large loan approval department that received the loan requests either through fax or telephone and used these multiple systems to score the applicant's credit history and make the loan decisions. However, the bank wants to make this system available online so that the applicant's could themselves apply for the loan. In addition to its potential clients, the bank may also decide later on to make this system available to its smaller business partners to get credit history of clients and to provide services such as credit risk scoring. For those services, the bank may charge those business partners on a per-transaction basis.
The second system is an application, called
Customer Service Online system, that will allow bank's consumer loan clients to get the status of their accounts, directly without going through customer service. This information already exists in a legacy J2EB system that is deployed in the internal secure network. The bank wants to build a front-end web service to this system.
25

In order to meet its strategic technical objectives, the bank has standardized on toolkit in accordance with the preferred embodiment. The bank also has a well-structured group that runs its data centers. The data center has system architects and system administrators who collectively run the managed environment for all the bank's applications.
As. is with any system, the normal steps of requirements gathering and requirements analysis are performed. These steps are no different than any other application development project. However, once the requirements have been analyzed, the application architect will transform the requirement for the Online Loan Approval System into a business interface. This business interface becomes the contract that has to be implemented. The logic that implements this business interface is termed as the business logic that has to be developed.
The application architects use a off-the-shelf modeling tool to model the service contract. This contract identifies the operations (business functions) that the service exposes, defines a type system that defines the data required as inputs or is returned as outputs by those operations. This business interface is critical data because it defines the Contract between this business service and its users. Once the application architects have stabilized the business contract, they extract contract information from the modeling tools and generate metadata in a metadata repository, in accordance with the preferred embodiment.
26

The development team then takes this business contract and conducts a detailed design and develops the business logic. The development team decides to use C# as the development language and the implementation is developed as C# assembly.
The development team only focuses on implementing the business logic as required by the business contract. They do not address other key issues such as security, billing or scalability. Their efforts are strictly focused on building one or more assemblies that implement the business logic.
Once the implementation has been built and tested in stand-alone mode, an implementation package is created that contains the necessary metadata and DLLs and is handed over to the data center that is responsible for deploying and managing bank' s applications .
The customer service system presents a different scenario than the first one. The bank really does not want to change the exiting system. The system works well and already has all the necessary functions required to fulfill the task. However, this system was purchased by the bank from a 3rd party and provides no way for bank to expose it to external users and is not manageable.
The application architects have decided to use a system in accordance with the preferred embodiment to build a front-end gateway service that will expose the functionality of this system to the external users and will conform to the strategic goals of the bank in being standards compliant and be manageable.
27

This process is very simple. The introspection capabilities of the preferred embodiment are used to analyze the J2EE interfaces exposed by the existing applications. From these, then one or more functions are selected and system then automatically generates the required metadata, populates the metadata repository and then generates a gateway implementation that can delegate requests to the existing system. As in the previous case, this gateway implementation is then packaged in JAR files , and an implementation package is created. This implementation package is then handed over to the data center that is -responsible for configuring, deploying and managing bank's applications.
Once the data center receives an implementation
package, it is ready to configure the service. It is assumed that by this time the minimal metadata that describes the service interface has been defined in the metadata repository.
The data center already has several different deployment domains configured. The data center also uses several infrastructure services such as Security. For some of its infrastructure services, the vendors provided toolkit-compatible plug-ins and for others the data center wrote its own. In either case, those infrastructure services are properly configured for the preferred embodiment and fit in its plug-and-play architecture.
Configuring a business service involves several different steps that allow a business service implementation to be transformed into a managed and hosted web service.

28

The business service implementation provided to the data center is an implementation package that contains one or more DLLs or JAR files that implement the business behavior. These implementations lack the appropriate environment required to make the business service addressable and hostable and they also lack the necessary infrastructure capabilities such as security.
The first step that the system architects do is
to define a virtual container. This virtual container extends the metadata describing the service contract with metadata relating to the desired infrastructure services. This metadata will be used later on to create a physical web service that will provide a proper execution environment for the business logic implemented by the developers and will provide the flexible management environment required by the data center to perform its functions.
During this process, the system architects also
decide what infrastructure level capabilities (security, transactions, etc.) are required for this business service. They then use the drag-and-drop facilities available in the visual composition environment of the preferred embodiment to create this container. As new infrastructure services are dragged onto the virtual container, these infrastructure services plugs are invoked by the graphical environment and at this time, these plugs populate the metadata with a set of properties that they would like to be customized. The graphical environment then presents those properties in a property editor and lets the system architect provide unique values of those properties. They
29

can also customize the container itself by setting its logging levels as well as choose the correct QoS parameters such as various delivery modes.
Once the virtual container has been configured, the system architects can select the target platform for this web service. For example, if the business implementation is written in Java, then the potential target platforms can be any of the J2EE environments supported by the installation. Alternatively, if the implementation was provided in DLLs, then the target platform can be Microsoft's .NET environment.
Once the target platform has been selected, the composer tool can generate the code necessary for a web service that can be physically deployed and managed and then build that code along with the provided implementation into an executable. The composer then creates a deployment package that contains all the necessary DLLs or the JAR files required for deployment.
This package is then automatically placed in a master vault that is managed by the system of the preferred embodiment. All machines that are configured in the data center have an agent service running on them. These agents cooperate with each other to transfer packages in and out of the master vault and configure particular underlying target platforms.for business services.
Once a deployable package has been created for a web service, the composer tool can be used to drag different hosts on a business service. This drag-and-drop operation triggers the actual deployment process.
30

When a host is dragged on a business service, the SOA Agent • running on that host retrieves the deployment package from the master vault, unpackages it on that machine, performs the steps necessary to configure the underlying environment and makes the web service addressable.
A web service can be undeployed from a host by selecting that host in composer tool and simply deleting it from there. This results in all traces of that package being removed from the machine.
One a service has been deployed, it can be easily managed. Whenever, a request is sent to that service, the physical container provided by the runtime environment receives it. The runtime environment then executes all the necessary infrastructure services configured for this container and then invokes the business implementation provided by the user. When it gets the response from the business service implementation, it re-invokes any necessary infrastructure services and sends the response back to the caller.
As the technology changes, ' the infrastructure services can change. The system architects can use the composer tool to slowly transition the deployed business services from an old or obsolete module to a new module by simply removing the old plug from the business service and using drag-and-drop to configure the business service with new plug. The preferred embodiment automatically removes older DLLs or JARs from the physically deployed services and copies the new ones for the new plug. The business
31

services adjust to the new infra-structure service without the typical need for interruption and modification.
To continue the bank example, after the Online Loan Approval service has been deployed, the bank decides to make that service available to its business partners for a price. An internal infrastructure level billing service is developed (along with its toolkit compatible plug) and configured. The system architects simple drag this infrastructure service on the Online Loan Approval service, without modifying the business implementation or bringing the service down. The preferred embodiment automatically modifies the metadata, reconfigures the deployed services and the runtime environment starts using this new infrastructure service when requests are sent to the business service.
One specific feature of the preferred embodiment is a visual composition environment. The preferred embodiment uses visual tools to generate metadata. These tools can present the core metadata in a tree structure as shown in Figure 5.
Figure 5 shows an exemplary user interface 500 for a visual composition environment in accordance with the preferred embodiment. GUI interface 500 is divided into multiple areas, including available objects area 510, active object identifier 540, related objects area 520, and properties area 530.
Available objects area 510 shows all objects that are available to be configured or deployed, including hosts, infrastructure services, service implementations,
32

and deployment domains. The folder named "hosts" contains the list of all available hosts in the entire managed space. The information that is visible for each host in this list can be such as the name of the server and its machine address.
The folder named "infrastructure services" contains a list of all available infrastructure services. This information preferably does not contain anything more than the name of the service and its description and purpose. These are all the infrastructure services available to be deployed.
The folder named "implementation services" contains all the implementation packages that have been made available. Each of these contain the related metadata describing the service contract as well as the binaries that contain the actual implementation of that service contract behavior. It is also possible to further group the service implementations.
The folder named "deployment domains" contains the deployment domains underneath it. Each deployment domain can have a folder of its own. Each deployment domain furthermore has one folder for each virtual container in it. The folder for the virtual container all the infrastructure services that it is configured with and all the hosts that it is deployed on.
Active object identifier 540 shows which object is currently active. Here, "Domain 1" is the active object; this label will change to correspond to whichever object the user is acting upon. This area is actually
33

sensitive to whether a deployment domain is selected or a virtual container is selected.
Related objects area 520 shows all objects, grouped according to type, which are currently associated with the active object. In this example, because deployment domain "Domain 1" is the active objects, the related objects area 520 shows all hosts, infrastructure services, and virtual containers for business services that are currently deployed in Domain 1. In this example, both Host 1 and Host 2 are associated with Domain 1, and the Security and Package Tracking services are deployed in Domain 1.
Note that if, for example, "Host 1" were the active object 540, then the related objects area 520 would display all deployment domains, infrastructure services, and virtual containers related to Host 1. Whatever type of object is showing as the active object 540, the other types of objects will be show in the related objects area 540.
Finally, properties area 530 is used to define and modify the properties for any object. When an object is selected anywhere in the user interface 500, any customizable properties related to that object will be shown in properties area 530. The user may then edit these properties as appropriate.
Using interface 500, the user can select an
active object 540, then drag and drop objects between the available objects 510 and the related objects area 520. When an object is dragged from the available objects area 510 Into the related objects area 520, the system will then

34

perform all necessary file generation and configuration, as defined by the appropriate properties, to actually form the logical relationship between the dropped object and the active object. This process is described in more detail elsewhere in this disclosure, and the implementation is within the abilities of one of skill in the art.
For example, if the "Online Catalog" service
implementation were dragged into the related objects area 520 when the active object 540 is "Domain 1," then the system will automatically generate all necessary binaries, and transfer and install them as appropriate, to deploy the Online Catalog service in the Domain 1 deployment domain.
In the same manner, if an object is dragged out of the related objects area 520, then the system will remove its logical relationship with the active object.
Dp to this level, the elements are those that 4xist in global space. These are elements or pieces of metadata that are not specific to a deployment domain. Further into the deployment domain, the metadata becomes more specific.
One or more hosts can be prepared to host a deployment domain. Similarly, a single deployment domain can span multiple hosts. All the hosts configured for a specific deployment domain appear in the folder belonging to that deployment domain. These nodes may contain data such as the working area to store different deployment packages containing different binaries and configuration files belonging to the infrastructure as well as business services in that deployment domain.
35

An infrastructure service can be configured in multiple deployment domains and a single deployment domain will have multiple infrastructure services. This relationship is similar to the many-to-many relationship that the hosts have to a deployment domain. When an infrastructure service is configured for a deployment domain, its related software, such as its plugins, is physically transferred to all the hosts that are configured for the domain.
When a new virtual service container is created,
it is ready to be deployed to any of the physical machines. Each container has a folder of its own underneath the deployment domain folder. The list of hosts that appear here are the hosts where this container is physically deployed and the list of infrastructure services are the ones that his container is configured to use.
By organizing the information like this, a visual tool of the preferred embodiment can use drag-and-drop capabilities to compose the virtual service container.
Figure 6 shows an exemplary virtual container
represented on a canvas. In this figure, the larger outside cylinder is the virtual service container 600. The smaller cylinders inside the larger one represent the plugins 610 for the infrastructure services. At the end of the chain is the business service implementation 620 that the virtual service container is hosting. Using this representation, the user can drag and drop infrastructure services, configured for that domain, from either the tree structure or a graphical palette. Similarly, the container
36

can be dragged onto a host in that domain, thus triggering the physical deployment.
Another feature is the unique customization of the use of the configured infrastructure properties through a system of property sheets. When a virtual container is configured with an infrastructure service, at that time the preferred embodiment loads the plug of the infrastructure service and invokes the plug, providing it the empty collection of property sheets. The plug responds by populating this collection with property sheets that contain properties that it is interested in. The runtime system and the composition tools do not know anything about these properties. One the plug has populated the property collections with properties specific to it, the composition tools presents those properties in a property editor that allows the user to provide unique values for those properties. These properties are then saved with the other metadata and can be changed later on. Each collection contains one or more property sheets and each property sheet contains one or more properties. This organization of properties allows for a more readable and understandable organization of the properties.
Another feature of the preferred embodiment is the code-generation capability. Once a container has been configured, its definition is complete. However, it is not yet ready to be physically deployed because it is only a definition at this point. However, since now the definition is complete, the user can select a target environment such as .NET or an EJB server. Once the target environment has been selected a code generation scheme can
37

Another feature of the preferred embodiment is software configuration capability. Once the code for the virtual service container has been generated, compiled, and packaged, the container can be placed into a packaged state. At this point, a host can be dragged on the container. This will cause the software configuration facility to perform separate steps:
- It can transfer the deployment package that contains all the related files to.the target host machine;
- These files can then be unpackaged on that machine by this facility automatically and placed into the specific directories structure required by the underlying platform;
- In the case of web services, the web server can be configured to know about the web service. Similarly in case of an J2EE, the EJB server can be configured to know about the service; and
- The configuration files can be placed into the proper areas.
Once these steps have been performed, the virtual service container has been transformed into a physical service that can be invoked.
At a later time, when updates are made available for either the business service implementation or the infrastructure services plugs, the corresponding packages can be updated and these updates can be propagated to all the machines where the physical business services are deployed.
38

be selected to generate software code that maps the definition of the virtual container to the computer facilities offered by the underlying target platform. This code can then be compiled and linked with the runtime environment required by the platform and a package is created.
Various color coding schemes can be used to describe the state that the container is in. The possible stages identified include configured, packaged, and deployed.
The code generation software can additionally generate smart proxies that perform the equivalent of the virtual service container for the client. These smart proxies integrate the infrastructure services as defined by the business service for the client. For example, a business service may require the client application to authenticate itself against the security infrastructure service and send only the authentication token to the business service. A smart proxy will retrieve the metadata for the client and invoke the infrastructures configured for the virtual container that are relevant for the client environment. These plugs can then prompt the client for any data that they might require and use the runtime environment to send that data to the virtual container along with the rest of the request data.
Just as the virtual service container can be
packaged into a distributable unit, the smart proxies can also be packaged into a distributable unit. These units can then be separately provided to those who are interested in building client applications to those business services.

39

Figure 7 shows a flowchart of an exemplary process in accordance with the preferred embodiment. In
this process, the user accesses a user interface and
selects a deployment domain (step 705) . The user then drags an icon representing a host system into the deployment domain area depicted on the user interface (step 710) . In response, the host is associated with that deployment domain and any other objects in the deployment domain (labeled DD in figure, step 715).
The user drags an icon representing an infrastructure service (labeled IS in figure) into the deployment domain area depicted on the user interface (step 720. In response, the infrastructure service is associated with the deployment domain and any other objects within the deployment domain (step 725).
The user drags an icon representing a service
implementation (labeled SI in figure) into the deployment domain area depicted on the user interface (step 730), thus starting the definition of a virtual container, and optionally specifies properties for the virtual container (step 735) . In response, the service implementation is associated with the deployment domain and any other objects within the deployment domain (step 740).
The user then drags one or more infrastructure services from within this domain onto the virtual container (labeled VC in figure, step 745), and optionally specifies the properties for the. infrastructure services (step 750). In response, the system associates this infrastructure service with the virtual container (step 755).

40

The system then evaluates any new or changed associations (step 760). The system generates any code necessary to implement the associations (step 765), and transmits and installs the generated code as necessary (step 770) . In this way, the user is able to fully manage the deployment domain, and to deploy and manage the hosts and services within it, all using a simple and intuitive user interface.
It should be noted that in the exemplary process described above, and other processes described herein, not all steps must be performed at any given time. Furthermore, many of the process steps described above may be performed in any order, or repeated, without changing the nature of the process or the advantages it provides.
It should also be noted, as discussed above, that a similar method can be used when a host or service is first selected, then other services, hosts, or a deployment domain is then associated with that host or service using the drag-and-drop technique above. Similarly, the implementing code will then be generated and installed by the system.
Those skilled in the art will recognize that, for simplicity and clarity, the full structure and operation of all data processing systems suitable for use with the present invention is not being depicted or described herein. Instead, only so much of a data processing system as is unique to the present invention or necessary for an understanding of the present invention is depicted and described. The remainder of the construction and operation

41

of data processing system may conform to any of the various current implementations and practices known in the art.
It is important to note that while the present invention has been described in the context of a fully functional system, those skilled in the art will appreciate that at least portions of the mechanism of the present invention are capable of being distributed in the form of instructions contained within a machine usable medium in any of a variety of forms, and that the present invention applies equally regardless of the particular type of instruction or signal bearing medium utilized to actually carry out the distribution. Examples of machine usable mediums include: nonvolatile, hard-coded type mediums such as read only memories (ROMs) or erasable, electrically programmable read only memories (EEPROMs), user-recordable type mediums such as floppy disks, hard disk drives and compact disk read only memories (CD-ROMs) or digital versatile disks (DVDs), and transmission type mediums such as digital and analog communication links.
Although an exemplary embodiment of the present invention has been described in detail, those skilled in the art will understand that various changes, substitutions, variations, and improvements of the invention disclosed herein may be made without departing from the spirit and scope of the invention in its broadest form.
None of the description in the present application should be read as implying that any particular element, step, or function is an essential element which must be included in the claim scope: THE SCOPE OF PATENTED
42

WE CLAIM:
1. A data processing system having at least a processor and accessible memory, the said
system comprising:
means adopted to receive a selection of a deployment domain (300);
means adopted to receive an instruction to associate an object(510) with the
deployment domain(300);
means adopted to choose a method necessary to associate the object with the
deployment domain(300); and
means adopted to perform the method, characterized in that method is chosen
according to pre-defined mappings of metadata(330) to an underlying platform.
2. The data processing system as claimed in claim $, wherein the object is a host data
processing system.
3. The data processing system as claimed in claiml, wherein the object is a service
implementation software module.
4. The data processing system as claimed in claim $, wherein the object is an
infrastructure service software module.
5. The data processing system as claimed in claim $, wherein the selection is received in
a graphical user interface (500).
6. The data processing system as claimed in claim $, wherein the instruction is made by
dropping an icon representing the object onto a graphical user interface screen portion
associated with the deployment domain (300).
7. The data processing system as claimed in claim |, further comprising means for
receiving property information associated with the object.
Dated this the 29th day of June, 2005

SYSTEM FOR MANAGING SERVICES

Documents:

Inventors:

PCT Conventions: