풍차의 블로그

TESTRT - TP.dll 또는 TP.so 사용법

2012-01-12T11:06:00.001+09:00

* c/cpp 혼합인 경우에 쓸수 있는 환경변수
ATL_FORCE_C is off (default)
ATL_FORCE_CPLUSPLUS is off (default)
ATL_FORCE_C_TDP is off (default)

* tp.dll 또는 tp.so 등 공유라이브러리 사용시 쓸수 있는 환경변수
ATL_NO_TDP_COMPILE is off (default)
ATL_SHARED_TDP is off (default)

ATL_NO_TDP_COMPILE
If set, the Target Deployment Port Library is never compiled, even at link time
ATL_SHARED_TDP
If set and used in conjunction with ATL_NO_TDP_COMPILE, it must contain
the name of the shared library containing the TP.o[bj] file to be put
in place of TP.o[bj] on the link command line

1) attolcc를 사용하는 경우 예제
On Suse 7.2 or RedHat 7.2
cmd> attolcc -force_tdp_cc --cflags=-fPIC
cmd> ld -shared -rpath `pwd` TP.o -o TP.so
cmd> export ATL_NO_TDP_COMPILE=on
cmd> export ATL_SHARED_TDP=TP.so
cmd> attolcc -- cc -g -o toto toto.c
cmd> ldd ./toto
TP.so => TP.so (0x40018000)
libc.so.6 => /lib/libc.so.6 (0x40039000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

On SuSe 8.0
cmd> attolcc -force_tdp_cc --cflags=-fPIC
cmd> ld -Wl,-rpath,. TP.o -o TP.so
cmd> export ATL_NO_TDP_COMPILE=on
cmd> export ATL_SHARED_TDP=TP.so
cmd> attolcc -- cc -g -o toto toto.c
cmd> ldd ./toto
TP.so => TP.so (0x40018000)
libc.so.6 => /lib/libc.so.6 (0x40039000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

2) 일반적인 빌드 경우 예제 - 다소 옛날식...

[build.bat]
------------------------------------------------------------------------
del *.exe *.dll *.obj *.fdc *.tsf *.tpf *.tqf *.tdf *.tio *.spt *.pdb *.ilk *.lib *.idb *.exp Products.h
set CC=cl /MDd /Zi
set LD=link /INCREMENTAL:NO /debug

rem compil the dll sources
%CC% -c mydll.cpp
%CC% -c mydll2.cpp

rem generate the dll
%LD% /dll /machine:I386 /out:"mydll.dll" mydll.obj
%LD% /dll /machine:I386 /out:"mydll2.dll" mydll2.obj

rem compil the main application
%CC% -c example.c

rem link the main app with its dll
%LD% example.obj

rem run app without any instrumentation
example.exe
pause

del *.exe *.dll *.obj *.pdb *.ilk *.lib *.idb *.exp

rem do the same thing with instrumentation
set ATLTGT=%TESTRTDIR%\targets\cvisual6
set OPTIONS=-proc=ret -block=implicit -mempro
set CC=%ATLTGT%\cmd\attolcc %OPTIONS% -verbose -force_tdp_cc -- %CC% -DRTRT_RMDLL
set ATL_SHARED_TDP=TP.lib
set LD=%ATLTGT%\cmd\attolcc %OPTIONS% -verbose -force_tdp_cc -- %LD%
rem make the TP.dll

rem compil the dll sources and the TP thanks to -force_tdp_cc
%CC% -DRTRT_UNLOADABLE -DRTRT_RMDLL -c mydll.cpp
%CC% -DRTRT_UNLOADABLE -DRTRT_RMDLL -c mydll2.cpp

rem generate the TPdll.dll
del tp.obj
cl -c -DRTRT_RMDLL -I. "%ATLTGT%\lib\tpdll.cpp"
link /INCREMENTAL:NO /dll /debug /machine:I386 /out:"TP.dll" /implib:"TP.lib" TPdll.obj

rem generate the dll
%LD% /dll /machine:I386 /out:"mydll.dll" mydll.obj
%LD% /dll /machine:I386 /out:"mydll2.dll" mydll2.obj

rem compil the main application
%CC% -c example.c

rem link the main app with its dll
%LD% example.obj

rem run app with instrumentation
example.exe

atlsplit atlout.spt
rem studio *.fdc *.tsf *.tpf *.tqf *.tdf *.tio
------------------------------------------------------------------------

3) TestRT GUI이용시 예제
TestMyLib->Settings->Build->Target Deployment Port->TDP output format : Dynamic Libary

openSUSE - vmware-config-tools.pl 요구사항

2012-01-09T22:14:00.000+09:00

1. Become root
2. Install gcc, kernel-source, kernel-syms, make, binutils
# yast2 --install gcc kernel-source kernel-syms make binutils
3. cd /usr/src/linux
4. make cloneconfig
5. make modules_prepare

That should generate the kernel-headers that /usr/bin/vmware-config-tools.pl requires.

Purify - 기본 사용법

2012-01-09T22:12:00.000+09:00

출처 : http://www.ibm.com/developerworks/rational/library/06/0822_satish-giridhar/

Purify는 프로그램 실행 분석을 통해 프로그램에서 발생하는 메모리 에러를 탐지합니다. 프로그램의 적절한 위치에 추가코드를 삽입한 후 해당 프로그램의 실행을 통해 메모리에 대한 데이터 수집 및 검증을 수행합니다. 메모리 체크 실패시 해당 에러를 보고를 하며, 프로그램 종료시점에 메모리 누수 블럭에 대한 스캔을 수행합니다(물론 중간에 누수 스캔 요청을 할 수 있습니다).

Purify는 프로그램과 라이브러리 오브젝트 코드에 삽입을 합니다. 이 과정을 오브젝트 코드 삽입 object code instrumentation (OCI)이라 합니다. Purify는 오브젝트 코드에 삽입을 하며, 소스코드에 삽입하는 것이 아님을 알아두시기 바랍니다. 때문에 소스코드가 없는 써드파티 라이브러리에 대한 메모리 체크가 가능합니다.

여러분의 코드를 디버그 옵션으로 컴파일한다면, Purify는 디버그 정보를 활용하여 에러를 소스라인과 연계할 수 있으며, 에러 보고시에 관련 코드를 보여줄 수 있습니다. 디버그 정보를 포함하지 않는 부분에는, 에러를 오브젝트 코드 정보, 예를 들어 프로그램 카운터(PC), 명령어 등과 에러를 연계할 수 있습니다.

Purify는 메모리 사용 에러와 함께 함수 콜 체인 정보를 보고합니다. 써드파티 라이브러리에서 에러가 발생한 경우에도, 여러분의 소스코드로 부터 라이브러리에 있는 함수를 호출할겁니다. 그러므로 콜 체인에서 소스있는 디버그 정보를 통해 여러분의 코드 어느부분에서 해당 라이브러리 함수를 호출했는 지 파악할 수 있습니다. 이는 에러가 발생한 경우에 대한 귀중한 단서를 제공합니다. 이러한 정보로 부터, 에러가 여러분의 코드에서 발생한 것인지(예를 들어, 초기화하지 않은 인자를 라이브러리에 넘긴 경우) 아니면 써드파티 라이브러리에서 발생한 것인지(예를 들어 라이브러리에 초기화하지 않은 변수가 있는 경우)를 분석할 수 있습니다.

Purify는 다음 단계들과 관련있습니다:

디버그 옵션으로 여러분의 코드를 컴파일합니다
Purify를 이용해 바이너리에 오브젝트 코드를 삽입합니다
삽입처리된 프로그램을 실행합니다
Purify가 보고한 에러를 조사하고 수정합니다

삽입처리 과정은 윈도우즈와 유닉스 플랫폼 간 차이점이 있습니다. 플랫폼별 Purify에 대한 사용방법은 아래 내용을 참고합니다.

윈도우즈 플랫폼에서의 Purify 사용방법

윈도우즈 플랫폼에서, Purify를 사용하는 방법은 두가지 방법이 있습니다:

첫번째 방법: Purify를 Microsoft® Visual Studio® IDE에 통합 설치를 하고, Purify 연계 또는 비연계를 버튼으로 지정할 수 있습니다. Purify를 연계한 경우, 프로젝트 빌드를 하면, Purify는 자동으로 빌드하는 실행파일에 삽입처리를 합니다. 해당 프로그램을 실행하면, Purify의 에러체크 코드가 실행되고 IDE에 에러를 메모리사용 통계와 함께 보고합니다.
두번째 방법: Purify GUI를 사용하여 프로그램 삽입처리 및 다양한 삽입처리 옵션 설정을 합니다. 삽입처리된 프로그램을 실행하면, Purify GUI 내 윈도우에 에러를 표시합니다. 아래에서는 프로그램 삽입처리, 삽입처리된 프로그램 실행, 보고된 에러조사 등의 단계에 대해 기술합니다.

Purify는 "정밀" 에러체크를 위해서 Visual Studio의 디폴트 설정에서 만들지 않는 재배치 정보를 필요로 합니다. /fixed:no 와 /incremental:no 등의 링커 옵션을 사용하면 재배치 정보를 추가할 수 있습니다. 재배치 정보가 없는 경우, Purify는 "최소" 에러체크를 시행합니다.

프로그램에 대한 삽입처리 및 실행을 하기 위해, 먼저 Purify를 띄우고 아래 단계를 따릅니다:

memerrors.c 파일 (Download 참조)을 디버그옵션을 이용해 컴파일하고 실행 프로그램을 생성합니다.
File > Run을 선택하여 Run Program 대화상자 (Figure 1) 를 띄웁니다.
Program name 상자에 실행 파일 경로를 지정합니다.
Collect 옵션에서 Error and leak data 선택 버튼을 클릭합니다.
프로그램 실행 후에도 콘솔을 유지하기 위해 Pause console after exit 체크 박스를 선택합니다.
(옵션) Settings를 클릭하여 Purify 설정을 변경합니다.
Run을 클릭합니다.

Figure 1. Run Program dialog to instrument an executable program

Purify는 바이너리 파일을 삽입처리하고 프로그램을 실행합니다. Figure 2와 같이 프로그램 및 관련 라이브러리들에 대한 삽입처리 과정을 보여줍니다.

Figure 2. Instrumentation Progress of the executable and DLLs

삽입처리가 끝나면, 프로그램을 실행됩니다. 실행 중, Purify는 탐지한 메모리 엑세스 에러를 보고합니다. 말미에, Purify는 메모리 누수에 대한 보고를 합니다. Figure 3에서 처럼 Purify 에러와 누수 보고서를 보여줍니다.

Figure 3. Memory errors found by Purify (on Windows)

Purify는 에러, 경고, 메모리 누수에 대한 요약 등을 보고합니다. 에러를 클릭하면, 통계, 스택 추적, 라인 번호 등 자세한 정보를 알수있습니다. 예를 들어, array bounds read (ABR) 에러를 클릭하면, 에러 위치와 메모리 할당 위치를 볼수 있습니다(Figure 4). 에러 위치의 소스코드를 보면, ABR 에러가 memerrors.c 파일의 100번째 라인 즉, 스트링 str이 printf 함수로 전달되는 라인에서 발생했습니다. printf 함수는 스트링 str을 NULL바이트를 만날때까지 처리합니다. 여기서는 printf 함수 호출 전에, name으로 부터 10바이트를 str로 복사를 했고, str[11]에 NULL을 설정하여 스트링을 끝처리 했습니다. 그래서 printf는 필시 11 바이트를 읽게 되었습니다. 메모리 할당 위치를 보면, memerrors.c 파일의 107 라인에서 str은 10개의 문자를 갖도록 할당되었습니다. 이를 종합해 보면, str[11]은 배열의 범위 밖을 엑세스하게 되어, array bounds read (ABR) 에러가 발생한 것입니다. 이는 NULL 문자열 끝처리와 배열의 크기에 관련된 오해에서 비롯된 전형적인 에러입니다.

Figure 4. Details of ABR error including source code and line number information (on Windows)

Purify가 보고한 각각의 에러를 조사합니다. Purify가 제공한 상세한 정보의 도움을 받아, 에러에 대한 디버그와 수정작업을 합니다. 결함 수정 후에는 다시 Purify를 실행하여 에러가 없다는 것을 검증합니다.

Purify는 다양한 맞춤 설정 옵션을 통해서 여러분의 요구에 맞는 분석 유형에 탄력적으로 대응합니다. 여러분이 수정할 수 없는 써드파티 라이브러리에서 발생하는 에러를 보고에서 억제하는 방법 또한 제공합니다.

아래 단계는 윈도우즈 플랫폼에서 UMC 에러, 그와 관련된 스택 변수를 명시하기 위한 단계를 제시합니다:

Run Program 대화상자(Figure 1)에서 Settings를 클릭합니다.
Errors and Leaks 탭에서 Show UMC messages (Figure 5)를 체크합니다.
Files 탭에서 Additional options 박스 (Figure 6)에 -stack-load-checking을 입력하여, Purify가 스택변수에 UMR 에러를 체크하도록 합니다.
OK를 클릭하고 Run을 클릭합니다.
Purify가 실행하면 UMC 메모리 사용 에러를 보고합니다(Figure 3).

Figure 5. Tick the Checkbox "Show UMC messages" in the Settings dialog (on Windows)

Figure 6. Additional options to check UMR errors on stack variables (on Windows)

여러분은 필터를 정의하여 관심없는 에러 보고를 억제할 수 있습니다. Purify 좌측 영역에서, Run을 우클릭하고 Filter Manager 대화상자를 선택합니다 (Figure 7). Purify는 특정 에러 유형, 특정 콜 스택상의 또는 특정 라이브러리의 에러에 대한 억제할 수 있는 기능을 제공합니다.

Figure 7. Invoking Filter Manager to suppress uninteresting errors (on Windows)

Purify 기능에 관련된 자세한 내용은 Help 메뉴을 참고합니다.

유닉스/리눅스 플랫폼에서의 Purify 사용방법

UNIX 플랫폼상에서는 프로그램을 삽입처리하는 다양한 방법이 있습니다. 가장 간단한 방법은 프로그램 빌드하는 커맨드라인에 purify를 접두어로 추가하는 방법입니다.

예를 들어, 아래와 같이 memerrors.c (Download 참조)파일을 빌드하여 a.out를 생성합니다:
ksh% cc -g memerrors.c

여기에 purify를 접두어로 추가시키면, 삽입처리된 a.out을 빌드합니다:
ksh% purify cc -g memerrors.c

만약 Makefile를 이용해 프로그램을 빌드한다면, 삽입처리용 빌드타겟을 추가할 수 있습니다:
a.out: foo.c bar.c
$(CC) $(FLAGS) -o $@ $?
a.out.pure: foo.c bar.c
purify $(CC) $(FLAGS) -o $@ $?

빌드 타켓을 복사하는 경우 아래 두가지 변경만이 필요합니다 (위의 a.out의 경우):

빌드 타겟 이름을 변경합니다 (a.out.pure).
빌드 타켓 커맨드에 purify를 접두어로 추가합니다.

삽입처리는 모든 플랫폼에서 링크시에 실행됩니다. AIX에서는, 실행파일에 바로 삽입처리를 적용할 수 있습니다:
ksh% purify a.out

아래는 AIX에서 memerrors.c 파일을 컴파일, 삽입처리, 실행시 로그를 보여줍니다:

ksh % cc -g memerrors.c
ksh % purify a.out
Purify 7.0 AIX (32-bit) (C) Copyright IBM Corporation. 1992, 2006 All Rights Reserved.  
Instrumenting: a.out. libc.a,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,.......,,,,, libcrypt.a., 
Instrumented a.out is a.out.pure.
Done.
ksh % ./a.out.pure

삽입처리된 프로그램을 실행하면 Purify GUI는 메모리 에러를 탐지하면 바로 나타냅니다(Figure 8).

Figure 8. Memory errors found by Purify (on UNIX)

에러를 클릭하면 자세한 정보를 얻을 수 있습니다. Figure 9는 ABR 에러에 대한 자세한 정보를 보여줍니다. 이 정보로 부터 memerrors.c의 107번째 라인에서 NULL 처리된 str 메모리를 할당받았다는 것을 알수 있습니다. 하지만 genABRandABW에서 잘못 계산한 까닭에, name 스트림을 str로 복사한 후에, NULL 바이트가 str[11]에 저장되었습니다. 이로 인해 printf가 str의 범위 밖을 읽게되어 array bounds read (ABR) 에러가 110번째 라인에서 발생했습니다.

Figure 9. Details of ABR errors, including source code and line number information (on UNIX)

유닉스 및 리눅스 시스템상에서 Purify는 모든 UMC 에러와 관련된 스택변수를 추적합니다. 디폴트로 해당 에러는 억제되어 있습니다. 억제된 에러를 보려면 View > Suppressed messages (Figure 10)를 선택합니다.

Figure 10. Seeing suppressed errors (on UNIX)

관심없는 에러 보고를 억제하는 방법은 간단합니다. 에러유형을 선택하고 우클릭후 Suppress 메뉴를 선택합니다(Figure 11).

Figure 11. Suppressing an error (on UNIX)

Purify 기능에 대한 자세한 정는 Help 메뉴를 사용합니다.

Purify - Daily 빌드 및 테스트과의 연계

2012-01-09T21:39:00.001+09:00

출처 : http://www.ibm.com/developerworks/rational/library/08/0513_gupta-gaurav/index.html

Purify is a very useful tool throughout the software development life cycle.

Developers can use it to ensure that the new code that they have written is not going to inadvertently cause any memory corruption errors or leaks.
Test engineers can use it to catch memory errors during functional verification and system integration testing.
And field and support engineers can use it to diagnose memory issues encountered after the software has been deployed.

Because the cost of detecting and fixing a defect is least during early phases of the software development life cycle, it is best to catch and fix as many issues as possible during development and testing phases. You can achieve that ideal by methodical and systematic use of Purify throughout the software development life cycle. The best way to accomplish this is by automating the use of Purify and integrating it into your software development and testing process.

Automation of a tool eliminates the overhead and makes it effortless to use, which in turn reduces the resistance to its adoption as part of the process. Thus, automation is the key in streamlining the process. For example, you can integrate Purify with your unit or smoke test suite that developers must run before checking in any code changes and require them to fix any new memory errors reported by Purify. In this way, an error is caught as soon as it is introduced and fixed easily, because the code changes are still fresh in the developer's mind. Similarly, you can integrate Purify with your functional and system verification test suite, which you might be running nightly or weekly. Testers can analyze and file defect reports for memory errors reported by Purify. This ensures that new memory errors are caught within a day or a week from the time that they were introduced, which is much better than catching them after releasing the software.

You can learn about using Purify and integrating it into your build makefiles in the article: Navigating C in a leaky boat? Try Purify. If you are already familiar with Purify, you can skip or skim that article. In this article, you will first learn how to change your build and test environment to incorporate Purify into it and about conversions symbols that you can use with Purify options to automate using Purify. Then you will see an example where all of these capabilities are exploited to automate reporting a summary of Purify errors on a Web page.

Incorporating Purify into your build and test environment

The first step in integrating Purify into your software development and testing process is to modify your build and test system. The build system builds an application and the test system runs the application with a test suite (shown in blue in Figure 1). Typically, the process of building the application and running the test suite is automated and scheduled as nightly or weekly jobs.

You need to modify your build system to build a Purify'd application along with the normal application. Normally, you will be building the application without having any debug information (release bits). For building a Purify'd application, it is advisable (although not required) to build the application with debug information (debug bits), and then purify it.

You also need to modify your test system to run the test suite with the Purify'd application, in addition to running it with the normal application. These additional build and test steps are shown in green in Figure 1. After making these changes, add building the Purify'd application and running it with your test suite to your automated nightly or weekly jobs. Later in this article, you will learn about various ways of controlling and automating the actions to be taken when Purify detects memory errors or leaks.

Figure 1. Modifications in the build and the test systems

Using conversion symbols

Purify provides various conversion symbols that you can use to specify values for various options, such as


                    -view-file

and


                    -log-file

(these options send Purify output to a Purify view file and to an ASCII log file, respectively). Purify replaces these symbols by meaningful expansions and computes a unique file name for saving data. For example, you can put the program name and process ID in the name of log file:

$ purify -log-file=./purifyerrors_%v_%p.plog cc -o progname foo.c bar.c

This command will create an instrumented executable named progname. If you run this, and the process ID for that run is 1234, all Purify errors will be logged in a file named purifyerrors_progname_1234.plog. In the log file name, Purify expands %v to the program executable name and the %p to the process ID.

Adding operations after a Purify run

Automating what happens before running your instrumented application is easy, because you have all of the controls. You can control and automate what happens after running the application by exploiting various Purify features that let you add custom post-processing tasks. Purify enables you to run a script after exiting the instrumented application. You can use this to report a summary of all of the errors reported after the instrumented program exits. To do this, you use the Purify


                    -run-at-exit

runtime option.

For example, if your instrumented application is test.pure, you can use this option as follows to print a summary of errors found:

$ setenv PURIFYOPTIONS '-run-at-exit="if %z ; then \
  echo \"%v : %e errors, %l bytes leaked.\" ; fi"'

The string that follows the


                    -run-at-exit

option is executed by the shell after the program exits. Conversion symbol substitutions are made, such as turning %z into false if there were no Purify errors or leaks during the run. Because of that, the if statement in this example says: "Execute the 'echo' only if there were errors." The echo command, in turn, uses more substitution strings to report how many errors there were. Upon exiting the program, Purify sends a message similar to one:

$ test.pure
test.pure : 2 errors, 10 bytes leaked

This is a simple example. However, you can put complex processing into a script, or even in a program, and pass various conversion symbols as arguments to the script or program. For example:

$ setenv PURIFYOPTIONS '-run-at-exit="postprocess.csh %v %z %e %l "'

Table 1 and Table 2 show more details of the substitution strings for conversion symbols.

Table 1. Conversion symbols that can be used with Purify options

Character	Converts to
%v	Program executable name, lowercase V (name of the instrumented executable that you are running)
%V	Full path name of the program, uppercase V (/ replaced by _)
%p	Process ID (pid or PID)

Table 2. Conversion symbols that can be used in Exit-command (-run-at-exit)

Character	Converts to
%z	String value `true` or `false`, indicating whether any call chains for errors or leaks were printed (use it to have your exit script act conditionally when Purify finds something of interest to you)
%x	Program's exit status (0 if the program did not call an exit)
%e	Number of distinct access errors printed (displayed)
%E	Total number of errors printed
%l	Number of bytes of memory leaked (lowercase L)
%L	Number of bytes of memory potentially leaked (uppercase L)

Using program exit status

You have already learned how to run your scripts at the end of instrumented program run. Purify also gives you some information through its exit status. By default, Purify does not modify the normal exit status of your program. However, you can choose to have your program exit with a special exit status if Purify finds any access errors or memory leaks. This is a convenient way to flag failing runs in test suites. Use the


                    -exit-status=yes

option to enable Purify to insert flags that indicate types of runtime errors. If there are unsuppressed Purify errors, the status code is computed by doing bit-wise OR of the following values, depending upon the type of memory error present:

0x40: Memory access errors
0x20: Memory leaks
0x10: Potential memory leaks

Alternatively, you can replace the calls to


                    exit(status)

in your code and the


                    return

statement in main() function with a call to the


                    purify_exit(status)

function. (See Resources for the article on Purify Application Programming Interface functions.) If you are concerned only about the memory access errors, you can either turn off leak detection at exit by using the


                    -leaks-at-exit=no

option, or you can suppress memory leak and potential leak messages. You can also ignore the appropriate bits of exit status. However, the program summary message in the Purify report always shows your original exit status before any other Purify result status bits are OR'ed into it.
Listing 1 is an example that exploits the


                    -exit-status

option and uses the exit status to determine whether any errors were found in the program.

Listing 1. Exit status option example

                
$ cat prog.c
#include <stdio.h>

int main() {
    int i,j;
    i = j+1;  /* UMR: Reading un-initialized variable j */
    return 0;
} 

$ purify -exit-status=yes cc -g prog.c -o prog.pure
$ prog.pure
$ echo $?
64

The exit value is not 0 (zero), as returned in function main. It is 64, which is 0x40 in hexadecimal. That is because Purify detects an Uninitialized Memory Read (UMR) memory access error in the program. This option can be easily incorporated in a script that checks the exit status after running the Purify'd executable and takes appropriate actions upon finding errors, such as filing a defect report with the test program or noting the result in the Purify log.

If you want your instrumented application to exit upon detecting the first error, you can use the


                    -exit-on-error

option. When you use that option, the program exits the moment that Purify encounters an error (errors that are hidden by using the suppress and kill directives do not count).

Mailing Purify results and assisting analysis

Purify has a


                    -mail-to-user

option that you can use to automate reporting of daily or weekly Purify results. When you use this option, Purify will e-mail the error report to the specified addresses of testers and developers, and they can verify the results when they receive the e-mail. For example, suppose that you purify your program this way:

$ purify -mail-to-user=yourid cc -g prog.c -o prog.pure

When you run the prog.pure executable thereafter, the Purify report will be sent automatically to yourid email address.

Sometimes, while analyzing the errors, it is useful to look at not only the function names but also other details, such as the complete path of the file where it is located or the PC values. You can enable Purify to display such information by using these options:

-show-pc shows you the full PC value
-show-pc-offset shows you the pc-offset from the start of the function
-show-directory shows you the directory listing where the file containing the function exists (requires program build with debugging)

Example

In this section, you will see an example that uses most of the options that you learned about in this article. Listing 2 shows the GNUMakefile that contains modified build and test systems (see Downloads to get the source code used in this article). If the application name is memerrors, a new target is added for building a Purify'd application named memerrors.pure. Similarly, a new target is added to run tests with the Purify'd application.

Purify runtime options are set before running the test. For the -log-file option, a unique log file name is created, using conversion symbols and the date command (the file name includes program name, process ID, date, and time). The -run-at-exit option is used to indicate that, after program exits, the addsummary.sh script should be run, along with the arguments specified through conversion symbols (namely, the log file name, whether any error call chain was printed, exit status, count of memory errors found, size of memory leaks, and potential memory leaks). Since the -exit-status=yes option is not used, Purify will not overwrite the exit status and retain the original exit status of the program.

Listing 2. GNUMakefile with modified build and test systems

                
# Name of Logfile using Purify conversion symbols and date command
DATEANDTIME     := `date +%Y_%b_%d_%H_%M_%S`
LOGFILENAME     := %v_pid%p_$(DATEANDTIME).plog

# Script to run when Purify'ed program exits
PURIFYEXITSCRIPT:= \"addsummary.sh $(DATEANDTIME) $(LOGFILENAME) %z %x %e %l %L\"

# Purify Options
PURIFYOPTIONS   := -log-file=$(LOGFILENAME) -run-at-exit=$(PURIFYEXITSCRIPT)

# Targets and Rules
all: runtest runpurifytest

# Clean
clean:
 $(RM) memerrors memerrors.pure

# Build Application
memerrors: memerrors.c
 $(CC) -o $@ $? 

# Build Purify'ed application
memerrors.pure: memerrors.c
 purify $(CC) -g -o $@ $? 

# Run Test Suite
runtest: memerrors
 ./memerrors

# Run Test Suite with Purify'ed application
runpurifytest: memerrors.pure
 echo Starting test at $(DATEANDTIME) .....
 env PURIFYOPTIONS="$(PURIFYOPTIONS)" ./memerrors.pure

# End of GNUMakefile

The addsummary.sh script shown in Listing 3 creates an HTML report. It maintains a list file that has one HTML table row for each Purify run so far, in reverse chronological order. When the script is executed upon exiting Purify, it creates a new list file that contains an HTML table row for the latest run, appends the file with previous rows, and replaces the old list file with the new list file. Then it generates an HTML file by an wrapping HTML header and footer around the list file.

Listing 3.Content of the addsummary.sh shell script

                
#!/bin/sh

DATEANDTIME=$1
LOGFILENAME=$2
LOGFULLNAME=`pwd`/$LOGFILENAME
ERRORFOUND=$3
EXITSTATUS=$4
ERRORCOUNT=$5
LEAKSIZE=$6
PLEAKSIZE=$7

PURIFYREPORT="purify_reports"
REPORTLIST="$PURIFYREPORT.list"
REPORTNEWLIST="$REPORTLIST.new"
REPORTHTML="$PURIFYREPORT.html"

# Start
echo Processing $LOGFILENAME created at $DATEANDTIME

# Create report list file if it does not exist
touch $REPORTLIST

# Create a row for the latest Purify run
echo "<tr>" >> $REPORTNEWLIST
echo "<td>$DATEANDTIME</td>" >> $REPORTNEWLIST
if ($ERRORFOUND == "true"); then
    echo "<td>FAILED</td>" >> $REPORTNEWLIST
else
    echo "<td>Pass</td>" >> $REPORTNEWLIST
fi
echo "<td>$EXITSTATUS</td>" >> $REPORTNEWLIST
echo "<td>$ERRORCOUNT</td>" >> $REPORTNEWLIST
echo "<td>$LEAKSIZE bytes</td>" >> $REPORTNEWLIST
echo "<td>$PLEAKSIZE bytes</td>" >> $REPORTNEWLIST
echo "<td><a href=\"$LOGFULLNAME\">$LOGFILENAME</a></td>" >> $REPORTNEWLIST
echo "</tr>\n" >> $REPORTNEWLIST

# Add this row at the beginning of the table
cat $REPORTLIST >> $REPORTNEWLIST
mv $REPORTNEWLIST $REPORTLIST

# Create HTML page
# Header
echo "<html>"  > $REPORTHTML
echo "<body>" >> $REPORTHTML
echo "<table border=1>" >> $REPORTHTML
echo "<caption>Purify Test Summary</caption>" >> $REPORTHTML
echo "<tr>" >> $REPORTHTML
echo "<th>Date & Time</th><th>Result</th><th>Exit Status</th>"  >> $REPORTHTML
echo "<th>Errors</th><th>Leaks</th><th>Potential Leaks</th>" >> $REPORTHTML
echo "<th>Log File</th>"  >> $REPORTHTML
echo "</tr>\n" >> $REPORTHTML
# Add rows for Purify results
cat $REPORTLIST >> $REPORTHTML
# Footer
echo "</table>" >> $REPORTHTML
echo "</body>" >> $REPORTHTML
echo "</html>" >> $REPORTHTML

# Done
echo "Successfully updated $REPORTHTML"

# End of addsummary.sh

Figure 2 shows the HTML page generated after three runs of the test suite. Each run is represented by a row, and each row has a hyperlink to the Purify log file. Each successive run of the test suite will add a new row at the beginning of the table.

Figure 2. Purify Test Summary report in the browser

Summary

As this article explains, you get maximum benefits when you use Purify regularly and systematically. You now know how to incorporate Purify into your software development and testing process and to automate its use with the help of conversions symbols and options.
Although the example used in this article is simple, it demonstrates how easy it is to integrate Purify into your build and test environment and the value of automating Purify usage. Think about the simplicity of checking the Purify test results summary on a Web page that gets updated automatically every time your test suite is executed. All existing log files are also accessible through the same Web page. The example here is intentionally simple, just to show you the possibilities. You can create a quite sophisticated system that compares results and sends e-mail notifications with precise details upon finding any additional memory errors and leaks. You can fix them as soon as they are introduced. With this knowledge, you are ready to reap the maximum benefits of Rational Purify.

Purify - 메모리 에러 설명

2012-01-08T20:15:00.000+09:00

출처 : http://www.ibm.com/developerworks/rational/library/06/0822_satish-giridhar/

Introduction
Most programmers agree that defects related to incorrect memory usage and management are the hardest to isolate, analyze, and fix. Therefore, they are the costliest defects to have in your programs. These defects are typically caused by using uninitialized memory, using un-owned memory, buffer overruns, or faulty heap management.

IBM® Rational® Purify® is an advanced memory usage error detecting tool that enables software developers and testers to detect memory errors in C and C++ programs. While a program runs, Purify collects and analyzes data to accurately identify memory errors that are about to happen. It provides detailed information, such as the error location (function call stack) and size of the affected memory, to assist you in quickly locating the problem areas. It also greatly reduces debugging time and complexity, so you can focus on fixing the flaw in the application logic that is causing the error.

Purify is available for all prominent platforms, including IBM® AIX® on Power PC®, HP-UX® on PA-RISC, Linux™ on x86 and x86/64, Sun™ Solaris™ on SPARC®, and the Microsoft® Windows® on x86 (check documentation for updated list of supported platform). In this article, you will first learn about various types of memory access errors with the help of examples, and then learn how to use Purify for detecting and fixing those errors. In the Download section, you will find the C source file (memerrors.c) with the code samples in this article, and you can use them to experiment with Purify.

Memory errors

Memory errors can be broadly classified into four categories:

Using memory that you have not initialized
Using memory that you do not own
Using more memory than you have allocated (buffer overruns)
Using faulty heap memory management

Purify detects errors in all of these categories and identifies the type of the error within a category. Understanding the types of errors helps you identify and isolate subtle mistakes in your program that may cause the program to act strangely and unpredictably. In rest of this section, various error types are explained using code samples.

Using memory that you have not initialized
When you read from memory that you forgot to initialize, you get garbage value. This error looks deceptively innocent, but it has the potential to cause mysterious program behavior.

The garbage value that you get could fortuitously happen to be a meaningful value that your program can handle. For example, some operating systems initialize a memory block with zeros when it is allocated for the first time. If zero is a meaningful value for your program, it may run smoothly, initially. However, after the program runs for a while, the memory might be freed and reallocated. When a memory block is recycled, it has the values that were stored in it when it was last used. These values are unpredictable. Depending upon the value, your program may crash immediately, may run for a while and crash sometime later, or may run smoothly but produce strange results. Since the value could be different in each run, the behavior of the program can be baffling, making it hard to reproduce the problem consistently.

Purify detects such errors and reports an Uninitialized Memory Read (UMR) error for every use of uninitialized memory. It further differentiates between using uninitialized memory and copying value from an uninitialized memory location to another memory location. When an uninitialized memory is copied, Purify reports an Uninitialized Memory Copy (UMC) error. After the copying, the destination location also has uninitialized memory; therefore, whenever this memory is used, Purify reports a UMR.

Listing 1 shows a simple example. There are two integers: i and j. The integer i is initialized with 10. Then the value of j is copied into i. Since j has not been initialized, i also has garbage value after j is copied into it. Purify maintains status of each memory location. It is capable of the analysis that reveals that, although i has been initialized with 10, copying an uninitialized value has made i also uninitialized. Therefore, Purify reports any usage of i (for example, as an argument to printf in the next line) as a UMR error.

Listing 1. An example of UMR and UMC errors

void uninit_memory_errors() {
    int i=10, j;
    i = j;     /* UMC: j is uninitialized, copied into i */
    printf("i = %d\n", i); /* UMR: Using i, which has junk value */
}

This example is intentionally trivial to make it easy for you to identify the problem just by inspecting the code. But real-world applications have many thousands lines of code and have complex control flow. The location where a valid value is corrupted by copying a garbage value into it, could be in a different function, and potentially in a different sub-system or library. If you inspect the bar method in Listing 2, and you do not know much about foo method, you would not suspect that i would be corrupted after calling the foo method. Depending upon the size and complexity of the source code, you may have to spend considerable time and effort to analyze and then to rectify this type of defect. Purify eliminates this effort and reports UMRs, indicating the use of uninitialized memory value.

Listing 2. Another example of UMR and UMC errors

void foo(int *pi) {
    int j;
    *pi = j; /* UMC: j is uninitialized, copied into *pi */
}

void bar() {
    int i=10;
    foo(&i);
    printf("i = %d\n", i); /* UMR: Using i, which is now junk value */
}

As you notice, whenever a memory location with a UMC error is finally used, Purify reports a UMR error for that same memory location. UMC errors may not always be critical, and Purify hides them by default. Later in this article, you will learn how to see UMC and other errors that Purify hides.

Using memory that you don't own
Explicit memory management and pointer arithmetic present opportunities for designing compact and efficient programs. However, incorrect use of these features can lead to complex defects, such as a pointer referring to memory that you don't own. In this case, too, reading memory through such pointers may give garbage value or cause segmentation faults and core dumps, and using garbage values can cause unpredictable program behavior or crashes.

Purify detects these errors. In addition to reporting the type of error, Purify indicates the memory area that the pointer refers to and where that memory has been allocated. This is typically a good clue for identifying the cause of the error. This category includes following types of errors:

Null pointer read or write (NPR, NPW)
Zero page read or write (ZPR, ZPW)
Invalid pointer read or write (IPR, IPW)
Free memory read or write (FMR, FMW)
Beyond stack read or write (BSR, BSW)

Null Pointer Read/Write (NPR, NPW) and Zero Page Read/Write (ZPR, ZPW):
If a pointer's value can potentially be null (NULL), the pointer should not be de-referenced without checking it for being null. For example, a call to malloc can return a null result if no memory is available. Before using the pointer returned by malloc, you need to check it to make sure that isn't null. For example, a linked list or tree traversal algorithm needs to check whether the next node or child node is null.

It is common to forget these checks. Purify detects any memory access through de-referencing a null pointer, and reports an NPR or NPW error. When you see this error, examine whether you need to add a null pointer check or whether you wrongly assumed that your program logic guaranteed a non-null pointer. On AIX, HP, and under some linker options in Solaris, dereferencing a null pointer produces a zero value, not a segmentation fault signal.

The memory is divided into pages, and it is "illegal" to read from or write to a memory location on the zero'th page. This error is typically due to null pointer or incorrect pointer arithmetic computations. For example, if you have a null pointer to a structure and you attempt to access various fields of that structure, it will lead to a zero page read error, or ZPR.

Listing 3 shows a simple example of both NPR and ZPR problems. The findLastNodeValue method has a defect, in that it does not check whether the head parameter is null. NPR and ZPR errors occur when the next and val fields are accessed, respectively.

Listing 3. An example of NPR and ZPR errors

typedef struct node {
    struct node* next;
    int          val;
} Node;

int findLastNodeValue(Node* head) {
    while (head->next != NULL) { /* Expect NPR */
        head = head->next;
    }
    return head->val; /* Expect ZPR */
}

void genNPRandZPR() {
    int i = findLastNodeValue(NULL);
}

Invalid Pointer Read or Write (IPR, IPW):
Purify tracks all memory operations. When it detects a pointer to a memory location that has not been allocated to the program, it reports either an IPR or IPW error, depending on whether it was a read or write operation. The error can happen for multiple reasons. For example, you will get this type of error if you have an uninitialized pointer variable and the garbage value happens to be invalid. As another example, if you wanted to do *pi = i;, where pi is a pointer to an integer and i is an integer. But, by mistake, you didn't type the * and wrote just pi = i;. With the help of implicit casting, an integer value is copied as a pointer value. When you dereference pi again, you may get an IPR or IPW error. This can also happen when pointer arithmetic results in an invalid address, even when it is not on the zero'th page. (See Listing 4.)

Listing 4. An example of IPR and IPW errors

void genIPR() {
    int *ipr = (int *) malloc(4 * sizeof(int));
    int i, j;
    i = *(ipr - 1000); j = *(ipr + 1000); /* Expect IPR */
    free(ipr);
}

void genIPW() {
    int *ipw = (int *) malloc(5 * sizeof(int));
    *(ipw - 1000) = 0; *(ipw + 1000) = 0; /* Expect IPW */
    free(ipw);
}

IPR and IPW are encountered commonly while using functions that return a pointer (e.g. malloc) in 64-bit applications because pointer is 8 byte long and integer is 4 byte long. If the method declaration is not included, compiler assumes that the method returns an integer, and implicitly casts the return value and retains only lower 4 bytes of the pointer value. Purify reports IPR and IPW upon using this invalid pointer. (See Listing 5.)

Listing 5. Another example of IPR and IPW errors

/*Forgot to include following in a 64-bit application:
#include <malloc.h>
#include <stdlib.h>
 */

void illegalPointer() {
    int *pi = (int*) malloc(4 * sizeof(int));
    pi[0] = 10; /* Expect IPW */
    printf("Array value = %d\n", pi[0]); /* Expect IPR */
}

Free Memory Read or Write (FMR, FMW):
When you use malloc or new, the operating system allocates memory from heap and returns a pointer to the location of that memory. When you don't need this memory anymore, you de-allocate it by calling free or delete. Ideally, after de-allocation, the memory at that location should not be accessed thereafter.

However, you may have more than one pointer in your program pointing to the same memory location. For instance, while traversing a linked list, you may have a pointer to a node, but a pointer to that node is also stored as next in the previous node. Therefore, you have two pointers to the same memory block. Upon freeing that node, these pointers will become heap dangling pointers, because they point to memory that has already been freed. Another common cause for this error is usage of realloc method. (See Listing 6 code.)

The heap management system may respond to another malloc call in the same program and allocate this freed memory to other, unrelated objects. If you use a dangling pointer and access the memory through it, the behavior of the program is undefined. It may result in strange behavior or crash. The value read from that location would be completely unrelated and garbage. If you modify memory through a dangling pointer, and later that value is used for the intended purpose and unrelated context, the behavior will be unpredictable. Of course, either an uninitialized pointer or incorrect pointer arithmetic can also result in pointing to already freed heap memory.

Listing 6. An example of FMR and FMW errors

int* init_array(int *ptr, int new_size) {
    ptr = (int*) realloc(ptr, new_size*sizeof(int));
    memset(ptr, 0, new_size*sizeof(int));
    return ptr;
}

int* fill_fibonacci(int *fib, int size) {
    int i;
    /* oops, forgot: fib = */ init_array(fib, size);
    /* fib[0] = 0; */ fib[1] = 1;
    for (i=2; i<size; i++)
        fib[i] = fib[i-1] + fib[i-2];
    return fib;
}

void genFMRandFMW() {
    int *array = (int*)malloc(10);
    fill_fibonacci(array, 3);
}

Beyond Stack Read or Write (BSR, BSW) :
If the address of a local variable in a function is directly or indirectly stored in a global variable, in a heap memory location, or somewhere in the stack frame of an ancestor function in the call chain, upon returning from the function, it becomes a stack dangling pointer. When a stack dangling pointer is de-referenced to read from or write to the memory location, it accesses memory outside of the current stack boundaries, and Purify reports a BSR or BSW error. Uninitialized pointer variables or incorrect pointer arithmetic can also result in BSR or BSW errors.

In the example in Listing 7, the append method returns the address of a local variable. Upon returning from that method, the stack frame for the method is freed, and stack boundry shrinks. Now the returned pointer would be outside the stack bounds. If you use that pointer, Purify will report a BSR or BSW error. In the example, you would expect append("IBM ", append("Rational ", "Purify")) to return "IBM Rational Purify", but it returns garbage manifesting BSR and BSW errors.

Listing 7. An example of BSR and BSW errors

char *append(const char* s1, const char *s2) {
    const int MAXSIZE = 128; 
    char result[128];
    int i=0, j=0;

    for (j=0; i<MAXSIZE-1 && j<strlen(s1); i++,j++) {
        result[i] = s1[j];
    }

    for (j=0; i<MAXSIZE-1 && j<strlen(s2); i++,j++) {
        result[i] = s2[j];
    }

    result[++i] = '\0';
    return result;
}

void genBSRandBSW() {
    char *name = append("IBM ", append("Rational ", "Purify"));
    printf("%s\n", name); /* Expect BSR */
    *name = '\0'; /* Expect BSW */
}

Using memory that you haven't allocated, or buffer overruns
When you don't do a boundary check correctly on an array, and then you go beyond the array boundary while in a loop, that is called buffer overrun. Buffer overruns are a very common programming error resulting from using more memory than you have allocated. Purify can detect buffer overruns in arrays residing in heap memory, and it reports them as array bound read (ABR) or array bound write (ABW) errors. (See Listing 8.)

Listing 8. An example of ABR and ABW errors

void genABRandABW() {
    const char *name = "IBM Rational Purify";
    char *str = (char*) malloc(10);
    strncpy(str, name, 10);
    str[11] = '\0'; /* Expect ABW */
    printf("%s\n", str); /* Expect ABR */
}

Using faulty heap memory management
Explicit memory management in C and C++ programming puts the onus of managing memory on the programmers. Therefore, you must be vigilant while allocating and freeing heap memory. These are the common memory management mistakes:

Memory leaks and potential memory leaks (MLK, PLK, MPK)
Freeing invalid memory (FIM)
- Freeing mismatched memory (FMM)
- Freeing non-heap memory (FNH)
- Freeing unallocated memory (FUM)

Memory leaks and potential memory leaks:
When all pointers to a heap memory block are lost, that is commonly called a memory leak. With no valid pointer to that memory, there is no way you can use or release that memory. You lose a pointer to a memory when you overwrite it with another address, or when a pointer variable goes out of the scope, or when you free a structure or an array that has pointers stored in it. Purify scans all of the memory and reports all memory blocks without any pointers pointing to them as memory leaks (MLK). In addition, it reports all blocks as potential leaks, or PLK (called MPK on Windows platforms) when there are no pointers to the beginning of the block but there are pointers to the middle of the block.

Linsting 9 shows a simple example of a memory leak and a heap dangling pointer. In this example, interestingly, methods foo and main independently seem to be error-free, but together they manifest both errors. This example demonstrates that interactions between methods may expose multiple flaws that you may not find simply by inspecting individual functions. Real-world applications are very complex, thus tedious and time-consuming for you to inspect and to analyze the control flow and its consequences. Using Purify gives you vital help in detecting errors in such situations.

First, in the method foo, the pointer pi is overwritten with a new memory allocation, and all pointers to the old memory block are lost. This results in leaking the memory block that was allocated in method main. Purify reports a memory leak (MLK) and specifies the line where the leaked memory was allocated. It eliminates the slow process of hunting down the memory block that is leaking, therefore shortens the debugging time. You can start debugging at the memory allocation site where the leak is reported, and then track what you are doing with that pointer and where you are overwriting it.

Later, the method foo frees up the memory it has allocated, but the pointer pi still holds the address (it is not set to null). After returning from method foo to main, when you use the pointer pi, it refers to the memory that has already been freed, so pi becomes a dangling pointer. Purify promptly reports a FMW error at that location.

Listing 9. An example of a memory leak and a dangling pointer

int *pi;
void foo() { 
    pi = (int*) malloc(8*sizeof(int)); /* Allocate memory for pi */
    /* Oops, leaked the old memory pointed by pi holding 4 ints */
    /* use pi */
    free(pi); /* foo() is done with pi, so free it */
}
void main() {
    pi = (int*) malloc(4*sizeof(int)); /* Expect MLK: foo leaks it */
    foo();
    pi[0] = 10; /* Expect FMW: oops, pi is now a dangling pointer */
}

Listing 10 shows an example of a potential memory leak. After incrementing pointer plk, it points to the middle of the memory block, but there is no pointer pointing to the beginning of that memory block. Therefore, a potential memory leak is reported at the memory allocation site for that block.

Listing 10. An example of potential memory leak

int *plk = NULL;
void genPLK() {
    plk = (int *) malloc(2 * sizeof(int)); /* Expect PLK */
    plk++;
}

Freeing invalid memory:
This error occurs whenever you attempt to free memory that you are not allowed to free. This may happen for various reasons: allocating and freeing memory through inconsistent mechanisms, freeing a non-heap memory (say, freeing a pointer that points to stack memory), or freeing memory that you haven't allocated. When using Purify for the Windows platform, all such errors are reported as freeing invalid memory (FIM). On the UNIX® system, Purify further classifies these errors by reporting freeing mismatched memory (FMM), freeing non-heap memory (FNH), and freeing unallocated memory (FUM) to indicate the exact reason for the error.

Freeing mismatched memory (FMM) is reported when a memory location is de-allocated by using a function from a different family than the one used for allocation. For example, you use new operator to allocate memory, but use method free to de-allocate it. Purify checks for the following families, or matching pairs:

malloc() / free()
calloc() / free()
realloc() / free()
operator new / operator delete
operator new[] / operator delete[]

Purify reports any incompatible use of memory allocation and de-allocation routine as an FMM error. In the example in Listing 11, the memory was allocated using the malloc method but freed using the delete operator, which is not the correct counterpart, thus incompatible. Another common example of an FMM error is C++ programs that allocate an array using the new[] operator, but free the memory using a scalar delete operator instead of array delete[] operator. These errors are hard to detect through code inspection, because the memory allocation and de-allocation locations may not be located close to each other, and because there is no difference in syntax between an integer pointer and a pointer to an integer array.

Listing 11. An example of a freeing mismatched memory error

void genFMM() {
    int *pi = (int*) malloc(4 * sizeof(int));
    delete pi; /* Expect FMM/FIM: should have used free(pi); */
    pi = new int[5];
    delete pi; /* Expect FMM/FIM: should have used delete[] pi; */
}

Freeing non-heap memory (FNH) error is reported when you call free with a non-heap address (a stack address, for instance). Freeing unallocated memory (FUM) is reported when you try to free unallocated memory, such as memory that you have already freed, or the pointer you are trying to free points to the middle of a memory block. Listing 12 shows examples of these errors.

Listing 12. Examples of freeing non-heap memory and freeing unallocated memory errors

void genFNH() {
    int fnh = 0;
    free(&fnh); /* Expect FNH: freeing stack memory */
}

void genFUM() {
    int *fum = (int *) malloc(4 * sizeof(int));
    free(fum+1); /* Expect FUM: fum+1 points to middle of a block */
    free(fum);
    free(fum); /* Expect FUM: freeing already freed memory */
}

Purify - 고급 사용법

2012-01-08T00:32:00.001+09:00

출처 : http://www.ibm.com/developerworks/rational/library/08/0226_gupta-gaurav/index.html

본 자료는 Purify 옵션과 지시문에 대한 개요를 먼저 소개하고 다음 항목에 대한 설명을 하고자 합니다:

캐시 관리: 삽입한 바이너리 파일의 관리 및 공유하는 방법
부분 Purify: 프로그램의 일부부만을 삽입하여 실행 시간 오버헤드와 탐지 영역을 줄이는 방법
힙 메모리 관리: 프로그램 실행시 메모리 오버헤드를 제한하고 힙 사용 보고서를 맞춤 설정하는 방법

Purify 옵션

Purify에서는 아래의 두가지 옵션을 통해 세밀한 제어를 제공합니다.

빌드타임 옵션
런타임 옵션

빌드타임 옵션은 삽입시에 사용됩니다. 예를 들어, 정적 데이터에 대한 버퍼 오버런을 체크하지 않을 경우, 삽입시에 -static-checking 옵션을 사용합니다:
$ purify -static-checking=no cc your_prog.c

런타임 옵션은 삽입된 프로그램의 런타임 행위에 영향을 줍니다. 예를 들어 보고된 에러에 대한 콜 스택 체인을 더 길게 보여주고자 할 때 아래와 같은 옵션을 사용합니다:
$ purify -chain-length=10 cc your_prog.c

옵션은 링크 라인 뿐아니라 환경변수 PUREOPTIONS 와 PURIFYOPTIONS 를 통해 표현할 수 있습니다.

환경변수 PUREOPTIONS는 Purify, Quantify 및 PureCoverage에도 적용됩니다.
환경변수 PURIFYOPTIONS는 Purify에만 적용됩니다.

sh, ksh, 및 bash 쉘을 사용하는 경우:
$ export PURIFYOPTIONS="-static-checking=no -chain-length=10"

csh 또는 tcsh 쉘을 사용하는 경우:
% setenv PURIFYOPTIONS "-static-checking=no -chain-length=10"

링크 라인에 명시된 빌드타임 옵션은 환경변수에 나타난 같은 옵션을 덮어씁니다.

Purify는 삽입시점의 런타임 옵션을 삽입된 프로그램에 저장합니다. 실행시, (-ignore-runtime-environment 빌드타임 옵션을 사용하지 않는 경우) 환경변수는 삽입된 프로그램에 저장된 런타임 옵션을 덮어씁니다.

Purify GUI를 통해 명시한 런타임 옵션은 환경변수 및 링크라인에 명시된 옵션을 덮어씁니다.

Purify는 도움말 및 버전 문자열을 제공하기 위해 여러 빌드타임 옵션을 제공합니다:
$ purify -version
$ purify -usage
$ purify -help
$ purify -onlinehelp

-print-home-dir 빌드타임 옵션은 Purify가 설치된 디렉토리를 출력합니다. 이를 이용하여, 아래처럼 purify_what_options 스크립트를 실행하여 삽입시 사용된 옵션을 알아볼 수 있습니다:
$ `purify -print-home-dir`/purify_what_options <your_prog.pure>

Purify API를 사용하기 위해 purify.h를 프로그램에 포함시키는 경우, 컴파일러의 헤더파일 탐색경로를 아래처럼 표기할 수 있습니다:
$ cc -c -I`purify -print-home-dir` your_prog.c

Purify 지시문

커맨드 라인 옵션외에 추가로 다양한 지시문을 명시함으로써 삽입 및 에러 보고에 대한 상세 제어를 할 수 있습니다.

예를 들어 써드파티 라이브러리(libfoo)에 있는 함수(foo)에 메모리에러(uninitialized memory read, UMR)가 있다고 가정해 봅니다. 라이브러리 제공 벤더에 에러를 보고했고, 이에 대한 픽스를 기다리는 동안에, Purify 분석 결과에서 해당 에러를 보이지 않게 하고 싶다면, suppress 지시문을 아래와 같이 사용합니다:
suppress umr foo

만약 suppress 지시문을 통해 보이지않는 에러를 보고싶다면 Purify GUI의 View 메뉴에서 Suppressed를 클릭합니다.

Purify는 아래 예처럼 구체적으로 또는 일반적으로 기술할 수 있도록 합니다:

특정 콜 체인 상의 UMR를 숨기고자 할때는 전체 콜 체인을 제시합니다:
suppress umr printf; foo; bar; main
일부 콜 체인과 매칭되는 UMR를 숨기고자 할때는 생략(...) 기호를 통해 제시합니다:
suppress umr ...; foo; ...; main
특정 라이브러리의 모든 UMR를 숨기고자 할때는 해당 라이브러리를 제시합니다:
suppress umr "libfoo*"
모든 UMR를 숨기고자 할때는 다음과 같습니다 (물론 위험천만한(?) 생각입니다):
suppress umr *

Purify는 지시문이 저장된 세곳의 .purify 파일을 다음 순서로 검색합니다:

<purify-installation-home>/.purify
<users-home-dir>/.purify
<current-working-directory>/.purify

모든 Purify 사용자, 프로젝트 사용자, 자기 자신 등 맞춤 설정 영역에 맞게 해당 파일을 수정하여 지시문을 제공합니다.

또 다른 방법으로 Purify GUI에서 에러를 선택하고 팝업메뉴에서 Suppress를 선택할 수 있습니다. 그리고 그림 1에서 처럼, 에러타입, 콜체인타입 등을 명시할 수 있습니다. .purify 파일 위치를 지정한 후 Make permanent를 클릭하여 저장할 수도 있습니다.

그림 1. Purify Suppression 대화상자

또다른 지시문 kill은 suppress와 거의 유사하지만, GUI에서 View > Suppressed Messages 메뉴를 사용해도 볼 수 없습니다. 어떤 에러가 아주 많이 발생하는 경우에 suppress 대신 kill을 사용하면 프로그램 실행이 더 빨라집니다.

캐시 관리

프로그램에 대한 삽입시에, Purify는 프로그램에서 직접 또는 간접적으로(예 libc) 사용하는 모든 라이브러리들 또한 삽입을 하고 삽입된 라이브러리를 원 라이브러리 대신 프로그램과 바인딩을 합니다. 만약 라이브러리가 있는 디렉토리에 쓰기권한이 있다면 해당 라이브러리 디렉토리에 삽입된 라이브러리를 생성합니다.

만약 쓰기 권한이 없다면, Purify 설치 영역내 디폴트 캐시 디렉토리에 삽입된 라이브러리를 생성합니다.
이러한 캐시관련된 여러 빌드타임 옵션이 있습니다. 삽입된 라이브러리를 여러 디렉토리에 산재하지 않고 캐시 디렉토리에 저장하기를 원한다면 -always-use-cache-dir 옵션을 사용합니다. 디폴트 캐시 디렉토리 대신 별도 캐시 디렉토리를 지정하길 원한다면 -cache-dir=<dir-name> 옵션을 사용합니다. 이러한 옵션들을 통해서, 손쉽게 캐시 디렉토리를 삭제함으로써 모든 삽입된 라이브러리를 제거할 수 있습니다.

프로그램에 대한 삽입시에, Purify는 마지막 삽입이후 변경이 있거나 삽입된 라이브러리를 찾을 수 없는 경우에만 라이브러리를 삽입합니다. 이는 삽입 시간을 절약하는 데 도움이 됩니다. 만약 이전에 삽입된 라이브러리를 무시하고 모든 필요한 라이브러리를 삽입하고자 할때는 -force-rebuild 옵션을 사용합니다. 이는 고급 옵션 (예 -static-checking-guardzone)를 사용하여 재 삽입을 강제할 경우 유용합니다.

일반적으론, 하나의 머신에서 삽입한 프로그램은 다른 머신에서 실행할 수 없습니다. 일반적으로 프로그램은 시스템 라이브러리들(예 libc)에 의존하는 데, 시스템 라이브러리들은 OS 패키지들의 다양한 패치 수준에 따라서 머신마다 달라질 수 있습니다.

프로그램이 같은 시스템의 원래 라이브러리에 상응하는 삽입된 라이브러리를 사용하도록 보장하기 위해서, Purify는 삽입된 라이브러리를 호스트 이름 별로 캐시하는 메커니즘을 제공합니다.

한편, 프로그램은 모든 머신에서 똑같거나 같은 네트워크 위치로 접근할 수 있는 라이브러리나 써드파티 라이브러리를 사용할 수도 있습니다. 이런 경우, 각각의 호스트별로 삽입된 해당 라이브러리를 가지고 싶어하지 않을 겁니다. 사본이 똑같기에 저장공간을 낭비하기 때문입니다. 이를 위해 Purify는 IBM® AIX®, Linux® 및 Solaris® UNIX® 플랫폼에서 repure 메커니즘을 제공합니다. 다만 삽입시에 다음과 같은 점을 주의해야 합니다:

먼저, 모든 머신상에 존재하는 로컬 경로를 선정합니다.예를 들어 /tmp 디렉토리는 모든 머신에 있지만 로컬 경로이고, 머신 간에 공유되고 있지 않습니다. 팁: 홈 디렉토리나 NFS 상의 디렉토리를 사용하지 마십시요.
-local-cache-dir 옵션을 사용하여, 시스템에 특화된 라이브러리의 삽입 결과를 저장할 경로를 지정합니다. 예:
$ purify -always-use-cache-dir -local-cache-dir=/tmp -cache-dir=./cache \
cc -g test.c -o test.pure
같은 머신에서 삽입된 프로그램을 실행할 수 있습니다:
$ ./test.pure
다른 머신에서 삽입된 프로그램을 실행하길 원한다면, 다른 머신에서 repure를 실행합니다:
$ repure ./test.pure
repure 실행 후 다른 머신에서 프로그램을 실행할 수 있습니다:
$ ./test.pure

오래된 삽입된 파일들을 삭제하고 싶다면, Purify 설치 영역의 pure_remove_old_files 스크립트를 실행합니다:
`purify -print-home-dir`/pure_remove_old_files <path> <days>

이 스크립트는 _pure_를 포함한 파일이나 .so 나 .sl 확장자를 갖는 공유 라이브러리 파일등 삽입된 라이브러리들만을 제거합니다. 예를 들어 파일시스템 상의 14일 이상된 모든 삽입된 파일을 삭제할 경우, 아래와 같이 실행합니다:
$ pure_remove_old_files / 14

부분 Purify

Purify는 부당한 메모리 엑세스를 체크하기 위해 관심있는 곳에 삽입을 합니다. 체크를 하고, 체크에 필요한 데이터를 관리하는 것은 성능 상의 오버헤드를 초래합니다. 때때로 프로그램의 특정 콤포넌트들에 있는 메모리 에러에만 관심이 가능 경우도 있습니다. 이러한 경우 부분적으로 프로그램에 삽입을 하고 관심없는 공유 라이브러리를 배제할 수 있는 메커니즘을 통해 삽입된 프로그램 실행시 실행시 오버헤드를 많이 줄일 수 있습니다.

주의:
부분 삽입은 HP-UX와 AIX 플랫폼에서만 동작합니다. Solaris SPARC 플랫폼은 제한적으로 지원하고, Solaris x86 및 Linux 플랫폼은 지원하지 않습니다.
공유 라이브러리를 배제하더라도, Purify는 배제된 공유라이브러리에서 할당받은 메모리 누스 등 힙 관리 에러를 탐지합니다.
부분 삽입을 통해 아래처럼 라이브러리를 배제할 수 있습니다:
$ purify -selective -exclude-libs=libfoo1.so:libfoo2.so cc -g app.c \
-o a.out.pure -lfoo1 -lfoo2 -lbar

-exclude-libs 옵션에 콜론으로 나열한 라이브러리 목록을 제공하거나 .purify 지시문 파일에 exclude 지시문을 사용할 수도 있습니다:
exclude libfoo*

-selective 옵션을 사용하면 Purify가 라이브러리 배제로 인해 발행할 수 있는 에러를 탐지해서 배제할 수 있도록 지시합니다:

예를 들어 main()이 foo()를 호출하고, foo()는 bar()를 호출하는 경우에 foo()를 삽입에서 배제한다고 가정합니다. 추가로 main()에서 메모리를 할당받고, foo()에서 메모리를 초기화 하고, bar()에서 메모리를 사용한다고 가정합니다. foo()를 삽입처리하지 않은 경우, Purify는 foo()에서 메모리가 초기화되었다는 것을 알지 못하므로, bar()에서 메모리를 사용할 때, uninitialized memory read (UMR) 에러를 보고할 수 있습니다. -selective 옵션은 이런 경우 Purify가 이런 류의 에러를 제거하도록 지시합니다.

라이브러리를 배제한 경우 Purify가 몇몇 에러를 찾지 못할 수 있습니다. 예를 들어 main()이 foo()를 호출하고 초기화되지 않은 버퍼를 전달한다고 가정합니다. Purify는 foo()에서 버퍼를 사용할 때마다 UMR를 보고합니다. 만약 foo()가 libfoo.so 공유라이브러리에 있고, 이를 배제했다고 한다면, Purify는 관련 메모리 체킹 코드를 삽입하지 못했기 때문에, 삽입된 코드에서 실행이 된다고 하더라도 foo()에서 초기화하지 않은 버퍼를 사용하더라도 탐지를 할 수 없습니다.

위의 두개의 예는 포괄적인 에러탐지와 실행시의 오버헤드에는 상당한 상충이 있다는 것을 보여줍니다. 그러므로, 신중히 라이브러리의 역할을 파악해서 배제할 공유 라이브러리를 선택해야 합니다.

Purify는 삽입처리되지 않는 코드에서 발생한 버퍼 오버런 에러를 탐지할 수 있습니다만 에러가 발생한 시점이 아닌 버퍼가 해제되는 시점에 탐지합니다. Purify는 에러가 발생할 때 보고를 하지만 삽입되지 않는 코드에 대한 에러는 제때 보고할 수 없습니다. -late-detect-logic 옵션은 힙 메모리 블럭이 해제될 때 추가적인 체크를 하도록 합니다. 버퍼 오버런을 탐지한 경우, Array Bound Write Late (ABWL) 에러를 보고합니다.

힙 메모리 관리 에러

Purify 는 삽입된 프로그램 실행시 메모리 및 실행 시간 오버헤드를 제어할 수 있는 몇가지 옵션을 제공합니다. 프로그램이 메모리블럭을 해제할 때, Purify는 곧바로 해당 메모리를 해제하지 않습니다. 대신에, 해제된 메모리를 FIFO 큐에 넣습니다. 이를 통해 Purify는 해제된 메모리를 가리키는 포인터에 대한 에러(Free Memory Read/Write, FMR/FMW)를 탐지하고 보고할 수 있습니다. 만약 해제된 메모리가 바로 힙으로 반환됐다면 곧바로 재사용될 수 있었지만 Purify는 해제된 블럭에 대한 부당한 엑세스인지 할당된 블럭에 대한 합당한 엑세스인지 알수 없을 겁니다.

큐의 디폴트 크기는 100입니다. 큐가 꽉 차면, Purify는 큐의 첫번째 메모리 블럭을 해제한 뒤 새로 할당받은 블럭을 추가합니다. 큐의 크기는 -free-queue-length=<value> 옵션으로 변경할 수 있습니다. 큐 크기가 커지면 부당한 포인터를 탐지할 가능성을 높이지만, 메모리 오버헤드 비용은 커지게 됩니다..

프리 큐는 작은 블럭에만 사용되며 임계치 이하의 블럭을 관리합니다. 큰 블럭은 바로 해제하여 힙으로 넘겨서 많은 메모리 사용의 위험성을 회피합니다. -free-queue-threshold=<value> 옵션으로 해당 임계치를 명시할 수 있습니다. 디폴트는 10000 바이트입니다. 즉 10000 바이트 이상의 블럭은 곧바로 해제됩니다.

Purify는 프로그램 종료시점에 모든 메모리 누수를 보고합니다. 사용중인 메모리 블럭에 대한 정보가 필요하다면, -inuse-at-exit=yes 옵션을 사용합니다. 마찬가지로 프로그램 종료시에 사용중인 파일 디스크립터에 대한 정보가 필요하면, -fds-inuse-at-exit=yes 옵션을 사용합니다.

AIX 시스템에서는, 메모리 누수에만 관심이 있는 경우, -memory-leaks-only 옵션을 사용할 수 있으며, 이 경우 Purify는 메모리 누수 및 Freeing Memory Mismatch (FMM) 에러 같은 몇몇 힙 관리 에러 탐지를 위한 매우 가벼운 삽입처리를 합니다. 이로 인해 실행시 일상적인 메모리 엑세스 검증을 하지 않아서 실행이 훨씬 빨리집니다.

Purify Linux - 사용법 개요

2012-01-07T23:54:00.000+09:00

출처 : http://www.ibm.com/developerworks/rational/library/05/r-3120/index.html

간단한 프로그램 분석을 통해 다음 두가지를 보여주고자 합니다.
(1) 리눅스에 Purify가 제대로 설치되어 있는 지 확인합니다.
(2) 작고 간단한 프로그램이지만 에러가 발생하기가 쉬우며 어떤 수정이 필요한지 보여줍니다.

아래 conv.c는 화씨를 섭씨로 변경하는 C 프로그램으로 Kernighan 및 Ritchie의 The C Programming Language에 예시된 프로그램을 조금 변경한 것입니다.

#include <stdio.h>
#include <stdlib.h>
#include <malloc.h>
main()
{
int *fahr;
fahr = (int *)malloc(sizeof(int));

int celsius;
int lower, upper, step;
celsius = lower + 10;
lower = 0; /* lower limit of temperature table */
upper = 300; /* upper limit */
step = 20; /* step size */

*fahr = lower;
while(*fahr <= upper){
celsius = 5 * (*fahr - 32) / 9;
printf("%d\t%d\n", *fahr, celsius);
*fahr = *fahr + step;
}
}

Purify를 이용해 이 프로그램을 분석하기 위해, 링크 커맨드 앞에 purify를 추가함으로써 프로그램에 삽입을 합니다. Purify 분석 메세지를 상세화하기 위해서 -g 옵션을 추가할 수 있습니다:
purify gcc [-g] conv.c

그림 1: gcc 컴파일러와 Purify를 이용한 conv.c 프로그램 빌드 및 삽입

만약 프로그램 컴파일 및 링크를 단계별로 수행할 경우에는 링크 라인에만 purify를 명시합니다:
컴파일 라인: gcc -c [-g] conv.c
링크 라인: purify gcc [-g] conv.o

Rational PurifyPlus for Linux and UNIX에서 지원하는 컴파일러 목록은 아래와 같습니다.
출처: http://www-01.ibm.com/software/awdtools/purifyplus/unix/sysreq/

Operating System	Software	Hardware
Solaris® 10 base through 5/09 Solaris 9 base through 9/05 Solaris 8 base through 2/04	Sun C/C++ 5.3 through 5.10 GNU gcc/g++ 4.0 through 4.4 GNU gcc/g++ 3.0 through 3.4	Sun UltraSPARC®
Solaris 10 6/06 through 5/09	Sun C/C++ 5.8 through 5.10 GNU gcc/g++ 4.0 through 4.4 GNU gcc/g++ 3.4	AMD64™ Intel® 64
RHEL 5 (Server/Desktop) base through 5.4 RHEL 4 (AS/ES/WS) base through 4.8 RHEL 3 (AS/ES/WS) base through U9 SLES 11 base SLES 10 base through SP2 SLES 9 base through SP4	GNU gcc/g++ 4.0 through 4.4 GNU gcc/g++ 3.2 through 3.4 Intel icc 11.0 Intel icc 10.1	Intel IA-32
RHEL 5 (Server/Desktop) base through 5.4 RHEL 4 (AS/ES/WS) base through 4.8 SLES 11 base SLES 10 base through SP2 SLES 9 base through SP4	GNU gcc/g++ 4.0 through 4.4 GNU gcc/g++ 3.2 through 3.4 Intel icc 11.0 Intel icc 10.1	AMD64 Intel 64
AIX® 6.1 base through TL3 AIX 5L v5.3 TL5 through TL9	IBM® XL C/C++ 10.1 IBM XL C/C++ 9.0 IBM XL C/C++ 8.0 IBM XL C/C++ 7.0 GNU gcc/g++ 3.4	IBM POWER4 IBM POWER5 IBM POWER6

7.0.1.0-002

Solaris

Solaris 10 update 8
Solaris Studio 12.1
gcc 4.5
gdb 6.8, 6.9, 7.0, 7.1

Linux

Red Hat Enterprise Linux 5.5 (Server/Desktop)

SUSE Linux Enterprise Server 10 SP3

gcc 4.5

gdb 6.8, 6.9, 7.0, 7.1

icc 11.1

AIX

AIX 6.1 TL4

AIX 5.3 TL10, TL11

이제 삽입된 프로그램을 실행하여 결과를 보도록 하겠습니다. 실행 결과가 그림 2처럼 커맨드 라인에 표시되는 동안, Purify는 분석 결과를 그림 3처럼 윈도우에 표시를 합니다.

그림 2: 프로그램 실행 출력 화면

그림 3: 프로그램 실행 분석 화면

탐지된 에러와 누수 정보를 보다 자세히 보려면 그림 4처럼 해당 메뉴항목을 확장합니다. Purify는 문제가 발생한 지점을 자세히 보여줍니다.

그림 4: 문제에 대한 상세 보기 (-g 옵션을 사용하지 않은 경우)

그림 4-1: 문제에 대한 상세 보기 (-g 옵션을 사용한 경우)

문제 해결에 필요한 도움말이 필요할 경우에는 에러(예 그림 4, "UMR: Uninitialized memory read")를 선택한 후 물음표를 클릭합니다.혹은 Actions 메뉴에서 그림 5처럼 Explain message를 선택합니다.

그림 5: Actions 메뉴의 메뉴 항목

그림 6처럼 UMR 에러 메시지 관련 정보가 나타납니다.

그림 6: UMR 에러 메세지에 대한 설명

도움말을 통해서, Purify가 탐지한 문제에 대한 해결책을 아래 처럼 결정할 수 있습니다:

정의되지 않은 lower 변수 값을 사용하는 celsius 변수에 대한 assignment 라인을 삭제합니다. (celsius assignment 라인을 lower 변수 정의 이후로 옮길 수도 있지만 여기선 그럴 필요가 없습니다) 이는 Purify가 분석한 UMR 문제를 해결합니다.
celsius = lower + 10;
fahr 변수에 대한 free 함수를 호출하여 fahr 변수에 할당된 메모리를 해제합니다. 이는 Purify가 분석한 메모리 누수 MLK를 해결합니다.

문제를 해결한 뒤, Purify를 다시 적용하여 문제가 처리되었는 지 확인하십시요. 그림 7처럼 문제 해결을 확인할 수 있습니다.

그림 7: 문제 해결 후의 Purify 분석 결과 화면

에러가 해결되었고 메모리 누수를 잡았습니다. 프로그램은 이제 좋은 상태입니다.

Linked Data

2012-01-07T19:57:00.000+09:00

출처 : http://www.ibm.com/developerworks/rational/library/basic-profile-linked-data/index.html

There is interest in using Linked Data technologies for more than one purpose. We have seen interest in it to expose information -- public records, for example -- on the Internet in a machine-readable format. The IBM® Rational® team has been using Linked Data as an architectural model and implementation technology for application integration.

We would like to share information about how we are using these technologies, the best practices and anti-patterns that we have identified, and the specification gaps that we have had to fill. These best practices and anti-patterns can be classified according to (but are not limited to) the following categories:

Resources

A summary of the HTTP and RDF standard techniques and best practices that you should use, and anti-patterns you should avoid, when constructing clients and servers that read and write Linked Data

Containers

Defines resources that allow new resources to be created using HTTP POST and existing resources to be found using HTTP GET

Paging

Defines a mechanism for splitting the information in large resources into pages that can be fetched incrementally

Validation

Defines a simple mechanism for describing the properties that a particular type of resource must or may have

The following sections provide details regarding this proposal for a Basic Profile for Linked Data.

Basic Profile Resources

Basic Profile Resources are HTTP Linked Data resources that conform to simple patterns and conventions. Most Basic Profile Resources are domain-specific resources that contain data for an entity in a domain. All Basic Profile Resources follow the rules of Linked Data:

Use URIs as names for things.
Use HTTP URIs so that people can look up those names.
When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL).
Include links to other URIs so that people can discover more things.

Basic Profile adds a few rules. Some of these rules could be thought of as clarification of the basic Linked Data rules.

Basic Profile Resources are HTTP resources that can be created, modified, deleted and read using standard HTTP methods.
Basic Profile Resources are created by HTTP POST (or PUT) to an existing resource, deleted by HTTP DELETE, updated by HTTP PUT or PATCH, and "fetched" using HTTP GET. Additionally, Basic Profile Resources can be created, updated, and deleted by using SPARQL Update.
Basic Profile Resources use RDF to define their states.
The state of a Basic Profile Resource (in the sense of state used in the REST architecture) is defined by a set of RDF triples. Binary resources and text resources are not Basic Profile Resources since their states cannot be easily or fully represented in RDF. XML resources might or might not be suitable as Basic Profile Resources. Some XML resources are really data-oriented resources encoded in XML that can be easily represented in RDF. Other XML documents are essentially marked up text documents that are not easily represented in RDF. Basic Profile Resources can be mixed with other resources in the same application.
You can request an RDF/XML representation of any Basic Profile Resource.The resource might have other representations, as well. These could be other RDF formats, such as Turtle, N3, or NTriples, but non-RDF formats such as HTML and JSON would also be popular additions, and Basic Profile sets no limits.
Basic Profile clients use Optimistic Collision Detection during update.
Because the update process involves getting a resource first, and then modifying it and later putting it back on the server, there is the possibility of a conflict (for example, another client might have updated the resource since the GET action). To mitigate this problem, Basic Profile implementations should use the HTTP If-Match header and HTTP ETags to detect collisions.
Basic Profile Resources use standard media types.
Basic Profile does not require and does not encourage the definition of any new media types. A Basic Profile goal is that any standards-based RDF or Linked Data client be able to read and write Basic Profile data, and defining new media types would prevent that in most cases.
Basic Profile Resources use standard vocabularies.
Basic Profile Resources use common vocabularies (classes, properties, and so forth) for common concepts. Many websites define their own vocabularies for common concepts such as resource type, label, description, creator, last modification time, priority, enumeration of priority values, and so on. This is usually viewed as a good feature by users who want their data to match their local terminology and processes, but it makes it much harder for organizations to subsequently integrate information in a larger view. Basic Profile requires all resources to expose common concepts using a common vocabulary for properties. Sites can choose to additionally expose the same values under their own private property names in the same resources. In general, Basic Profile avoids inventing property names where possible. Instead, it uses ones from popular RDF-based standards, such as the RDF standards themselves, Dublin Core, and so on. Basic Profile invents property URLs where no match is found in popular standard vocabularies.
Basic Profile Resources set rdf:type explicitly.
A resource's membership in a class extent can be derived implicitly or indicated explicitly by a triple in the resource representation that uses the rdf:type predicate and the URL of the class or derived implicitly. In RDF, there is no requirement to place an rdf:type triple in each resource, but this is a good practice, because it makes a query more useful in cases where inferencing is not supported. Remember also that a single resource can have multiple values for rdf:type. Basic Profile sets no limits to the number of types a resource can have.
Basic Profile Resources use a restricted number of standard data types.
RDF does not define data types to be used for property values, so Basic Profile lists a set of standard datatypes to be used in Basic Profile.
Basic Profile clients expect to encounter unknown properties and content.
Basic Profile provides mechanisms for clients to discover lists of expected properties for resources for particular purposes, but it also assumes that any given resource might have many more properties than those listed. Some servers will support only a fixed set of properties for a particular type of resource. Clients should always assume that the set of properties for a resource of a particular type at an arbitrary server might be open, in the sense that different resources of the same type might not all have the same properties, and the set of properties that are used in the state of a resource is not limited to any predefined set. However, when dealing with Basic Profile Resources, clients should assume that a Basic Profile server might discard triples for properties when it has prior knowledge. In other words, servers can restrict themselves to a known set of properties, but clients cannot. When doing an update using HTTP PUT, a Basic Profile client must preserve all property values retrieved by using HTTP GET. This includes all property values that it doesn't change or understand. (Use of HTTP PATCH or SPARQL Update rather than HTTP PUT for updates avoids this burden for clients.)
Basic Profile clients do not assume the type of a resource at the end of a link.
Many specifications and most traditional applications have a "closed model," by which we mean that any reference from a resource in the specification or application necessarily identifies a resource in the same specification (or a referenced specification) or application. In contrast, the HTML anchor tag can point to any resource addressable by an HTTP URI, not just other HTML resources. Basic Profile works like HTML in this sense. An HTTP URI reference in one Basic Profile Resource can, in general, point to any resource, not just a Basic Profile Resource. There are numerous reasons to maintain an open model like HTML's. One is that it allows data that has not yet been defined to be incorporated in the web in the future. Another reason is that it allows individual applications and sites to evolve over time. If clients assume that they know what will be at the other end of a link, then the data formats of all resources across the transitive closure of all links must be kept stable for version upgrade. A consequence of this independence is that client implementations that traverse HTTP URI links from one resource to another should always code defensively and be prepared for any resource at the end of the link. Defensive coding by client implementers is necessary to allow sets of applications that communicate through Basic Profile to be independently upgraded and flexibly extended.
Basic Profile servers implement simple validations for Create and Update.
Basic Profile servers should try to make it easy for programmatic clients to create and update resources. If Basic Profile implementations associate a lot of very complex validation rules that need to be satisfied for an update or creation to be accepted, it becomes difficult or impossible for a client to use the protocol without extensive additional information specific to the server that needs to be communicated outside of the Basic Profile specifications. The recommended approach is for servers to allow creation and updates based on the sort of simple validations that can be communicated programmatically through a Shape (see the Constraints section). Additional checks that are required to implement more complex policies and constraints should result in the resource being flagged as requiring more attention, but should not cause the basic Create or Update action to fail.
Basic Profile Resources always use simple RDF predicates to represent links.
By always representing links as simple predicate values, Basic Profile makes it very simple to know how links will appear in representations and also makes it very simple to query them. When there is a need to express properties on a link, Basic Profile adds an RDF statement with the same subject, object, and predicate as the original link, which is retained, plus any additional "link properties." Basic Profile Resources do not use "inverse links" to support navigation of a relationship in the opposite direction, because this creates a data synchronization problem and complicates a query. Instead, Basic Profile assumes that clients can use queries to navigate relationships in the opposite direction from the direction supported by the
underlying link.

Common properties

The tables that follow list properties from well-known RDF vocabularies that are recommended for use in Basic Profile Resources. Basic Profile requires none of them, but a specification based on Basic Profile might require one or more of these properties for a particular type of resource.

Commonly used namespace prefixes

Prefix	Namespace URI
`dcterms`	http://purl.org/dc/terms/
`rdf`	http://www.w3.org/1999/02/22-rdf-syntax-ns#
`rdfs`	http://www.w3.org/2000/01/rdf-schema#
`bp`	http://open-services.net/ns/basicProfile#
`xsd`	http://www.w3.org/2001/XMLSchema#

From Dublin Core
URI: http://purl.org/dc/terms/

Property	Range	Comment
dcterms:contributor	dcterms:Agent	The identifier of a resource (or blank node) that is a contributor of information. This resource can be a person or group of people or, possibly, an automated system.
dcterms:creator	dcterms:Agent	The identifier of a resource (or blank node) that is the original creator of the resource. This resource can be a person or group of people or, possibly, an automated system.
dcterms:created	xsd:dateTime	The creation timestamp.
dcterms:description	rdf:XMLLiteral	Descriptive text about the resource represented as rich text in XHTML format. Should include only content that is valid and suitable inside an XHTML element.
dcterms:identifier	rdfs:Literal	A unique identifier for the resource. Typically read-only and assigned by the service provider when a resource is created. Not typically intended for end-user display.
dcterms:modified	xsd:dateTime	Date on which the resource was changed.
dcterms:relation	rdfs:Resource	The URI of a related resource. This is the predicate to use when you do not know what else to use. If you know what kind of relationship it is, use a more specific predicate.
dcterms:subject	rdfs:Resource	Should be a URI (see dbpedia.org). From Dublin Core: "Typically, the subject will be represented using keywords, key phrases, or classification codes. Recommended best practice is to use a controlled vocabulary. To describe the spatial or temporal topic of the resource, use the Coverage element."
dcterms:title	rdf:XMLLiteral	A name given to the resource. Represented as rich text in XHTML format. Should include only content that is valid inside an XHTML element.

From RDF
URI: http://www.w3.org/1999/02/22-rdf-syntax-ns#

Property	Range	Comment
rdf:type	rdfs:Class	The type or types of the resource. Basic Profile recommends that the rdf:type(s) of a resource be set explicitly in resource representations to facilitate query with non-inferencing query engines.

From RDF Schema
URI: http://www.w3.org/2000/01/rdf-schema#

Property	Range	Comment
rdfs:member	rdf:Resource	The URI (or blank node identifier) of a member of a Container.
rdfs:label	rdf:Resource	"Provides a human-readable version of a resource name." (From RDFS)

Basic Profile Container
Many HTTP applications and sites have organizing concepts that partition the overall space of resources into smaller Containers. Blog posts are grouped into blogs, wiki pages are grouped into wikis, and products are grouped into catalogs. Each resource created in the application or site is created within an instance of one of these Container-like entities, and users can list the existing artifacts within one. There is no agreement across applications or sites, even within a particular domain, on what these grouping concepts should be called, but they commonly exist and are important. Containers answer two basic questions:

To which URLs can I POST to create new resources?
Where can I GET a list of existing resources?

We call these RDF Containers that you can POST to Basic Profile Containers. Here are some of their characteristics:

Clients can retrieve the list of existing resources in a Basic Profile Container.
New resources are created in Basic Profile Containers by POSTing to them.
Any resource can be POSTed to a Basic Profile Container. A resource does not have to be a Basic Profile Resource with an RDF representation to be POSTed to a Basic Profile Container.
After POSTing a new resource to a Container, the new resource will appear as a member of the Container until it is deleted. A Container can also contain resources that were added through other means, for example through the user interface of the site that implements the Container.
The same resource can appear in multiple Containers. This happens commonly if one Container is a "view" onto a larger Container.
Clients can get partial information about a Basic Profile Container without retrieving a full representation of all of its contents.

The representation of a Basic Profile Container is a standard RDF Container representation that uses the rdfs:member predicate.

Representation of a Basic Profile Container

@prefix rdfs: .

        a rdfs:Container;
        rdfs:member ;
        # … 999999998 more triples here …
        rdfs:member .

The Basic Profile does not recognize or recommend the use of other forms of an RDF Container, such as Bag and Seq, because they are not friendly to query. This follows standard Linked Data guidance for RDF use.

The Basic Profile recommends the use of a set of standard Dublin Core properties with Containers. The subject of triples using these properties is the Container itself.

rdfs:Container domain properties

Property	Occurs	Range	Comment
dcterms:title	zero or one	rdf:XMLLiteral	A name given to the resource. Represented as rich text in XHTML format. Should include only content that is valid inside an XHTML element.
dcterms:description	zero or one	rdf:XMLLiteral	Descriptive text about resource represented as rich text in XHTML format. Should include only content that is valid and suitable inside an XHTML element.
dcterms:publisher	zero or one	dcterms:Agent	An entity responsible for making the Basic Profile Container and its members available.
bp:containerPredicate	exactly one	rdfs:Property	The predicate of the triples whose objects define the contents of the Container.

Retrieving non-member properties

The representation of a Container that has many members will be large. When we looked at our use cases, we saw that there were several important cases where clients needed to access only the non-member properties of the Container. Because retrieving the whole Container representation to get these information is onerous, we were motivated to define a way to retrieve only the non-member property values. We do this by defining a corresponding resource for each Basic Profile Container, called the "non-member resource," which has a state that is a subset of the state of the Container. The non-member resource's HTTP URI can be derived in the following way:

If the HTTP URI of the Container is {url}, then the HTTP URI of the related non-member resource is {url}?non-member-properties. The representation of {url}?non-member-properties is identical to the representation of {url}, except that the membership triples are missing. The subjects of the triples will still be {url}, not {url}?non-member-properties. Any server that does not support non-member-resources should return an HTTP 404 File Not Found error when a non-member-resource is requested.

This approach is analogous to using HTTP HEAD rather that HTTP GET. The difference is that HTTP HEAD is used to fetch the response headers for a resource, as opposed to requesting the entire representation of a resource using HTTP GET.

HTTP GET example, request

GET /container1?non-member-properties HTTP/1.1
HOST: example.org 
Accept: text/turtle

HTTP GET example, response

@prefix rdfs: .
@prefix dcterms: . 
@prefix bp: .

        a rdfs:Container;
        dcterms:title "An Basic Profile Container of Acme Resources";
        bp:containerPredicate rdfs:member;
        dcterms:publisher .

Basic Profile validation and constraints

Basic Profile resources are RDF resources, and RDF has the happy characteristic that "it can say anything about anything." This means that, in principle, any resource can have any property and there is no requirement that any two resources have the same set of properties, even if they have the same type or types. In practice, though, the properties that are set on resources usually follow regular patterns that are dictated by the uses of those resources. Although a particular resource might have arbitrary properties, when viewed from the perspective of a particular application or use case, the set of properties and property values that are appropriate for that resource in that application will often be predictable and constrained. For example, if a server has resources that represent software products and bugs, for the purposes of displaying information in tabular formats, creating and updating resources, or other purposes, a client might want to know what properties software products and bugs have on that server. The Basic Profile Validation and Constraints specification aims to capture information about those properties and constraints.

The distinction between the resource and the use cases that it participates in is important to us. Traditional technologies such as relational databases constrain the total set of properties that an entity can have. In the Basic Profile, we aim only to define the properties that a resource can have when viewed through the lens of a particular application or use case, yet retaining the ability of the same resource to have an arbitrary set of properties to support other applications and use cases.

The set of properties that a resource can or will have is not necessarily linked to its type, but exploiting the pattern where resources of the same type have the same properties is a very traditional approach that supports the development of many useful applications. Sometimes, knowledge of types and properties for the application is hard-coded in software, but there are many cases where it is desirable to represent this knowledge in data. The Basic Profile provides resource types called Shape and PropertyConstraint to represent this data.

Note on the relationship of Shape to other standards:
Although we're all very familiar from relational databases and object-oriented programming with the model where the valid properties are constrained by the type, it is not the "natural" model of RDF, nor is it the model of the natural world. The familiar model says that if you are of type X, you will have these properties that will have values of certain types. RDF and, to a large degree, the natural world work the other way around; if you have these properties, you must be of type X. We are not aware of any OWL or RDFS construct that lets you say "from the perspective of application X, resources with an RDF type of Y will have the list of properties Z," nor of constraining the types of the values of these properties.

Class: PropertyConstraint
URI: http://open-services.net/ns/basicProfile#PropertyConstraint
bp:PropertyConstraint domain properties

Property	Occurs	Range	Comment
rdfs:label	zero or one	rdfs:Literal	A human-readable name for the subject. (from rdfs)
rdfs:comment	zero or one	rdfs:Literal	A description of the subject resource. (from rdfs)
bp:constrainedProperty	exactly one	rdfs:Property	The URI of the predicate being constrained.
bp:rangeShape	zero or one	bp:Shape	A bp:Shape that describes the rdfs:Class that is range of the property.
bp:allowedValue	zero or many	range of the subject	A value allowed for the property. If there are both `bp:allowedValue` elements and an`bp:AllowedValue` resource, then the full set of allowed values is the union of both.
bp:AllowedValues	zero or many	bp:AllowedValues	A resource with allowed values for the property being defined.
bp:defaultValue	zero or one	range of the object	A default value for the property
bp:occurs	exactly one	rdfs:Resource	Must be one of these three: `http://open-service.net/ns/basicProfile#Exactly-one` or`http://open-service.net/ns/ basicProfile#Zero-or-one`, `http://open-service.net/ns/basicProfile#Zero-or-many` or `http://open-service.net/ns/ basicProfile#One-or-many`
bp:readOnly	zero or one	Boolean	`true` if the property is read-only. If not set or set to `false`, then the property is writable. Providers should declare a property read-only when changes to the value of that property will not be accepted on PUT. Consumers should note that the converse does not apply: Providers may reject a change to the value of a writable property.
bp:maxSize	zero or one	Integer	For String properties only, specifies maximum characters allowed. If not set, then there is no maximum or maximum is specified elsewhere.
bp:valueType	zero or one	rdfs:Resource	For literals, see XSD Datatypes.

It is debatable whether we should have a separate bp:PropertyConstraint class with a property on it called bp:constrainedProperty, or whether it would be better to use rdfs:Property and simply define new predicates with rdfs:Property as the domain.

Important:
However, it is important not to use rdfs:range, because the semantics are different.

Class: AllowedValues
URI: http://open-services.net/ns/basicProfile#AllowedValues
bp:AllowedValues domain properties

Property	Occurs	Range	Comment
bp:allowedValue	zero or many	same as range of owning property	Allowed value

Class: Shape
URI: http://open-services.net/ns/basicProfile#Shape
bp:Shape domain properties

Property	Occurs	Range	Comment
dcterms:title	zero or one	rdfs:XMLLiteral	Title
bp:describedClass	exactly one	rdfs:Class	Class described
bp:propertyConstraints	zero or one	rdfs:List	The list of propertyConstraints for properties of this Shape. The domains of the PropertyConstraints must be compatible with the describedClass.

Validation semantics

Validation semantics are expressed by mapping the property and class definitions in terms of SPARQL ASK semantics. This enables a declarative way in RDF to define the constraints while using the existing SPARQL ASK specification.

Associating Shapes and Containers

It is useful to be able to specify for a Container what types of members it will return and accept, plus what properties it expects to be used with resources of those types. To enable this, the Basic Profile defines two new Container properties.
rdfs:Container domain properties

Property	Occurs	Range	Comment
bp:createShape	zero or many	bp:Shape	One or more Shapes that provide information on the expected data formats of resources that can be POSTed to the Container to create new members.
bp:readShape	zero or many	bp:Shape	One or more Shapes that provide information on the expected data formats of resources that can be found as members of the Container. Containers often add properties of their own to POSTed and PUT resources (creation date, modification date, creator), and it's useful for clients to know what these might be.

RQM - DOORS Integration Architecture

2012-01-06T17:37:00.002+09:00

as-is

to-be

-

Analytic Reporting & Live Reporting

2012-01-06T17:11:00.003+09:00

출처 : https://jazz.net/wiki/bin/view/Main/LinkedLifecycleData

Linked Data is a design for sharing decentralized, but interrelated, data on the Web.

At any given point in the development lifecycle it is of great interest to understand how requirements, source code, test cases, and defects are related. Typical questions are,

"Which requirements don't have any test cases?" and
"How many defects are unresolved for each requirement?"

Design 1.

One design for integrating this lifecycle data is to develop relational models for each type of development artifact and then store the corresponding relational representations of all the artifacts in a data warehouse where they can be queried, reported on, and analyzed using conventional business intelligence tools such as BIRT and Cognos.

Analytical Reporting

Design 2.

Linked Data offers an alternative way to solve the data integration problem. The key advance here is that Linked Data provides a uniform way to identify artifacts, namely HTTP Uniform Resource Identifiers (URI), and a common data model and representation format for them, Resource Description Framework (RDF). Data integration among mutliple sources of development artifacts is achieved by loading the RDF representations of all the development artifacts into a shared triple store, e.g. Jena, which can be queried using the powerful SPARQL query language.

The main tiers of this architecture are as follows:

Data Source Tier - CLM Development Tools that provide Linked Data
Reporting and Query Service Tier - Indexer, RDF Triple Store (Jena/TDB), SPARQL Endpoint
Presentation Tier - Business Intelligence reporting and analysis (Cognos, BIRT), Document generation (RPE), Faceted browsing

Live Reporting

Indexing & Query

2012-01-06T16:55:00.000+09:00

1. 다양한 형태의 resource는 storage에 저장됩니다.

2. property indexing은 저장된 resource로 부터 정보를 추출하여 공통 RDF 형태로 storage에 저장합니다.

3. query는 공통 RDF 형태에 대해 질의하여 결과를 리턴합니다.

예) 내가 작성(공통 property dc:creator에 기반)한 resource(요구사항/작업항목/테스트케이스/...)에 대한 query

예) change set에 link(다양한 storage에 저장된 resource간의 link에 기반)된 resource(작업항목/요구사항/테스트케이스/...)에 대한 query

4. JFS는 두 종류의 index를 빌드합니다. 하나는 property index이고 다른 하나는 full text index입니다.

5. Property 기반 indexer는 resource로 부터 구조화된 property를 추출하여 SQL 비슷한 방식의 query (structured query)를 사용할 수 있도록 합니다.

6. Text indexer는 resource로 부터 text를 추출하여 Apache Lucene 엔진에 제공하여 full text search ("fuzzy" query)를 제공합니다.

7. repotools -reindex는 offline server에 대해 수행됩니다. 기본적으로 query triple store와 Lucene text store를 빌드합니다. 기본적으로 resource의 최근 버전에 대해서만 빌드합니다. 전체 버전에 대한 빌드는 시간비용이 많이 소요되기 때문입니다.

참고 : Jazz Integration Architecture ( https://jazz.net/projects/DevelopmentItem.jsp?href=content/project/plans/jia-overview/index.html )

8. indexing repository에는 두 종류가 있습니다. 하나는 RDF triple store 로써 SPARQL queriy에서 사용되고, 다른 하나는 full-text search index 입니다.

9. 시스템 정의된 property들은 RDF triple store에 저장됩니다.

property	Type	Description
`dc:creator`	URI	a URI to a resource that represents the user that created this resource.
`dc:created`	datetime	the date and time the resource was created.
`dc:contributor`	URI	a URI to a resource that represents the user that last modified this resource.
`dc:modified`	datetime	the date and time the resource was last modified.
`dc:format`	string	the content-type provided by the client on the last modification of the resource.
`dc:isPartOf`	URI	the URI of the storage namespace this resource belongs to.
`jazz:etag`	string	the ETag value last calculated for the resource.
`jazz:resourceContext`	URI	the URI of the owning security context.
`jazz:resourceLocation`	URI	the internal storage URI of this resource.
`rdf:type`	URI	If the resource is XML or RDF then this represents a URI constructed from the root element in the document.

참고자료 : https://jazz.net/wiki/bin/view/Main/QueryServicesRequirements

resource store와 index store의 분리

indexing 과정

query 과정

RDF & SPAQL

2012-01-06T15:35:00.000+09:00

출처 : http://www.w3.org/TR/rdf-concepts/

The Resource Description Framework (RDF) is a framework for representing information in the Web.

The underlying structure of any expression in RDF is a collection of triples, each consisting of a subject, a predicate and an object. A set of such triples is called an RDF graph.

a subject,
an object, and
a predicate (also called a property) that denotes a relationship.

RDF 예

<http://reqs.com/req/1234> rdf:type oslc_rm:Requirement

<http://reqs.com/req/1234> dcterms:title "Smooth upgrade path"

<http://reqs.com/req/1234> oslc_rm:elaboratedBy <http://reqs.com/req/7772>

<http://reqs.com/req/1234> oslc_rm:validatedBy <http://tests.com/test/521>

<http://tests.com/test/521> rdf:type oslc_qm:TestCase

<http://tests.com/test/521> dcterms:title "Verify compatibility"

<http://tests.com/test/521> oslc_qm:usesTestScript <http://tests.com/script/13>

SPARQL is standard query language for RDF datasets

SPARQL 예

SELECT ?uri ?title WHERE {

?uri rdf:type oslc_rm:Requirement .

?uri dcterms:title ?title .}

결과

uri	title
<http://reqs.com/req/1234>	"Smooth upgrade path"

TESTRT - Using Eclipse CDT on Windows

2012-01-05T17:01:00.003+09:00

출처 : http://www.ibm.com/developerworks/opensource/library/os-eclipse-stlcdt/

Get products and technologies

Learn about MinGW, the GNU C/C++ tools for Windows included with Cygwin.
Download Cygwin a Linux-like environment for Windows. It consists of two parts: A DLL that acts as a Linux API emulation layer providing substantial Linux API functionality and a collection of tools that provide a Linux look and feel.
Once you're done installing, you'll need to add gcc, g++, make, and GDB to your path. (예 : ;C:\MinGW\msys\1.0\bin;C:\MinGW\bin )
The Eclipse C/C++ Development Toolkit (CDT) download information contains the latest information about the available versions of CDT. (TestRT 이클립스 클라이언트 사용시 설치 필요없음)

(1) New C project

(2) New > Source Folder.

(3) New > Source File

(4) Project > Build Project

(5) Run > Run Configurations
- 실행할 바이너리를 선택한 후 Apply를 함

- run 버튼을 클릭하여 실행함
- 콘솔의 실행결과를 확인함

(6) C Project를 TestRT Project로 변경

- TDP를 선택합니다.

(7) 프로젝트를 빌드합니다. (Active Configuration은 Debug에서 TestRT로 바뀐 상태임)

(8) 실행파일을 우 클릭 후 Run As > Run instrumented application으로 실행합니다.

(9) 실행결과를 클릭하여 coverage report를 봅니다.

옵션 : 다른 리포트를 보고자 하는 경우에는 TestRT build configuration을 수정합니다.
- 프로젝트 속성에서 다른 리포트를 선택합니다.

- build clean, build project, run instrumented application을 실행합니다.

- 결과를 보기 위해 command windows에서 studio를 실행합니다.

- 결과 리포트를 열람합니다.

RTC Project Area 목록을 구하기 위한 OSLC 코드

2012-01-04T14:22:00.002+09:00

출처 : https://jazz.net/forums/viewtopic.php?t=12745


Http http = new Http();

HttpRequest req = new HttpRequest();



// get the root document link to the catalog



req.setEndpoint(settings[0].ServerAddress__c+settings[0].BaseDocument__c);     

req.setMethod('GET');

res = http.send(req);

if(res.getStatusCode()==200)

{

 // get the providers element

 Dom.XMLNode providers = res.getBodyDocument().getRootElement().getChildElement('cmServiceProviders', 'http://open-services.net/xmlns/cm/1.0/');

 // and the catalog URL

 String attr=providers.getAttributeValue('resource','http://www.w3.org/1999/02/22-rdf-syntax-ns#');

 req.setEndpoint(attr);

 req.setMethod('GET');

 // set the userid/pw to operate under.

 Blob headerValue = Blob.valueOf(settings[0].UserName__c + ':' + settings[0].UserPW__c);

 String authorizationHeader = 'BASIC ' + EncodingUtil.base64Encode(headerValue);

 req.setHeader('Authorization', authorizationHeader);

 // send the request

 res = http.send(req);

  

 // should come back with an authorization request redirect (302)

 if(res.getStatusCode()==302)

 {                       

  // get the sessionid string from the returned cookies 

  String[] cookies = res.getHeader('Set-Cookie').split(';');

  String sessionid='';

  for(Integer i=0;i<cookies.size();i++)

  {

   if (cookies[i].startswith('JSESSIONID'))

   {     

    sessionid=cookies[i];                 

    break;

   }

  }



  // set the redirect endpoint

  req.setEndpoint(res.getHeader('Location')); 

  // and the session id

  req.setHeader('Cookie',sessionid);

  req.setMethod('GET');

  res = http.send(req);

  //

  if(res.getStatusCode()==200)

  {

   //  we will have to deal with form logon later

   String pw = settings[0].SecurityString__c;

   pw=pw.replaceFirst('uname',settings[0].Username__c);

   pw=pw.replaceFirst('upw',settings[0].Userpw__c);

   req.setEndpoint(settings[0].ServerAddress__c + pw);

   //req.setHeader('Referer',res.getHeader('Location'));

   req.setMethod('GET');

   req.setHeader('ContentType','application/x-www-form-urlencoded');

   req.setHeader('Cookie',sessionid);

   res = http.send(req);                     

  }

  // spin thru the remaining redirects..

  while(res.getStatusCode()==302)

  {                     

   // redirect after login

   req.setEndpoint(res.getHeader('Location')); 

   req.setHeader('Cookie',sessionid);

   req.setMethod('GET');

   res = http.send(req);

  }

  // we should have the project list document now

  System.debug(res.getHeaderKeys());

  System.debug(res.getBody());

  // find the first project 'entry' node

  Dom.XMLNode project = res.getBodyDocument().getRootElement().getChildElement('entry','http://open-services.net/xmlns/discovery/1.0/');

  do

  {

    Dom.XMLnode provider = project.getChildElement('ServiceProvider','http://open-services.net/xmlns/discovery/1.0/');

    String projectName =provider.getChildElement('title','http://purl.org/dc/terms/').getText();

    String projectServicesURL = provider.getChildElement('services','http://open-services.net/xmlns/discovery/1.0/').getAttributeValue('resource','http://www.w3.org/1999/02/22-rdf-syntax-ns#');                                                           

    req.setEndpoint(projectServicesURL); 

    req.setHeader('Cookie',sessionid);

    req.setMethod('GET');

    res = http.send(req);

    // get the services list document

    if(res.getStatusCode()==200)

    {

     DOM.XMLNode serviceslist = res.getBodydocument().getRootElement();

     //System.debug(serviceslist);

     Dom.XMLNode changeRequests = serviceslist.getChildElement('changeRequests','http://open-services.net/xmlns/cm/1.0/');

     //System.debug(changeRequests);

     Dom.XMLNode workitemFactory = changeRequests.getChildElement('factory','http://open-services.net/xmlns/cm/1.0/');

     String workitemCreateUrl;

     if(workitemFactory.getAttributeValue('default','http://open-services.net/xmlns/cm/1.0/')=='true')

     {

      workitemCreateUrl = workitemFactory.getChildElement('url','http://open-services.net/xmlns/cm/1.0/').getText();

      system.debug(workitemCreateUrl);

     }

     String workitemQueryURL = (changeRequests.getChildElement('simpleQuery','http://open-services.net/xmlns/cm/1.0/')).getChildElement('url','http://open-services.net/xmlns/cm/1.0/').getText();

     //system.debug(workitemQueryUrl);

     //System.debug(workitemfactory);

     ExportValue e=new ExportValue(projectName, workitemCreateUrl, workitemQueryURL);

     result.add(e);

    }

    // find the projects parent node

    Dom.XMLNode parent = project.getparent();

    // remove the project node from the document

    parent.removeChild(project);

    // find the next project entry

    project = parent.getChildElement('entry','http://open-services.net/xmlns/discovery/1.0/');

  } while (project!=null);

 }

}

CCCQ8 CM Architecture Change

2012-01-02T16:40:00.000+09:00

간단해진 CCRC WAN Server Version 8 구조
- 버전8로 오면서 CCRC WAN Server의 성능과 확장성이 배가되었습니다.
- UCM/CQ 통합시 OSLC(HTTP연결)를 사용하며 CQIntSrv를 사용하지 않음
- Base CC/CQ 통합시에는 기존의 방식을 사용함
CQ CM Server (7.x와 동일)

참고 : 기존 CCCQ7 CM Architecture

Jazz Application Framework Overview

2011-12-31T11:09:00.000+09:00

https://jazz.net/wiki/bin/view/Main/JAFIntroduction

When building an application using JAF, it is helpful to simplify the topology and think about the following pieces:

-
When building an application on the Jazz platform, there are two distinct kinds of shared implementation capabilities:

Integration services, which can be employed for the purpose of integrating tools. These integration services should have the same loosely-coupled, protocol-driven characterstics as OSLC.
Application frameworks, which can be used to develop Jazz-based products from the ground up. These frameworks may make use of the integration services.

The Jazz Application Frameworks (JAF) aims to provide:

Architectural guidance for designing new Jazz products that have a common look, behavior and collaboration capabilities.
An JAF SDK in the form of an empty OSGi application shell that provides a framework for a richer, more dynamic and layered application.
참고: https://jazz.net/wiki/bin/view/Main/JAFSdkContents
A set of reusable features packaged as OSGi bundles that can optionally be embedded in the SDK to provide a range of common functionalities, including Web UI frameworks or toolkits, process capabilities, a persistance layer with query capabilities, reporting and data warehousing, and others.
A set of low-level common utils and libraries that can be deployed as OSGi bundles or plain JARs. For example, OAuth helpers, Jazz HTTP clients.
A Jazz Team Server (JTS) providing common user admininistration, delegated authentication, licensing, dashboards, and data warehousing to the applications associated with it.

Jazz Application Framework Transition

2011-12-31T10:30:00.000+09:00

https://jazz.net/wiki/bin/view/Main/JAFSdkTransition

FROM

an application that was developed with the older Application SDK 3.x.x.x, using functional services from a shared Jazz Team Server (JTS).
The Application SDK included a framework for defining application REST services. Application services were declared in plugin.xml files as extensions of the com.ibm.team.jfs.app.restServices extension point, and implemented as extensions of the com.ibm.team.jfs.app.RestService class.
Fronting applications only needed to build against a few Foundation features:
- com.ibm.team.jfs.sdk.runtime.feature
- net.jazz.ajax.app.jfs.feature
- net.jazz.ajax.app.jfs.feature

use the new JAF SDK 4.x.x.x, using local functional services and data storage.
the JAF SDK includes the Jazz OSGi services framework (see the HelloJAF tutorial for a brief introduction).
the JAF SDK is considered to be this set of features:
- com.ibm.team.app.server.jfs.feature
- com.ibm.team.dashboard.server.jfs.feature
- com.ibm.team.gateway.server.jfs.feature
- com.ibm.team.jazz.server.feature
- com.ibm.team.process.server.jfs.feature
- com.ibm.team.reports.server.jfs.feature
- com.ibm.team.repository.server.jfs.feature
- com.ibm.team.repository.services.jfs.feature
- net.jazz.ajax.app.jfs.feature
- net.jazz.ajax.jfs.feature

https://jazz.net/wiki/bin/view/Main/JAFSdkIntroduction

Jazz Application Frameworks SDK

One of the primary deliverables of the Jazz Application Frameworks is an SDK for building applications. This SDK takes the form of an empty OSGi application shell that provides a framework for a rich, dynamic layered application. Applications embed functional services from this SDK, which they invoke locally. Some integration services, such as user management, licensing and authentication, are delegated to a Jazz Team Server (JTS) which may be shared amongst multiple applications. This SDK will be part of the Jazz Application Frameworks 4.0 release.

The history of the SDK

A brief word is required here to explain the multiple SDKs which exist, and where the JAF SDK fits in to the story.

Jazz 0.6 SDK

The "0.6 SDK" included local execution of functional services in an OSGi application. It included a repository service framework, a persistence story, process, reporting, Web UI, and dashboards. Such an application has a local database for storage. RTC and RQM are based on the Jazz 0.6 SDK.

Application SDK

The Application SDK described OSGi or pure Java "fronting applications" which rely on a shared JTS for functional services such as storage. It communicated with the JTS using REST to consume these services. RRC is a fronting application based on the Application SDK.

JAF SDK

In 2012, the preferred approach for building applications on JAF is changing. Instead of creating fronting applications that consume functional services from a shared JTS, applications will embed the functional services and invoke them locally. There are a number of advantages to this approach, including reducing the load on the JTS and unifying two SDK stories into one. The JAF SDK is essentially the 0.6 SDK, with some compatibility and transition add-ons to aid applications which are currently build on the Application SDK. Applications will continue to use the JTS for integration services.

-

Jazz 로그

2011-12-30T23:40:00.000+09:00

서버 로그

째즈서버 로그 : jazz/server/logs/jazz.log
톰캣서버 로그 : jazz/server/tomcat/logs/*.log

서버 로그를 영문으로 캡처하는 방법

톰캣 : \jazz\server\server.startup.bat 파일을 수정

set JAVA_OPTS=%JAVA_OPTS% -Duser.language=en -Duser.region=US
set JAVA_OPTS=%JAVA_OPTS% -Djava.awt.headless=true
...

Jazz 빌드엔진을 영문으로 띄우는 방법

\jazz\buildsystem\buildengine\eclipse\jbe.ini 파일을 수정합니다.
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Duser.language=en
-Duser.region=US

Jazz 웹 자바스크립트 에러 로그를 캡처하는 방법

1. 디버그 모드를 활성화하는 방법

https://host:port/jazz/web/projects/ProjectArea?debug=true#action=com.ibm.team.workitem.viewWorkItem&id=131615

2. Firebug를 통한 javascript 콘솔 로그를 잡는 방법

클라이언트 로그

이클립스 로그 : 작업공간\.metadata\.log

이클립스 영문로그를 캡처하는 방법

\jazz\client\eclipse\eclipe.exe의 바로 가기를 만들고, 바로 가기의 속성창에서
대상에 \jazz\client\eclipse\eclipse.exe -nl en_US 를 추가해 줍니다.

SCM - 소스코드 엑세스 로그

2011-12-30T23:04:00.001+09:00

https://jazz.net/wiki/bin/view/Main/SCMScaa

In your RTC deployment, you may wish to log access to the File content in your repository, for traceability rationale. While this support is disabled by default, it can be enabled through the use of log4j.

To enable logging, uncomment the following section from the bottom of of jazz/server/conf/jazz/log4j.properties

#log4j.appender.scm_scaa=org.apache.log4j.RollingFileAppender #log4j.appender.scm_scaa.layout=org.apache.log4j.PatternLayout #log4j.appender.scm_scaa.layout.ConversionPattern=%m %n #log4j.appender.scm_scaa.File=scaa_content.log #log4j.appender.scm_scaa.MaxBackupIndex=10 #log4j.appender.scm_scaa.MaxFileSize=7000KB
#log4j.logger.scm_scaa=TRACE, scm_scaa

This will create a scaa_content.log file in jazz/server/logs. The log will be rotated between 10 files of 7MB each.
Logging will occur as users access content from the server. Nothing will be written to the logs if there is no user activity.
To process this data for use in another tool, you should convert this configuration FileAppender and pipe the file into the script or program.

The format of the log entries are as follows:

SCAA:{0}/{1},{2},{3},{4}/{5},{6}

where :

{0} is the contributor's userid
{1} is the item type (in RTC 2.0, most commonly FileItem^?)
{2} is the last segment of the item's path (Foo.java)
{3} is the item's identifier
{4} is the item's state or version identifier
{5} is the component's name or label
{6} is the component's identifier

While there is not a huge overhead to logging content access, the logfiles can grow fairly large quickly. In the default configuration, it may take less than a day for the 10 logfiles to completely rollover, depending on the number of developers and build engines your server hosts.

Jazz 서버 - 로그인/엑세스 로그

2011-12-30T22:54:00.001+09:00

JTS : login information in the server log.
Tomcat : \server\tomcat\logs\localhost_access_log.yyyy-mm-dd - pick out some information about login from the tomcat local access log.
WAS : C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\logs

RTC를 이용한 Code Review Process

2011-12-30T22:22:00.000+09:00

Project configuration

Precondition : "Require Work Item Approval"
for "Deliver (client)" operation
for "Everyone" role.
In the "Required approvals", for the "Review" type, at least one from "Everyone" role (or "Team Member" role) is set.
"User may overrule" may also be checked if not all code delivery may require a review process.

Scenario
There are three developers - D1, D2 & D3 - all using RTC Eclipse client.

D1 does the code change for files f1 & f2 in her local workspace and saves them. f1 and f2 appears as unresolved in the pending changes view.
D1 checks-in f1 & f2 into a new change set "CS".
Right clicks on "CS" and select "Submit for Review" menu option and associate to a WI (existing or a new one) and select approvers - D2 as the approver for f1 review (subject field is used to tell what to review) and D3 as approver for f2 review.
The approval/Review process will be in the pending state.
D2 & D3 gets intimation of the review task assigned to them through a query - "Pending approvals for me".
D2 opens the WI and in the Links section, double clicks on the f1 in the change set and see the diff in the Change Explorer. Does the review. Optionally, adds comment for D1 in the discussion field of the WI. Changes the Review approval state from pending to approved.
D3 follows the same process as D2 but rejects because the f3 code change is not acceptable. Changes the Review approval state from pending to rejected.
D1 gets the review comment via email/feed - because D1 is the owner and the subscriber of the WI.
D1 fixes the code in f2 based on D3's review and checks in to the same changeset.
D1 adds D3 again for the new review approval in the same WI.
D3 gets intimation of the review task assigned to him through a query - "Pending approvals for me".
D3 opens the WI and in the Links section, double clicks on the f2 in the changeset and see the diff in the Change Explorer. Does the review. Optionally, adds comment for D1 in the discussion field of the WI. Changes the Review approval state from pending to approved.
D1 gets the review comment via email/feed - because D1 is the owner and the subscriber of the WI.
D1 delivers the changeset (or invokes "Complete" action on the changeset) because all the approvals in the WI are in approved state.
The complete history of the code review process (rejected ones, approved ones) are in the "Approvals" tab.

제안 https://jazz.net/wiki/bin/view/Main/SCMChangeSetReview
-

SCM - 베이스라인 BOM CLI

2011-12-30T19:31:00.000+09:00

https://jazz.net/wiki/bin/view/Main/SCMCommandLineBillOfMaterials

This story is to support the following workflow with the RTC Command line:

A user will be able to navigate to a baseline or snapshot using scm list command
A user will be able to run a command to output a listing which describes the configuration as follows
- for every item in the snapshot/baseline, we print a row which describes the path, item-id & state-id

A user will be able to extract a particular content from the repository using the state-id as a selector

참조 : When storing a reference to another item, RTC store an item handle, which is: item type + item UUID [+ optional state id (if referring to a particular state of an auditable item)].

IItemHandle handle = IComponent.ITEM_TYPE.createHandle(uuid, null);
ITeamRepository repo = ...;
IItem item = repo.itemManager.fetchCompleteItem(handle, IItemManager.DEFAULT, null);
IItemType type = item.getItemType();
System.out.println("Simple type name: " + type.getName());
System.out.println("Type's namespace: " + type.getNamespaceURI());
-
웹브라우저 이용시
- copy the UUID
- paste it into a URL of the form:
/resource/itemOid/com.ibm.team.scm.Component/_DC6QYM0yEd2CTNaxDdYRfg?_mediaType=text/xml
(replacing the UUID there with yours)
- open this in a web browser
- there the XML should indicate the type

URI format for IVersionedContentService is:

//content/////

URI format for IFilesystemContentService is:

https://:/jazz/service/com.ibm.team.filesystem.service.internal.rest.IFilesystemContentService/-/COMPONENT_UUID/filename.txt?itemId=RESOURCE_UUID&stateId=RESOURCE__STATE_UUID&platformLineDelimiter=CRLF

CQ OSLC CM 2.0 REST API

2011-12-30T18:39:00.001+09:00

https://jazz.net/wiki/bin/view/Main/CqOslcV2

OSLC 란?
OSLC는 소프트웨어 딜러버리 라이프싸이클 관련 리소스 및 인터페이스 표준화 관련 커뮤니티입니다. 이를 통해 ALM 도구 간의 통합을 지원합니다. 다른 한편으로 CQ 같은 하나의 도구의 리소스를 작업하기 위한 API로 사용할 수 있습니다.
더 자세한 정보는 http://open-services.net/.

REST 란?
REST는 아키텍처 스타일로서

리소스는 URI를 가집니다.
리소스는 다양한 표현을 가집니다.
리소스는 이러한 표현을 통해 변경할 수 있습니다.

CQ의 리소스의 예로 레코드, 쿼리 등이 있습니다. CQ는 각 리소스를 RDF/XML, JSON 등 다양한 표현을 지원합니다. OSLC는 다양한 HTTP 메쏘드를 제공합니다.

GET 메쏘드는 리소스를 가져옵니다.
PUT 메쏘드는 리소스를 갱신합니다.
POST 메쏘드는 새로운 리소스를 생성합니다.
DELETE 메쏘드는 리소스를 삭제합니다.

예를 들어, 리소스를 갱신할 때는 먼저 GET 메쏘드를 통해 리소스를 가져오고, 프로퍼티를 수정한 뒤에, PUT 메쏘드를 통해 다시 리소스를 갱신합니다. 보다 자세한 정보는 Working with Records.

CQ REST API 버전들

CQ 7.1.0.0 웹에서 REST API를 처음 지원합니다.
RTC 2.0과 CQ 7.1.1.0에서 OSLC-CM 1.0 REST API를 지원합니다.
CQ 7.1.2.1에서 여기 소개된 OSLC-CM 2.0을 지원합니다.

OSLC 2.0 사용법

OSLC 2.0 API를 사용할 때는 HTTP 요청 전 요청 헤더 OSLC-Core-Version의 값을 2.0으로 설정합니다.

OSLC-Core-Version: 2.0

이 헤더를 설정하지 않으면 하위 호환성을 위해 OSLC-CM 1.0 응답을 제공합니다.

CQ OSLC 1.0과 CQ OSLC 2.0의 차이점

CQ OSLC 2.0의 XML 응답은 RDF/XML 표현입니다. Resource Representations 참고하세요.
CQ OSLC 2.0의 RDF/XML와 JSON 응답은 표준 OSLC ChangeRequest 프로퍼티와 CQ 필드 값을 함께 제공합니다.
PUT 요청시, oslc.properties 패리미터를 설정하지 않을 경우에는, 모든 필드 값을 제공해야 합니다. Working with Records: PUT 참고하세요.
CQ OSLC 2.0에서는 각 레코드 유형별 쿼리 URL을 제공합니다.
네임스페이스 및 패러미터 이름은 OSLC-CM 2.0 Specification를 참고하세요.

리소스의 표현
CQ는 모든 리소스에 대한 RDF/XML (application/rdf+xml) 표현, JSON (application/json) 표현을 제공합니다. 쿼리인 경우, Atom (application/atom+xml) 표현도 지원하고, 레코드인 경우, HTML (text/html) 표현을 제공합니다. 콘텐츠 유형은 HTTP Accept 요청 헤더를 통해 표시합니다 (RFC 2616 참조). 예를 들면 RDF/XML 콘텐츠 유형을 요청할 경우, 아래 요청 헤더를 사용합니다. (Accept 헤더를 설정하지 않은 경우에 디폴트로 아래 값을 사용합니다.)

Accept: application/rdf+xml

아래처럼 하나 이상의 콘텐츠 유형을 요청할 수 있습니다.

Accept: text/html,application/atom+xml

아래처럼 rcm.contentType 패러미터를 이용해 콘텐츠를 요청할 수 있습니다. 이 경우에는 HTTP Accept 헤더에 설정 값을 무시합니다.

GET http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/?rcm.contentType=application/json

RDF/XML를 사용할 때는 사용 편의성 및 에러방지를 위해 RDF/XML 파싱시, Jena 같은 자바 라이브러리를 사용하길 권장합니다.

인증

CQ OSLC-CM REST API는 사용자 인증을 위해 Basic Access Authentication과 OAuth를 지원합니다. 리소스에 엑세스할 경우에는 인증에 대한 준비를 해야 합니다. 다만 Base URI에 GET 요청을 하고 스키마 저장소 목록을 가져올 경우에는 인증이 필요하지 않습니다. 인증이 필요할 경우에는 401 HTTP 상태 코드를 수반합니다.

Basic access authentication과 OAuth 중 어느 것을 사용할지?

대부분의 경우 Basic access authentication를 사용할 수 있습니다. 간단하며 셋업이 필요하지 않습니다. 다만 SSL을 사용하지 않는 경우 보안이 약합니다. 그리고 RFC2617에서 정의한바 비(非) ASCII 사용자 ID를 지원하지 않습니다.

OAuth는 관리자 셋업을 필요로 하지만 여러 장점이 있습니다. 사용자 ID와 암호가 필요하지 않는 까닭에 보다 안전합니다. 대신 CQ가 발행하는 엑세스 토큰으로 인증을 합니다. 엑세스 토큰은 서버 재시작 전까지 유효하며 한명의 사용자만 사용할 수 있습니다. 그렇더라도 SSL을 사용하는 것을 권장합니다.

Basic Access Authentication

Basic access authentication을 사용할때는 사용자 ID와 암호를 Base64 인코딩으로 HTTP 인증 요청 헤더에 명시합니다. SSL을 사용하지 않을 경우 보안에 약합니다.

거의 모든 브라우저에서 Basic access authentication을 지원합니다. CQ OSLC URI를 브라우저에서 탐색을 하게되면, 기존의 활성 세션이 없는 경우에는 사용자의 ID와 암호를 묻게 됩니다.

대부분의 HTTP 클라이언트 라이브러리 또한 Basic access authentication을 지원합니다. 아래 예는 Apache HTTP 클라이언트 사용하여 사용자 ID와 암호를 명시하는 경우입니다.

HttpClient http = new HttpClient();

Credentials credential

= new UsernamePasswordCredentials("user", "password");

http.getParams().setAuthenticationPreemptive(true); http.getState().setCredentials(AuthScope.ANY, credential);

각 HTTP 클라이언트 라이브러리 문서를 참고하시기 바랍니다.

OAuth

시작하기 전에 먼저 OAuth 개념을 이해바랍니다. The Beginner's Guide to OAuth는 훌륭한 자료입니다.

OAuth 라이브러리

OAuth 인증을 사용할 때는 OAuth 라이브러리를 사용하여 요청에 사인을 합니다. 각각의 프로그래밍 언어별 오픈소스 라이브러리는 http://oauth.net/code/에서 찾을 수 있습니다.

OAuth 이용자 등록

OAuth 인증을 사용하기 위해서는 사용하는 애플리케이션을 OAuth 이용자로 등록해야 합니다. 우선 CQ 웹을 어드민으로 로그인을 하고, "Site Administration" 메뉴에서 "OAuth Consumer Management"를 선택합니다. 설정 대화 상자가 나타나면 아래 나와있는 OAuth 이용자 정보를 입력합니다.

프로퍼티	설명
이용자 이름	애플리케이션 이름, 사용자에게 표시됩니다.
이용자 키	값을 지정하며 되며 유일해야 합니다.
이용자 암호	CQ와 애플리케이션간에 공유되는 암호입니다. CQ는 이 암호를 통해서 애플리케이션 요청을 검증합니다. 특정 값을 암호로 지정합니다.
신뢰됨	선택을 할 경우, CQ는 신뢰하는 다른 애플리케이션과 인증을 공유할 수 있습니다.

CQ는 RootServicesSpecAddendum2에 기술된 째즈의 동적 OAuth 이용자 등록 방법 또한 지원합니다. CQ의 루트 서비스 URI는 Base URI에 기술되어 있습니다.

OAuth 토큰 획득하기

OAuth 엑세스 토큰을 획득하는 절차는 아래와 같습니다.

oslc:oauthRequestTokenURI로 OAuth 요청 토큰을 요청합니다.
oslc:authorizationURI로 사용자 인증 처리를 리다이렉트합니다.
oslc:oauthAccessTokenURI로 OAuth 요청 토큰을 OAuth 엑세스 토큰으로 교환합니다.

이들 OAuth URI는 oslc:OAuthConfiguration 자원으로 프로퍼티로써 각 데이터베이스 세트별로 service provider catalog에 정의되어 있습니다.

OAuth 엑세스 토큰은 사용자 대신하여 요청을 할 수 있도록 해주며, CQ 서버가 재시작될때까지 유효합니다.

요청 사인하기

엑세스 토큰으로 요청을 사인할려면 OAuth 라이브러리가 필요합니다. CQ는, OAuth의 제공자로써, HMAC-SHA1 사인 메쏘드를 지원하며, Authorization 헤더, 쿼리 문자열의 일부 및 요청 바디 상의 OAuth 패러미터를 허용합니다. OAuth 1.0a: Parameter Transmission를 참고하세요.

세션 관리

CQ 세션은 클라이언트가 보호된 리소스를 접근할 때 체결되며 비활성 상태로 일정 기간이 지나면 만료됩니다. 만료는 HTTP 세션 타임아웃 또는 CQ 세션 타임아웃시 발생합니다. 일반적으로 세션이 체결될때 라이센스를 가져오며 세션이 만료될 때 라이센스가 릴리즈됩니다.

HTTP 클라이언트로 Base URI 아래 /session/ 컨텍스트에 DELETE 메쏘드를 호출함으로써 명시적으로 CQ 세션을 무효화할 수 있습니다.

요청:

DELETE /cqweb/oslc/session/ HTTP/1.1

Host: quagmire.rtp.raleigh.ibm.com

OSLC-Core-Version: 2.0

응담:

HTTP/1.1 204 No Content

Content-Length: 0

결과로 세션과 관련된 라이센스는 릴리스됩니다.

세션을 추적하기 위해서는 HTTP 클라이언트 사용시 쿠키를 사용 가능하도록 해야 합니다. Apache HTTP 클라이언트를 사용할 경우, http.protocol.single-cookie-header를 true로 설정할 수 있습니다.

HttpClient http = new HttpClient();

http.getParams().setParameter("http.protocol.single-cookie-header", true); http.getParams().setCookiePolicy(CookiePolicy.BROWSER_COMPATIBILITY)

Base URI

OSLC-CM 2.0 엑세스를 위한 Base URI는 아래와 같습니다.

http:///cqweb/oslc/

통합를 위한 CQ 루트 서비스 URI는 아애와 같습니다.

http:///cqweb/oslc/repo//discovery

만약 데이터베이스 세트 이름에 비 ASCII 문자가 있다면 인코딩이 필요함을 주의하시기 바랍니다.

본 자료는 RootServicesSpec을 준수하며 째즈 제품과의 통합을 위해 많이 사용합니다.

서비스 열람

서비스 열람은 OSLC 제공자가 제공하는 기능을 열람하도록 합니다. 그래서 OSLC 제공자와의 작업의 출발점이 됩니다. CQ는 OSLC Core 2.0 스펙을 따른 모델을 제공합니다. 먼저 Base URI에 GET 메쏘드를 호출하여 서비스 제공자 카탈로그를 획득합니다. 카탈로그와 다른 리소스와의 관계는 아래 그림을 참고하세요.

-
서비스 제공자 카탈로그

CQ가 제공하는 최상위 카탈로그는 서버에 정의된 데이터베이스 세트들입니다. 각 데이터베이스 세트는 각각의 사용자를 가지는 까닭에 개별적인 OAuth 구성정보를 가집니다. 각 데이터베이스 세트별로 개별 사용자 데이터베이스 카탈로그 위치를 가지고 있습니다.

아래는 CQ 서비스 제공자 카탈로그 리소스의 RDF/XML 표현 예로써 두개의 데이터베이스 세트: DOC, Links를 나타냅니다.

요청:

GET /cqweb/oslc/ HTTP/1.1
Host: quagmire.rtp.raleigh.ibm.com
OSLC-Core-Version: 2.0
Accept: application/rdf+xml

응답:

HTTP/1.1 200 OK
OSLC-Core-Version: 2.0
Transfer-Encoding: chunked
Content-Type: application/rdf+xml; charset=UTF-8

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns="http://open-services.net/ns/core#" xmlns:dc="http://purl.org/dc/terms/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<ServiceProviderCatalog rdf:about="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc">
<dc:title>Repository</dc:title>
<dc:publisher>
<Publisher>
<dc:title>RCM/CQ OSLC CM Service Description Document</dc:title>
<label>RCM/CQ OSLC CM Service Description Document</label>
<dc:identifier>com.ibm.rational.cm.clearquest</dc:identifier>
<icon rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/_rcm-resources/clearquest.ico"/>
</Publisher>
</dc:publisher>
<serviceProviderCatalog>
<ServiceProviderCatalog rdf:about="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC">
<dc:title>DOC</dc:title>
<details rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/"/>
<oauthConfiguration>

아래는 CQ 서비스 제공자 카탈로그 리소스의 JSON 표현 예로써 두개의 데이터베이스 세트: DOC, Links를 나타냅니다.

요청:

GET /cqweb/oslc/ HTTP/1.1
Host: quagmire.rtp.raleigh.ibm.com
OSLC-Core-Version: 2.0
Accept: application/json

응답: 생략

서비스 기술 문서

각각의 CQ 사용자 데이터베이스는 개별의 서비스 기술 문서를 가지고 있습니다. 이 서비스 기술 문서에는 새로운 레코드 생성과 쿼리를 위한 URL이 정의되어 있고 다른 웹 애플리케이션에서 사용할 수 있는 레코드 선택 및 생성에 필요한 대화상자에 대해 기술하고 있습니다. 각각의 레코드 유형별로 레코드 선택 및 생성 대화상자와 쿼리에 대한 서비스를 제공함을 유의하시기 바랍니다. 또한 디폴트로 제공하는 레코드 선택 대화상자는 레코드 유형을 선택할 수 있는 기능을 제공합니다.

아래는 DefectTracking 스키마의 SAMPL 사용자 데이터베이스가 제공하는 CQ 서비스 기술 문서 리소스에 대한 RDF/XML 표현의 예입니다.

요청:

GET /cqweb/oslc/repo/DOC/db/SAMPL/ HTTP/1.1
Host: quagmire.rtp.raleigh.ibm.com
OSLC-Core-Version: 2.0
Accept: application/rdf+xml

응답:

HTTP/1.1 200 OK
OSLC-Core-Version: 2.0
Transfer-Encoding: chunked
Content-Type: application/rdf+xml; charset=UTF-8

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns="http://open-services.net/ns/core#" xmlns:dc="http://purl.org/dc/terms/" xmlns:cq="http://www.ibm.com/xmlns/prod/rational/clearquest/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<ServiceProvider rdf:about="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL">
<dc:title>RCM/CQ OSLC CM Service Description Document</dc:title>
<dc:description>Rational Change Management/ClearQuest OSLC CM Services available for DOC/SAMPL.</dc:description>
<dc:publisher>
<Publisher>
<dc:title>IBM Rational ClearQuest</dc:title>
<label>IBM Rational ClearQuest</label>
<dc:identifier>com.ibm.rational.cm.clearquest</dc:identifier>
<icon rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/_rcm-resources/clearquest.ico"/>
</Publisher>
</dc:publisher>
<details rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/restapi/DOC/SAMPL?format=html"/>
<prefixDefinition>
<PrefixDefinition>
<prefix>oslc</prefix>
<prefixBase rdf:resource="http://open-services.net/ns/core#"/>
</PrefixDefinition>
</prefixDefinition>
<prefixDefinition>
<PrefixDefinition>
<prefix>oslc_cm</prefix>
<prefixBase rdf:resource="http://open-services.net/ns/cm#"/>
</PrefixDefinition>
</prefixDefinition>
<prefixDefinition>
<PrefixDefinition>
<prefix>dc</prefix>
<prefixBase rdf:resource="http://purl.org/dc/terms/"/>
</PrefixDefinition>
</prefixDefinition>
<prefixDefinition>
<PrefixDefinition>
<prefix>dcterms</prefix>
<prefixBase rdf:resource="http://purl.org/dc/terms/"/>
</PrefixDefinition>
</prefixDefinition>
<prefixDefinition>
<PrefixDefinition>
<prefix>rdf</prefix>
<prefixBase rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#"/>
</PrefixDefinition>
</prefixDefinition>
<prefixDefinition>
<PrefixDefinition>
<prefix>rdfs</prefix>
<prefixBase rdf:resource="http://www.w3.org/2000/01/rdf-schema#"/>
</PrefixDefinition>
</prefixDefinition>
<prefixDefinition>
<PrefixDefinition>
<prefix>foaf</prefix>
<prefixBase rdf:resource="http://xmlns.com/foaf/0.1/"/>
</PrefixDefinition>
</prefixDefinition>
<prefixDefinition>
<PrefixDefinition>
<prefix>cq</prefix>
<prefixBase rdf:resource="http://www.ibm.com/xmlns/prod/rational/clearquest/1.0/"/>
</PrefixDefinition>
</prefixDefinition>
<prefixDefinition>
<PrefixDefinition>
<prefix>oslc_cmx</prefix>
<prefixBase rdf:resource="http://open-services.net/ns/cm-x#"/>
</PrefixDefinition>
</prefixDefinition>
<service>
<Service>
<domain rdf:resource="http://open-services.net/ns/cm#"/>
<creationFactory>
<CreationFactory>
<dc:title>Unattended location for the creation of ClearQuest Records</dc:title>
<label>Unattended location for the creation of ClearQuest Records</label>
<creation rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/record"/>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
<usage rdf:resource="http://open-services.net/ns/core#default"/>
<resourceShape rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/shape/16777224"/>
<resourceShape rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/shape/16777751"/>
<resourceShape rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/shape/16777220"/>
<resourceShape rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/shape/16777222"/>
<resourceShape rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/shape/16777219"/>
<resourceShape rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/shape/16777935"/>
<resourceShape rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/shape/16777221"/>
<resourceShape rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/shape/16777897"/>
<resourceShape rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/shape/16777223"/>
</CreationFactory>
</creationFactory>
<creationDialog>
<Dialog>
<dc:title>New Defect</dc:title>
<dc:description>Web dialog for creating new Defect records</dc:description>
<label>Defect</label>
<dialog rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/record-type/16777224/creationDialog?dc%3Atype=Defect"/>
<hintWidth>703px</hintWidth>
<hintHeight>510px</hintHeight>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
<usage rdf:resource="http://open-services.net/ns/core#default"/>
</Dialog>
</creationDialog>
<creationDialog>
<Dialog>
<dc:title>New Customer</dc:title>
<dc:description>Web dialog for creating new Customer records</dc:description>
<label>Customer</label>
<dialog rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/record-type/16777935/creationDialog?dc%3Atype=Customer"/>
<hintWidth>803px</hintWidth>
<hintHeight>588px</hintHeight>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
</Dialog>
</creationDialog>
<creationDialog>
<Dialog>
<dc:title>New Email_Rule</dc:title>
<dc:description>Web dialog for creating new Email_Rule records</dc:description>
<label>Email_Rule</label>
<dialog rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/record-type/16777751/creationDialog?dc%3Atype=Email_Rule"/>
<hintWidth>727px</hintWidth>
<hintHeight>471px</hintHeight>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
</Dialog>
</creationDialog>
<creationDialog>
<Dialog>
<dc:title>New Project</dc:title>
<dc:description>Web dialog for creating new Project records</dc:description>
<label>Project</label>
<dialog rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/record-type/16777897/creationDialog?dc%3Atype=Project"/>
<hintWidth>651px</hintWidth>
<hintHeight>294px</hintHeight>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
</Dialog>
</creationDialog>
<creationDialog>
<Dialog>
<dc:title>New groups</dc:title>
<dc:description>Web dialog for creating new groups records</dc:description>
<label>groups</label>
<dialog rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/record-type/16777222/creationDialog?dc%3Atype=groups"/>
<hintWidth>722px</hintWidth>
<hintHeight>194px</hintHeight>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
</Dialog>
</creationDialog>
<creationDialog>
<Dialog>
<dc:title>New ratl_replicas</dc:title>
<dc:description>Web dialog for creating new ratl_replicas records</dc:description>
<label>ratl_replicas</label>
<dialog rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/record-type/16777220/creationDialog?dc%3Atype=ratl_replicas"/>
<hintWidth>674px</hintWidth>
<hintHeight>342px</hintHeight>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
</Dialog>
</creationDialog>
<creationDialog>
<Dialog>
<dc:title>New users</dc:title>
<dc:description>Web dialog for creating new users records</dc:description>
<label>users</label>
<dialog rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/record-type/16777223/creationDialog?dc%3Atype=users"/>
<hintWidth>703px</hintWidth>
<hintHeight>376px</hintHeight>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
</Dialog>
</creationDialog>
<selectionDialog>
<Dialog>
<dc:title>Choose ClearQuest Record</dc:title>
<dc:description>Web dialog for finding and selecting ClearQuest Record records</dc:description>
<label>ClearQuest Record</label>
<dialog rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/record-type/16777224/selectionDialog?dc%3Atype=cq.repo.cq-rectype%3A16777224%40DOC%2FSAMPL&restrictType=false"/>
<hintWidth>640px</hintWidth>
<hintHeight>540px</hintHeight>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
<usage rdf:resource="http://open-services.net/ns/core#default"/>
</Dialog>
</selectionDialog>
<selectionDialog>
<Dialog>
<dc:title>Choose Defect</dc:title>
<dc:description>Web dialog for finding and selecting Defect records</dc:description>
<label>Defect</label>
<dialog rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/record-type/16777224/selectionDialog?dc%3Atype=cq.repo.cq-rectype%3A16777224%40DOC%2FSAMPL&restrictType=true"/>
<hintWidth>640px</hintWidth>
<hintHeight>540px</hintHeight>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
</Dialog>
</selectionDialog>
<selectionDialog>
<Dialog>
<dc:title>Choose Email_Rule</dc:title>
<dc:description>Web dialog for finding and selecting Email_Rule records</dc:description>
<label>Email_Rule</label>
<dialog rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/record-type/16777751/selectionDialog?dc%3Atype=cq.repo.cq-rectype%3A16777751%40DOC%2FSAMPL&restrictType=true"/>
<hintWidth>640px</hintWidth>
<hintHeight>540px</hintHeight>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
</Dialog>
</selectionDialog>
<selectionDialog>
<Dialog>
<dc:title>Choose ratl_replicas</dc:title>
<dc:description>Web dialog for finding and selecting ratl_replicas records</dc:description>
<label>ratl_replicas</label>
<dialog rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/record-type/16777220/selectionDialog?dc%3Atype=cq.repo.cq-rectype%3A16777220%40DOC%2FSAMPL&restrictType=true"/>
<hintWidth>640px</hintWidth>
<hintHeight>540px</hintHeight>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
</Dialog>
</selectionDialog>
<selectionDialog>
<Dialog>
<dc:title>Choose groups</dc:title>
<dc:description>Web dialog for finding and selecting groups records</dc:description>
<label>groups</label>
<dialog rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/record-type/16777222/selectionDialog?dc%3Atype=cq.repo.cq-rectype%3A16777222%40DOC%2FSAMPL&restrictType=true"/>
<hintWidth>640px</hintWidth>
<hintHeight>540px</hintHeight>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
</Dialog>
</selectionDialog>
<selectionDialog>
<Dialog>
<dc:title>Choose history</dc:title>
<dc:description>Web dialog for finding and selecting history records</dc:description>
<label>history</label>
<dialog rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/record-type/16777219/selectionDialog?dc%3Atype=cq.repo.cq-rectype%3A16777219%40DOC%2FSAMPL&restrictType=true"/>
<hintWidth>640px</hintWidth>
<hintHeight>540px</hintHeight>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
</Dialog>
</selectionDialog>
<selectionDialog>
<Dialog>
<dc:title>Choose Customer</dc:title>
<dc:description>Web dialog for finding and selecting Customer records</dc:description>
<label>Customer</label>
<dialog rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/record-type/16777935/selectionDialog?dc%3Atype=cq.repo.cq-rectype%3A16777935%40DOC%2FSAMPL&restrictType=true"/>
<hintWidth>640px</hintWidth>
<hintHeight>540px</hintHeight>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
</Dialog>
</selectionDialog>
<selectionDialog>
<Dialog>
<dc:title>Choose attachments</dc:title>
<dc:description>Web dialog for finding and selecting attachments records</dc:description>
<label>attachments</label>
<dialog rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/record-type/16777221/selectionDialog?dc%3Atype=cq.repo.cq-rectype%3A16777221%40DOC%2FSAMPL&restrictType=true"/>
<hintWidth>640px</hintWidth>
<hintHeight>540px</hintHeight>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
</Dialog>
</selectionDialog>
<selectionDialog>
<Dialog>
<dc:title>Choose Project</dc:title>
<dc:description>Web dialog for finding and selecting Project records</dc:description>
<label>Project</label>
<dialog rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/record-type/16777897/selectionDialog?dc%3Atype=cq.repo.cq-rectype%3A16777897%40DOC%2FSAMPL&restrictType=true"/>
<hintWidth>640px</hintWidth>
<hintHeight>540px</hintHeight>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
</Dialog>
</selectionDialog>
<selectionDialog>
<Dialog>
<dc:title>Choose users</dc:title>
<dc:description>Web dialog for finding and selecting users records</dc:description>
<label>users</label>
<dialog rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/record-type/16777223/selectionDialog?dc%3Atype=cq.repo.cq-rectype%3A16777223%40DOC%2FSAMPL&restrictType=true"/>
<hintWidth>640px</hintWidth>
<hintHeight>540px</hintHeight>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
</Dialog>
</selectionDialog>
<queryCapability>
<QueryCapability>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
<usage rdf:resource="http://open-services.net/ns/core#default"/>
<dc:title>Simple GET-based Record Query</dc:title>
<label>Defect</label>
<queryBase rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/simpleQuery/16777224"/>
<resourceShape rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/queryShape/16777224"/>
<cq:supportsOslcSearchTerms>false</cq:supportsOslcSearchTerms>
</QueryCapability>
</queryCapability>
<queryCapability>
<QueryCapability>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
<dc:title>Simple GET-based Record Query</dc:title>
<label>Email_Rule</label>
<queryBase rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/simpleQuery/16777751"/>
<resourceShape rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/queryShape/16777751"/>
<cq:supportsOslcSearchTerms>false</cq:supportsOslcSearchTerms>
</QueryCapability>
</queryCapability>
<queryCapability>
<QueryCapability>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
<dc:title>Simple GET-based Record Query</dc:title>
<label>ratl_replicas</label>
<queryBase rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/simpleQuery/16777220"/>
<resourceShape rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/queryShape/16777220"/>
<cq:supportsOslcSearchTerms>false</cq:supportsOslcSearchTerms>
</QueryCapability>
</queryCapability>
<queryCapability>
<QueryCapability>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
<dc:title>Simple GET-based Record Query</dc:title>
<label>groups</label>
<queryBase rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/simpleQuery/16777222"/>
<resourceShape rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/queryShape/16777222"/>
<cq:supportsOslcSearchTerms>false</cq:supportsOslcSearchTerms>
</QueryCapability>
</queryCapability>
<queryCapability>
<QueryCapability>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
<dc:title>Simple GET-based Record Query</dc:title>
<label>history</label>
<queryBase rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/simpleQuery/16777219"/>
<resourceShape rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/queryShape/16777219"/>
<cq:supportsOslcSearchTerms>false</cq:supportsOslcSearchTerms>
</QueryCapability>
</queryCapability>
<queryCapability>
<QueryCapability>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
<dc:title>Simple GET-based Record Query</dc:title>
<label>Customer</label>
<queryBase rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/simpleQuery/16777935"/>
<resourceShape rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/queryShape/16777935"/>
<cq:supportsOslcSearchTerms>false</cq:supportsOslcSearchTerms>
</QueryCapability>
</queryCapability>
<queryCapability>
<QueryCapability>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
<dc:title>Simple GET-based Record Query</dc:title>
<label>attachments</label>
<queryBase rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/simpleQuery/16777221"/>
<resourceShape rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/queryShape/16777221"/>
<cq:supportsOslcSearchTerms>false</cq:supportsOslcSearchTerms>
</QueryCapability>
</queryCapability>
<queryCapability>
<QueryCapability>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
<dc:title>Simple GET-based Record Query</dc:title>
<label>Project</label>
<queryBase rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/simpleQuery/16777897"/>
<resourceShape rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/queryShape/16777897"/>
<cq:supportsOslcSearchTerms>false</cq:supportsOslcSearchTerms>
</QueryCapability>
</queryCapability>
<queryCapability>
<QueryCapability>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
<dc:title>Simple GET-based Record Query</dc:title>
<label>users</label>
<queryBase rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/simpleQuery/16777223"/>
<resourceShape rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/queryShape/16777223"/>
<cq:supportsOslcSearchTerms>false</cq:supportsOslcSearchTerms>
</QueryCapability>
</queryCapability>
<cq:queryNavigatorDialog>
<Dialog>
<usage rdf:resource="http://open-services.net/ns/core#default"/>
<resourceType rdf:resource="http://open-services.net/ns/cm#ChangeRequest"/>
<dc:title>Choose Query - IBM Rational ClearQuest</dc:title>
<dc:description>Web dialog for choosing named queries</dc:description>
<dialog rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/queryNavigatorDialog"/>
<hintWidth>325px</hintWidth>
<hintHeight>375px</hintHeight>
</Dialog>
</cq:queryNavigatorDialog>
<cq:namedQuery>
<cq:NamedQuery>
<dc:title>Location for named queries and folders</dc:title>
<url xmlns="http://www.ibm.com/xmlns/prod/rational/clearquest/1.0/">http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/query-folder</url>
</cq:NamedQuery>
</cq:namedQuery>
<cq:schema>
<cq:Schema>
<dc:title>URL to request record type definitions in XSD</dc:title>
<url xmlns="http://www.ibm.com/xmlns/prod/rational/clearquest/1.0/">http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/record-type</url>
</cq:Schema>
</cq:schema>
<cq:localReplica>
<cq:Replica>
<dc:title><local></dc:title>
</cq:Replica>
</cq:localReplica>
<cq:defaultRecordType>
<cq:RecordType>
<dc:title>URL of the default record type</dc:title>
<url xmlns="http://www.ibm.com/xmlns/prod/rational/clearquest/1.0/">http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/record-type/16777224</url>
</cq:RecordType>
</cq:defaultRecordType>
</Service>
</service>
<oslc_cmx:whoami xmlns:oslc_cmx="http://open-services.net/ns/cm-x#" rdf:resource="http://quagmire.rtp.raleigh.ibm.com/cqweb/oslc/repo/DOC/db/SAMPL/whoami"/>
</ServiceProvider>
</rdf:RDF>

리소스 형태

CQ는 레코드를 충분히 커스텀할 수 있는 기능을 제공합니다. 새로운 레코드 타입을 정의하고 각 레코드 타입에 들어갈 필드를 선택할 수 있습니다. 그렇다면 특정 CQ 사용자 데이터베이스에 있는 특정 레코드 타입에 정의된 필드는 어떻게 알 수 있을까요?

이를 돕기 위해 OSLC 리소스 형태를 제공합니다. 리소스 형태는 각 필드의 타입 뿐만 아니라 레코드에 정의된 필드들에 대한 정보를 알려줍니다. 또한 어떤 필드가 필수 요소이며 어떤 값이 유효한지 알수 있습니다. OSLC Core 2.0 스펙: 부록 A에 정의된 oslc:ResourceShape Resource 를 참고하시기 바랍니다.

레코드 타입 형태

레코드 타입에 대한 형태는 여러 곳에서 파악할 수 있습니다. 예를 들면,

레코드의 oslc:instanceShape 프로퍼키
서비스 기술 문서에 있는 레코드 생성 팩토리의 oslc:resourceShape 프로퍼티
쿼리 형태의 oslc:valueShape 프로퍼터

쿼리 결과 형태

CQ는 또 쿼리 결과 형태에 대한 정보를 제공합니다.

아래는 CQ 쿼리 결과 형태에 대한 JSON 표현의 예입니다.

요청:

GET /cqweb/oslc/repo/DOC/db/SAMPL/queryShape/16777224
Host: quagmire.rtp.raleigh.ibm.com
OSLC-Core-Version: 2.0
Accept: application/json

응답:

HTTP/1.1 200 OK
OSLC-Core-Version: 2.0
Transfer-Encoding: chunked
Content-Type: application/json; charset=UTF-8

{
   "prefixes":{
      "oslc":"http:\/\/open-services.net\/ns\/core#",
      "rdf":"http:\/\/www.w3.org\/1999\/02\/22-rdf-syntax-ns#",
      "dcterms":"http:\/\/purl.org\/dc\/terms\/"
   },
   "rdf:type":[
      {
         "rdf:resource":"http:\/\/open-services.net\/ns\/core#ResourceShape"
      }
   ],
   "rdf:about":"http:\/\/quagmire.rtp.raleigh.ibm.com\/cqweb\/oslc\/repo\/DOC\/db\/SAMPL\/queryShape\/16777224",
   "dcterms:title":"ClearQuest CM V2 Query Result",
   "oslc:describes":"http:\/\/www.w3.org\/1999\/02\/22-rdf-syntax-ns#Description",
   "oslc:property":[
      {
         "rdf:type":[
            {
               "rdf:resource":"http:\/\/open-services.net\/ns\/core#Property"
            }
         ],
         "oslc:name":"member",
         "oslc:propertyDefinition":{
            "rdf:resource":"http:\/\/www.w3.org\/2000\/01\/rdf-schema#member"
         },
         "oslc:valueType":"http:\/\/open-services.net\/ns\/core#AnyResource",
         "oslc:occurs":{
            "rdf:resource":"http:\/\/open-services.net\/ns\/core#Zero-or-many"
         },
         "oslc:range":{
            "rdf:resource":"http:\/\/open-services.net\/ns\/cm#ChangeRequest"
         },
         "oslc:valueShape":{
            "rdf:resource":"http:\/\/quagmire.rtp.raleigh.ibm.com\/cqweb\/oslc\/repo\/DOC\/db\/SAMPL\/shape\/16777224"
         },
         "oslc:representation":{
            "rdf:resource":"http:\/\/open-services.net\/ns\/core#Inline"
         },
         "oslc:readOnly":"true",
         "oslc:isMemberProperty":"true"
      }
   ]
}

OSLC-CM 2.0 ChangeRequest 리소스에 대한 지원

OSLC 2.0 Change Management 스펙은 ChangeRequest 리소스에 대해 정의하고 있습니다. 이 리소스는 OSLC 제공자가 공통으로 갖는 프로퍼티들을 갖고 있습니다. CQ 또한 이러한 프로퍼티 대부분을 지원합니다.

모든 레코드에 공통인 표준 프로퍼티들

아래 표준 ChangeRequest 프로퍼티들은 모든 유형의 레코드에서 제공합니다.

dcterms:title
rdf:type
dcterms:type
dcterms:identifier
oslc_cm:shortTitle
oslc:instanceShape

추가로 상태를 갖는 레코드에는 다음 프로퍼티를 제공합니다.

oslc_cm:status

OSLCLinks 패키지에서 제공하는 표준 프로퍼티들

레코드 타입에 OSLCLinks 패키지를 적용한 경우 추가적으로 제공하는 OSLC ChangeRequest 프로퍼티들이 있습니다.

OSLCLinks 1.0

OSLCLinks 1.0 패키지는 여느 레코드와의 링크를 허용합니다. OSLC-CM 2.0에서 정의한 모든 링크 타입이 지원됩니다.

oslc_cm:relatedChangeRequest
oslc_cm:affectsPlanItem
oslc_cm:affectedByDefect
oslc_cm:tracksRequirement
oslc_cm:implementsRequirement
oslc_cm:affectsRequirement
oslc_cm:testedByTestCase
oslc_cm:affectsTestResult
oslc_cm:blocksTestExecutionRecord
oslc_cm:relatedTestExecutionRecord
oslc_cm:relatedTestCase
oslc_cm:relatedTestPlan
oslc_cm:relatedTestScript
oslc_cm:tracksChangeSet

OSLCLinks 1.1

OSLCLinks 1.1 패키지는 상태 값 프로퍼티를 제공합니다.

oslc_cm:closed
oslc_cm:inprogress
oslc_cm:fixed
oslc_cm:approved
oslc_cm:reviewed
oslc_cm:verified

스키마에서 정의된 워크플로우에 맞게 상태 값을 설정하기 위해서는 훅(Hook)이 필요합니다. OSLCLinks 패키지 관련 문서를 참고하세요.

그 밖의 표준 프로퍼티들

ALM 스키마를 사용한 경우 OOTB로 oslc:description, dcterms:creator, dcterms:contributor 등의 OSLC ChangeRequest 프로퍼티들을 제공합니다. 레코드에서 사용할 수 있는 OSLC 프로퍼티들을 파악하기 위해서는 레코드에 대한 oslc:instanceShape를 요청해서 알아볼 수 있습니다.

레코드에 대한 작업 예제

생략

RTC OSLC CM 2.0 REST API

2011-12-30T18:39:00.000+09:00

출처 : https://jazz.net/wiki/bin/view/Main/WorkItemAPIsForOSLCCM20

This document is the next version of ResourceOrientedWorkItemAPIv2 and describes services offered by RTC 3.0.1 Work Items Service provider implementing OSLC CM 2.0 specifications. This version of service provider is much enhanced from earlier version that has more kinds of resource formats, operations etc. Most of the services and operations existed in previous version are still supported but change is only in semantics which are programmatic friendly. This document explains how Work item service provider can be consumed by referring to OSLC CM 2.0 specifications with good examples. The example snippets assume that you are authenticated to a server configured for form-based auth. These examples can be tried on a browser or by using POSTER plug in on Fire Fox.

Introduction

OSLC CM 2.0 Specification document defines a RESTful web services interface for Change Management systems, like RTC, the management of product change requests, activities, tasks and relation ships between those and related resources such as project, category, release, and plan. To support these scenarios, it defines a set of HTTP-based RESTful interfaces in terms of HTTP methods: GET, POST, PUT, and DELETE, HTTP response codes, content type handling and resource formats. RTC Work Items Service provider implements these OSLC CM specifications as a server which can be consumed by clients. Some of the specifications defined by OSLC and implemented by Work Items Service Provider are listed below:

Resource Definitions - Defining resources like Service Provider, Work Item and other related resources like Users, Comments etc.,
Resource Formats and Representations - Each defined resource is represented in all the formats specified by OSLC.
- Format type - application/rdf+xml - Resource should be in RDF/XML representation.
- Format type - application/json - Resource should be in JSON representation.
- Format type - application/xml - Resource should be in OSLC-defined abbreviated XML representation.
- Format type - application/atom+xml - Resource should be in Atom Syndication Format XML representation.

Resource Operations - Updating or Deleting properties of resources (Work Item and other related resources) using HTTP methods
Creation Factories - To create a resource (Work Item and other related resources) by posting its representation.
Query Capabilities - To fetch resources (Work Item and other related resources) using queryable conditions, search terms, selecting properties and sorting orders.
Resource Paging - To fetch collection of resources (Work Item and other related resources) in pages with user defined sizes.
Delegated UI Dialogs - To create and select resources (Work Item and other related resources).

Following sections will explain in detail about each of the services defined above.

Discovery Mechanism

Clients that work with RTC or another implementation of the OSLC spec need a way to discover which functionality is offered by the implementation and where it is surfaced. Clients should not rely on specific URLs or perform path math on URLs. Instead, they should use the discovery chain offered by RTC. Here's an outline of the process to find the Change Management functionality:

The root document is exposed at https://://rootservices. In a typical RTC testbed, this is https://localhost:9443/jazz/rootservices
Fetch this document and extract the Change Management Catalog URL (pointed to by rdf:about) of the element oslc:ServiceProviderCatalog in
Fetch the document behind this URL. It contains a list of ServiceProvider elements that point to the documents which contain the actual service descriptions. In the case of RTC, there is one ServiceProvider element for each Project Area. Typically, an application would use the title of this element to allow the user to choose between the project areas.
Fetch the services document pointed to by property rdf:about of element oslc:ServiceProvider. This document contains references to services and operations like Creation Factories to create new work items, Query capabilities that allows to query work items, Delegated UI dialogs to create and select work items, and CLM Filters that are pre-defined queries on work items.

Sample of a work item service provider document is illustrated in Service Provider Document.

Resource Definition

A Work Item resource is defined by the OSLC Change Request properties and RTC Work Item properties. CM Resource Definitions table has OSLC defined properties for Change Request resource.

OSLC Defined Work Item Properties

RTC Defined Work Item properties

Custom attributes are exposed as: rtc_cm:[attributeId]
Contributed Link Types are exposed as: rtc_cm:[linkTypeId].[endPointId]

Resource Formats

Work Items provides representation of work item resource in all defined OSLC CM MUST resource types like RDF/XML, XML, and JSON representations. When requested for a work item in:

application/rdf+xml Work Item resource in RDF/XML representation is responded.
application/json Work Item resource in JSON representation is responded.
application/xml Work Item resource in OSLC-defined abbreviated XML representation is responded.
application/atom+xml Work Item resource in Atom Syndication Format XML representation is responded.

The usage of the OSLC CM 1.0 defined media types of application/x-oslc-cm-change-request+xml, application/x-oslc-cm-changerequest+xml, application/x-oslc-cm-change-request+json, application/x-oslc-cm-changerequest+json for work item resource is being deprecated for use in OSLC CM 2.0 based services.

Getting Representations

Work items are exposed under their Location URI. These URIs are typically obtained by a query or by using a reference from another work item. Two examples of Location URIs:

https://localhost:9443/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/262
https://localhost:9443/jazz/resource/itemOid/com.ibm.team.workitem.WorkItem/_Kk8YQFElEd6wrL4Qi7w25Q

There is an alternative URL format, called service alias format, which is mostly used for non-work item artifacts like enumeration literals, users etc. In contrast to the Location URI format, this format allows to address sub-resources like a link collection or the work item's comments. Using this format, the media type can be specified using an extension like .rdf or .xml or .json for easier testing in a browser during development time. Note that this way of specifying the media type is RTC proprietary and will work only on RTC Server. Some examples:

https://localhost:9443/jazz/oslc/workitems/821.rdf
https://localhost:9443/jazz/oslc/workitems/821.xml
https://localhost:9443/jazz/oslc/workitems/821.json
https://localhost:9443/jazz/oslc/workitems/_Kk8YQFElEd6wrL4Qi7w25Q.json
https://localhost:9443/jazz/oslc/workitems/821/rtc_cm:comments.atom

Multiple representations of a work item are available by specifying an Accept HTTP header or by specifying the required content type as an URL parameter _mediaType. These work for all URL exposed in a resource representation. Specifying an extension works only for the non-Location URI format. The first option is suitable for programmatic use, the second and third options are necessary when you have no control over the Accept header, e.g. in a browser or iFrame.

Content Type	Extension	Format
`application/rdf+xml`	.rdf	RDF Format as defined inOSLC Guidelines for RDF+XML representation.
`application/json` and `text/json`	.json	JSON Format as defined in OSLC Guidelines for JSON representation. The JSON formats can be requested with the additional URL parameter `?_pretty=true` which will format the JSON source for better legibility. Otherwise, unnecessary whitespace is omitted.
`application/xml` and `text/xml`	.xml	XML Format as defined in OSLC Guidelines for XML representation
`application/x-turtle` and `text/turtle`	n/a	Turtle Format as defined in OSLC Guidelines for Turtle representation
`application/x-jazz-compact-rendering`	n/a	The Compact Rendering discovery format used to get a link title/icon and the URLs pointing to the hover presentations
`text/html`	.hover.html	The HTML hover representations. Additional URL parameters are currently needed: `_selector=hover` for the full representation `_selector=smallHover` for the smaller representation `_context=web` for slightly different link handling geared towards the Web UI (e.g. mailto links for users)
`application/atom+xml`	.atom	ATOM Feed format. Useful only for collections of work items, but supported for single work items, too. OSLC Guidelines for ATOM representation.
`application/xhtml+xml`	.xhtml	XHTML intended for exploration/debugging -- do not rely on this format

Requesting a Subset of Properties (Partial Representations)

As supported in previous version, this version of work items service provider also allows a work item resource to be represented partially with only needed properties in the response format. As per OSLC CM 2.0 specifications, OSLC core URL parameters oslc_properties=prefixA:propA, prefixB:propB and oslc_prefixes=prefixA=nsUriA, prefixB=nsUriB should be used to get the partial representation of the resource with requested properties. For syntax help on above parameters refer to Selective Property Values.

Resource Operations

Work Item Service provider as an OSLC service, implements operations like creating, updating properties of, and deleting a work item resource using HTTP POST, PUT, DELETE methods. This section explains how to update properties of a work item. Work Item properties can be categorized as follows:

Simple property which has native values like literal, string, boolean, timestamp, integers as values.
Reference property, a property which is a reference to another resource and can occur only once. Attributes like dcterms:contributor(owner), oslc:Discussion(comments), etc are reference properties.
Collection property, a property which is a reference property and can occur more than once. All links such as oslc_cm:implementsRequirement, parent, children fall into this category.
Inline property is a contained composite/collection property, whose properties will be always part of the representation of the resource containing it. oslc:comment is an inline property of oslc:Discussion

Updating Work Items

To update a Work Item resource using OSLC CM 2.0 specifications, a client should first fetch the representation of that resource as mentioned in previous section Getting Representations. Update the representation and use HTTP PUT to send the new representation to the resource's URI Steps to update a work items are as follows:

Fetch the representation of that resource as mentioned in the section Getting Representations
Update the representation by adding, removing or changing values
Send the modified representation to the resource's URI using HTTP PUT

Two cases deserve special attention:
Avoid overwriting changes done by someone else: Because the update process involve first getting a work item, modifying it and then later putting back to the server there is a possibility of conflict. e.g. some other client may have updated the work item since the GET. In general, clients should not blindly overwrite the work item contents, but make sure that the changes are applied to the state that they fetched from the server. To mitigate this problem, clients should use the HTTP if-match header. This is done by including the ETag received on load in the If-Match header when PUTting the work item back to the server.
ETag information can be fetched from HTTP response headers that is written when a work item representation is requested using HTTP GET request.

HTTP/1.1 200 OK
ETag:  "_DrhL0KDHEeCbuLDfakk_jw"
Last Modified:  Mon, 27 Jun 2011 14:09:22 GMT
Cache-Control: max-age=0, must-revalidate
Expires:  Wed, 06 Jul 2011 07:52:15 GMT
Vary: Accept, Accept-Language
Content-Type:  application/rdf+xml;charset=UTF-8
Transfer-Encoding: chunked
Server:  Jetty(6.1.x)

If the HTTP if-match header is missing, Work Item service provider will return HTTP Bad Request (400) status code to indicate the header is required.
If the HTTP if-match header is present and it does not matches to the existing state (case where the work item was modified in the meantime), Work Item service provider behave as described in HTTP specification, returning an HTTP 412 Precondition Failed status.
If the HTTP if-match header is present and matches, the update will be executed and on success HTTP 200 OK status is returned

Updating a Subset of Properties (Partial Updates): PUT generally has the semantics of updating the entire resource (and removing what is not included). In order to allow partial updates via the more generally supported PUT, and in order to selectively remove entire attributes from a work item, you can specify the set of properties to update via the oslc.properties parameter. If the parameter oslc.properties. contains a valid work item property on the request that is not provided in the representation content, such property will be removed. If the parameter contains a invalid work item property, then HTTP 409 Conflict is returned. OSLC Core has defined guidelines OSLC Core Guidance: Partial Update on how to do partial update a resource using HTTP PATCH request which is yet to be implemented by Work Items. Work and plan related to this is captured in the work item 141545: Implement OSLC-CM v2 partial update using PATCH.

NOTE: Clients must preserve any unknown-property-values and any other content in the work item representation when doing the update with out using oslc.properties parameter. Because, these updates will completely modify/replace the existing representation of the work item with the received representation.
Let us see how we can update (modify/delete/replace) each of these properties with examples.

Java HTTP 라이브러리 (OSLC REST 프로그램시)

2011-12-30T17:54:00.001+09:00

Java

HttpURLConnection

Apache HTTP Client

v3 : http://hc.apache.org/httpclient-3.x/ (End of life)
v4 : http://hc.apache.org/httpcomponents-client/

참고 JFS SDK (https://jazz.net/wiki/bin/view/Main/ServerSDKOverview)

REST Framework: The JFS SDK provides a REST framework that can be used by applications to structure their code as a set of REST handlers (also called services). This framework is based on Apache's HTTP Component library. A key characteristic of this framework is that the REST handlers work with the HttpRequest and HttpResponse classes provided by the Apache's HTTP Component library, instead of the HttpServletRequest and HttpServletResponse classes provided by J2EE. This approach allows us to create a framework that is isolated from application servers-specific behavior (See the ServerSDKQnA for more details).

-
참고 bulk operations

HTTP pipelining(http://en.wikipedia.org/wiki/HTTP_pipelining)
IETF HTTP Batch proposals using MIME multi-part(http://tools.ietf.org/html/draft-snell-http-batch-01 and http://martin.atkins.me.uk/specs/batchhttp)
Microsoft ADO.Net batch requests(http://msdn.microsoft.com/en-us/library/cc668802(VS.100).aspx)
WebSockets.
JFS bulk operations service(https://jazz.net/wiki/bin/view/Main/JFSBulkOperations).