International Business Machines Corporation

Ali P Arsanjani

Ahamed Jalaldeen

Siddharth N Purohit

Kerrie Lamont Holley

Shuvanker Ghosh

Abdul Allam

Gandhi Sivakumar

Faried Abrahams

Yi-Min Chee

Liang-Jie Zhang

Kerard R Hogg

Shihabudheen V Kavungathodika

Dilip S Muthukurussi Mana

DingDing Lu

Dingding Lu

Seamless transition from a Component Business Model (CBM) to a Services Oriented Architecture (SOA) is achieved by converting a tabular representation of a CBM Heat Map to a Unified Modeling Language (UML) representation, and automatically converting the UML representation of a CBM Heat Map to a first iteration of input used during the subsequent SOA solution development using Service Oriented Modeling and Architecture (SOMA).

System and method for transforming a component business model

A method and system defines a mechanism to architect and define extensible methods and processes to build hybrid solutions. Solution templates provide a mechanism to architect and define the software development method in an extensible way and it enables the method architecture to be flexible to assemble method content and process elements only for those solution types that are necessary for a given solution. Solution templates keep the common base method lightweight and reusable and control the proliferation of software development processes necessary to build hybrid solutions by defining the solution templates for each of the solution types as pluggable extensions or add-ons to the base method that can be assembled on demand based on project needs.

Architecting and defining extensible methods and processes to build hybrid solutions

Provided herein are approaches to re-factor, rationalize, and prioritize a service model, and to assess service exposure in the service model. At least one approach provides: determining a granularity of a service of the service model; re-factoring and refining a service portfolio and a hierarchy of the service model; adapting a Service Litmus Test (SLT) and service exposure scope to the service model; applying at least one Service Litmus Test (SLT) to the service model; and verifying, with each affected stakeholder associated with the service model, that the service model achieves business and technical needs based on the results of the SLTs, which include tests to make exposure decisions, including whether to expose the service or not expose the service, wherein the service represent business capabilities and are placed in the hierarchy of the service model which represents the granularity.

Re-factoring, rationalizing and prioritizing a service model and assessing service exposure in the service model

Selectively permitting or denying usage of a service available on a device is provided. Usage restrictions on usage of services available on the device are maintained, the usage restrictions including customizable restrictions on usage of the services available on the device. A usage restriction for a service indicates usage parameter(s) of the device under which the service is usable or is unusable to users of the device. Based on detecting an event associated with the device, current usage parameter(s) of the device are identified and compared to usage parameter(s) indicated by a usage restriction to determine whether the service is to be usable or unusable. Usage of the service by a user of the device is then permitted or denied based the comparison.

Selectively permitting or denying usage of wearable device services

Provided herein are approaches to re-factor, rationalize, and prioritize a service model, and to assess service exposure in the service model. At least one approach provides: determining a granularity of one or more services of the service model; re-factoring and refining a service portfolio and a hierarchy of the service model; adapting a Service Litmus Test (SLT) and service exposure scope to the service model; applying Service Litmus Tests (SLTs) to the service model; and verifying, with each affected stakeholder associated with the service model, that the service model achieves business and technical needs based on the results of the SLTs, which include tests to make exposure decisions, including whether to expose the service or not expose the service, wherein the service represent business capabilities and are placed in the hierarchy of the service model which represents the granularity.

Techniques are provided for service-oriented (SOA) process decomposition and service modeling. In one aspect of the invention, the techniques include identifying meta-data entities, attributes of the meta-data entities and relationships between stereotypes of the meta-data model, managing the meta-data model for creating, modifying and removing modeling artifacts, and creating modeling templates from the meta-data model to facilitate addressing at least one need of industry-specific applications. In another aspect the invention, the techniques include packaging the method for SOA process decomposition and service modeling, facilitating lifecycle management of modeling assets, and facilitating maintenance of the modeling assets.

Method and apparatus for service-oriented architecture process decomposition and service modeling

The method of the present invention to re-factor, rationalize, and prioritize a service model and to assess service exposure in the service model is illustrated. The service model is reviewed and re-factored and the service portfolio and service hierarchy are refined, exposure decisions are made, and finally the service model and its constituent parts are rationalized based on the re-factoring and exposure decisions. Another technique called Service Litmus Tests (SLTs) is leveraged during service re-factoring and rationalization. SLTs are set of gating criteria to select and filter a set of (candidate) services from the service portfolio for exposure. A Service Exposure Assessment Toolkit (SEAT) is also presented in the present invention. SEAT is a mathematical model to facilitate making exposure decisions for services and prioritizing the services in the service model.

An approach is presented for specifying categories of data elements during a service specification phase of a service-oriented architecture (SOA) life cycle defined in a service modeling methodology like Service-Oriented Modeling and Architecture (SOMA). A Unified Modeling Language based SOA modeling tool for the service modeling methodology includes a middleware based integration plug-in that categorizes service-specific data elements as transaction elements, glue elements, core Common Information Model (CIM) elements, and elements extending the CIM elements, and associates the categorized data elements with corresponding operations of the service being modeled.

Data element categorization in a service-oriented architecture

A service re-factoring method and system. The method includes selecting by a computing system, a first service comprising a first name. The computing system receives a second name for a second service to be generated from the first service. The computing system executes a service refactoring software application, adjusts a granularity of the first service, and generates the second service. The computing system retrieves first traceability links associated with the first service and a first value associated with a first service identification technique. The first traceability links are created within the second service. The computing system generates a second value associated with a second service identification technique. The first service, the first name, and the first value are removed from the computing system. The computing system stores the second service, the second name, the second value, and the first traceability link.

Service re-factoring method and system

An SOA solution architecture generation method and system. The method includes retrieving by a computing system, a service model and an SOA solution architecture model. The computing system retrieves and loads a configuration file comprising mapping data. The mapping data comprises data associating elements of the service model to architectural layers of the SOA solution. Each element is processed. The computing system identifies each architectural layer that corresponds to an associated element based on the mapping data. Each element is placed in an associated layer of the architectural layers. The computing system generates a UML model. The UML model comprises each element in an associated layer of the architectural layers. The computing system loads the UML model.

Architecture view generation method and system

A method and system for specifying categories of data elements during a service specification phase of a service-oriented architecture (SOA) life cycle defined in a service modeling methodology like Service-Oriented Modeling and Architecture (SOMA). A Unified Modeling Language based SOA modeling tool for SOMA methodology includes a middleware based integration plug-in that categorizes retrieved service-specific data elements as transaction elements, optional controller elements, glue elements, optional extension patterns, extension elements and core Common Information Model entities, and associates the categorized data elements with corresponding operations of the service being modeled. A user interface provided by the plug-in enables input of the data elements into the categories and input of the associations between the categorized data elements and corresponding operations of the service being modeled. Furthermore, the plug-in generates and initiates storing of a service specification based on the categorization of the data elements.

Growing community of inventors

Fairfield, IA, United States of America

Ali P Arsanjani