Browse Prior Art Database

A Method and System for Determining Dynamic Component Runtime Behavior Using Static Analysis

IP.com Disclosure Number: IPCOM000239465D
Publication Date: 2014-Nov-10
Document File: 5 page(s) / 178K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method and system for determining dynamic component runtime behavior using static analysis.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 5

A Method and System for Determining Dynamic Component Runtime Behavior Using Static Analysis

In a Service Oriented Architecture (SOA) programming paradigm such as Service Component Architecture (SCA) a service may be invoked either synchronously or asynchronously. Whether a service is invoked synchronously or asynchronously carries major implications in the runtime behavior of the service. A transaction

context may not be propagated if a service is invoked asynchronously. Error reporting behaviors may differ between synchronous and asynchronous interactions. Disclosed is a method and system for determining dynamic runtime behavior of a component using static analysis.

Figure 1

In an exemplary embodiment, a service named Service A may invoke two other services, i.e. Service B and Service C. The services B and C in turn invoke a number of services downstream. A tree like assembly is formed as shown in Fig.1. In the context of a SCA application, each service may be of different implementation type. The implementation type may be one or more of a short running business process, long running business process and simple Java* implementation.

Alternatively the implementation type may be one or more binding implementations

capable of integrating with external services such as, for example, a web service. Each implementation type may have individual interaction characteristics. The interaction characteristics may be used for performing a static analysis.

A meta-data model corresponding to invoked services is as depicted in Fig.2.

1


Page 02 of 5

Figure 2

The meta-data model may be structured as two directed graphs corresponding to an invocation assembly. Each node represents a wire in the service component assembly. Each wire may maintain a link to its source node and its target node. Runtime information may be stored in a wire node. The meta-data model may be useful for capturing results from various analyses. A flowchart in Fig.3 summarizes steps involved in an analysis.

2


Page 03 of 5

Figure 3

At step 1, a custom model is generated. The custom model corresponds to a service assembly required to be analyzes. For an edge centric graph implementation, a linked list may be used to capture each invocation path. Subsequently at step 2, a component level analysis is performed. The characteristics of the component type implementation may be required to perform the component level analysis. Some exemplary but non limiting implementations such as long running business processes may only tolerate asynchronous interactions. Asynchronous behavior of each service component type may be

inferred to determine how a given service will be interacted. Later at step 3, assembly level analysis is performed. The component level analysis may look at the services from an application assembly in isolation. Assembly level analysis takes

into account how wiring of differe...