번역 : 이동국(fromm0 골뱅이 gmail.com)

<div class="note"> <b>Service</b> 란 단어의 개인적인 이해가 다를꺼 같아 해당 단어에 대해서는 그대로 사용하였습니다. </div>

http://www.onjava.com/pub/a/onjava/2005/01/26/soa-intro.html

soa1.gif An Introduction to Service-Oriented Architecture from a Java Developer Perspective
by Debu Panda
01/26/2005

회사내에서 이종의 기술과 애플리케이션은 실재의 일이다. 현 시점에 자원은 부족한 상황이다. IT는 현재의 애플리케이션을 던져버릴수가 없다. 그들은 현재의 투자를 계속적으로 추진해야만 한다. 당신에게 애플리케이션을 재사용가능하게 하고 이종의 기술과 애플리케이션사이의 상호운용을 약속하기 때문에 service지향 아키텍쳐(SOA)는 인기가 있다.

이 글에서 나는 자바개발자의 관점에서 SOA를 소개할것이고 service지향 애플리케이션을 빌드하기 위해서 자바공간에서 유용한 기술을 시험한다.

SOA는 무엇이냐.?#

service의 개념은 새로운것이 아니다. 하지만 SOA의 개념은 지난 2년간 발전되어 왔다. 이것은 당신이 재사용하는 컴포넌트 사이의 느슨한 커플링을 조장하는 소프트웨어 애플리케이션을 빌드하는 구조적인 스타일이다. 게다가 이것은 다음의 특성을 가지는 애플리케이션을 빌드하는 새로운 방법이다.

  • Service는 약정/인터페이스(contracts/interfaces)를 발행한 소프트웨어 컴포넌트이다. 약정은 플랫폼-, 언어-, 그리고 OS에 비종속적이다. XML과 간단한 객체접근프로토콜(Simple Object Access Protocol(SOAP))은 플랫폼에 비종속적인 표준이기 때문에 SOA의 기술을 가능하게 한다.
  • 소비자(Consumers)는 동적으로 services를 발견한다.
  • Services는 상호운용이 가능하다.

그림 1은 service기반 아키텍처의 개념도표를 보여준다.

soa2.jpg

SOA의 기본적인 빌드단위는 service이다. service는 자신을 포함하는 소프트웨어 모듈이다. 예를 들면 미리 계산된 작업(고객의 신용정보를 확인하는)을 수행하는 것이다. service는 특정한 기본적인 기술을 사용하는 개발자들을 요구하지 않는 소프트웨어 컴포넌트이다(역자 주. service는 특정 언어나 플랫폼을 사용하는 개발자를 요구하지 않는다. 즉 service는 특정 환경에 종속적이지 않다는 말이다.). 자바개발자처럼 우리는 재사용하는 코드에 포커스를 맞춘다. 게다가 우리는 객체의 로직이나 애플리케이션내의 컴포넌트를 탄탄하게 통합할려고 하는 경향이 있다. SOA는 애플리케이션을 조직화하게 한다. 왜냐하면 service는 다수의 소비자에 의해 재사용이 될수 있기 때문이다. 예를 들면 소비자의 신용카드를 청구하는 service를 생성하기 위해 우리는 그런 service의 단 하나의 인스턴스만을 빌드하고 배치한다. 그리고 우리는 몇몇의 애플리케이션으로 부터 이 service를 소비할수 있다.

SOA의 다른 장점은 당신에게 자동적으로 비지니스프로세스에 관한 관리(automate business-process management) 하도록 하는데 있다. 비지니스프로세스는 요구되는 기능을 달성하기 위해서 그런 서비스를 조정하고 소비한다. 게다가 새로운 비지니스프로세스는 현재 존재하는 service를 사용해서 생성될수 있다. 예를 들면 고객은 필수 service와함께 비동기적으로 상호작동할수 있는 비지니스프로세스에 의해 표현될수 있는 선적을 위한 제기되는 것을 요청한다.

왜 SOA인가.?#

오늘날의 IT조직은 변함없이 본질적으로 다른 시스템과 기술을 사용한다. 대부분의 분석가는 J2EE와 .NET이 대부분의 조직에서 공존을 계속할것이고 IT시장에서 계속되는 이기종의 기술은 흐름이라고 예견한다. 게다가 애플리케이션을 생성하는것은 역사적으로 다소 영향력이 수그러진 다른 기술들에게 영향을 미칠것이다. SOA는 표준화와 상호운용성이 있는 인터페이스를 통해서 그들의 기능을 끄집어 내기 위한 시스템을 허락함으로써 애플리케이션통합 이슈를 위한 분명한 해결책을 제공한다.

SOA를 사용하는것은 다양한 장점을 제공한다.

  • 기술을 변경하기 위해 애플리케이션을 개조
  • 다른 시스템과의 쉬운 통합 애플리케이션
  • 기존 시스템내에서 현재의 투자를 촉진한다.
  • 존재하는 services로부터 쉽고 빠르게 비지니스 프로세스를 생성할수 있다.

SOA와 Java#

대부분의 개발자는 종종 웹서비스와 SOA가 같은것이라고 생각을 한다. 많은 사람들은 웹서비스를 사용하지 않고는 service기반 애플리케이션을 빌드하는것이 가능하지 않다고 생각한다. 명백하게 하면 SOA는 디자인개념이다. 그런 이유로 웹서비스는 구현기술이다. 당신은 웹서비스를 사용하지 않고도(예를 들면 자바 RMI와 같은 전통적인 기술을 사용해서) service기반 애플리케이션을 빌드할수 있다.

SOA뒷편의 주요한 테마는 적합한 모듈방식을 찾고 모듈사이의 느슨한 커플링을 달성하는것이다(역자 주. SOA에서 모듈방식의 SOA의 가장 중요한 특징중에 하나이다. 그렇기 때문에 느슨한 커플링은 SOA에서 가장 필수적으로 이루어져야 하는 개념중에 하나라고 보인다.). 상호작동하는 컴포넌트사이에 너무 단단하게 커플링이 되어 있지 않은 모듈이(예를 들면 JSP표현레이어가 데이터모델에 너무 단단하게 통합되어 있지 않고 EJB등을 통해 그것에 접근하는 애플리케이션같은) 있는 곳에서 애플리케이션은 빌드할수 있다.

웹서비스의 인기가 오르기 전에 Jini가 SOA의 개념을 오랫동안 유지했던것을 언급하는것은 가치가 있다. 웹서비스는 HTTP, XML, SOAP, 그리고 UDDI처럼 플랫폼에 비 종속적인 표준이다. 게다가 J2EE그리고 .NET처럼 이종의 기술사이의 상호작용을 가능케 한다. 이 글에서 우리는 service기반의 애플리케이션을 빌드하기 위해서 가능한 기술의 관점에서 웹서비스에 촛점을 맞출것이다.

service기반의 애플리케이션을 위한 각각의 레이어#

어느 분산 애플리케이션처럼 service기반 애플리케이션은 다중계층(multi-tier) 애플리케이션이고 표현, 비지니스 로직 그리고 영속레이어를 가진다. 그림 2에서 service기반 애플리케이션의 전형적인 구조를 제공한다. SOA에서 가장 핵심이 되는 두가지 레이어는 service레이어와 비지니스프로세스 레이어이다.

sao3.jpg

service레이어#

우리가 먼저 논의를 했던것 처럼 service는 service기반 애플리케이션의 빌드단위(building blocks)이다. 게다가 service는 자바 객체와 EJB같은 컴포넌트와 다소 유사하다. 객체와 달리 어쨌든 service는 자기자신을 포함하고 자신의 상태를 유지하며 느슨하게 커플링된 인터페이스를 제공한다.

service기반 애플리케이션를 빌드하는것의 가장 큰 도전은 추상적인 상태로 인터페이스를 생성하는 것이다. 당신의 비지니스 요구사항을 분석하는 동안 어떤 소프트웨어 컴포넌트가 service처럼 빌드되길 원하는지에 대해서 주의깊게 생각해야 한다. 일반적으로 service는 조잡한 기능을 제공한다. 예를 들면 구매주문을 처리하는 소트프웨어 컴포넌트는 구매주문의 속성을 수정한 컴포넌트의 반대되는 것처럼 service처럼 배포되기 위해 좋은 후보중에 하나 이다.

당신은 service를 빌드할때 두가지 선택을 할수있다. 위에서 아래로 접근하는 방식(top-down approach)와 아래에서 위로 접근하는 방식(bottom-up approach)이다. 위에서 아래로 접근하는 방식은 당신이 당신의 service가 제공하는 메시지와 작동을 확인하고 기술한 후 service를 구현하는것을 요구한다. 이 방식은 당신이 새로운 service를 완벽하게 빌드할때 추천된다(역자 주. 기존의 시스템과 통합할 필요는 없지만 추후의 시스템에 통합이 시도될듯한 시스템에서 사용되는듯하다. 아래에서 위로 접근하는 방식에 비해 현재 존재하는 시스템과의 통합에 용이하지 않을수도 있는듯하다.). 이것은 당신에게 당신이 선호하는 구현기술을 선택하도록 한다. 이 방식은 또한 대부분의 상호작동가능한 service를 진행시킨다. 당신은 상호작동성을 방해하는 어떤 구현물(예를 들면 상호작동가능한 표현을 할수 없는 데이터 타입)을 피할수도 있다.

아래에서 위로 접근하는 방식은 비지니스 컴포넌트에서 당신이 현재 투자한 제품을 재사용할수 있도록 하기 때문에 배우 인기가 높다. 예를 들면 어떤 회사가 당신에게 service처럼 할인을 하기 위해서 권한을 제공하는 고객인지 아닌지 체크하기 위한 PL/SQL 저장 프로시저를 드러내도록 하게 하는 툴을 제공한다.

service의 가장 중요한 관점은 service서술(description)이다. SOA를 위한 구현기술처럼 웹서비스를 사용할때 웹서비스 서술 언어(Web Services Description Language-WSDL)는 메시지 타입, 웹서비스의 작동을 서술하고 이것이 따르도록 웹서비스 보증에 계약한다.

이것은 간단한 웹서비스를 위한 WSDL의 예제이다.

<?xml version="1.0" encoding="UTF-8"?> 
<definitions name="MyTimeService" 
  targetNamespace="urn:oracle-ws"
  xmlns:tns="urn:oracle-ws"
  xmlns="http://schemas.xmlsoap.org/wsdl/"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
<types/>
<message name="TimeService_getDateTime">
<part name="String_1" type="xsd:string"/></message>
<message name="TimeService_getDateTimeResponse">
<part name="result" type="xsd:string"/></message>
<portType name="TimeService">
<operation name="getDateTime" parameterOrder="String_1">
<input message="tns:TimeService_getDateTime"/>
<output message="tns:TimeService_getDateTimeResponse"/>
</operation>
</portType>
<binding name="TimeServiceBinding" type="tns:TimeService">
<operation name="getDateTime">

<input>
<soap:body
  encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
  use="encoded"
  namespace="urn:oracle-ws"/>
</input>

<output>
  <soap:body
    encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
    use="encoded"
    namespace="urn:oracle-ws"/>
</output>

<soap:operation soapAction=""/></operation>

<soap:binding
  transport="http://schemas.xmlsoap.org/soap/http" style="rpc"/>
</binding>

<service name="MyTimeService">

<port
  name="TimeServicePort"
  binding="tns:TimeServiceBinding">
  <soap:address location="REPLACE_WITH_ACTUAL_URL"/>
</port> 

</service> 

</definitions>

만약에 당신은 WSDL이 TimeService웹서비스의 완벽한 서술자(port와 작동및 기능, 그리고 메시지 타입에 대한)를 가지는지 주의깊에 봐라. WSDL에 기반하는 웹서비스는 이런 기능과 Oracle의 자바 기술이나 Microsoft .NET와 같은 다른 어떤 기술 을 사용해서 빌드하는지에 대한 메시지를 지원해야만 한다.

자바로 service레이어 빌드하기#

자바는 service기반 애플리케이션의 service레이어를 빌드하기 위해서 향상된 플랫폼을 제공한다. J2EE 1.4는 자바를 사용해서 웹서비스를 빌드하기 위해서 API를 표준화한다.

다음의 테이블은 웹서비스 애플리케이션을 빌드하기 위해 J2EE 1.4에 유효한 API들의 목록을 제공한다.

<table border="1"> <tr> <td>Java APIs</td> <td>Description</td> </tr> <tr> <td>JAXP</td> <td>Java API for XML Parsing</td> </tr> <tr> <td>JAXB</td> <td>Java API for XML Binding</td> </tr> <tr> <td>JAX-RPC (JSR 101)</td> <td>Java API for XML-Remote Procedure Call</td> </tr> <tr> <td>SAAJ</td> <td>SOAP API for Attachments in Java</td> </tr> <tr> <td>JAXR</td> <td>Java API for XML Registries</td> </tr> <tr> <td>JSR 109</td> <td>Web Services Deployment Model</td> </tr> <tr> <td>EJB 2.1</td> <td>Stateless Session EJB Endpoint Model</td> </tr> </table>

이런 기술에서 JAX-RPC는 J2EE를 가지고 웹서비스를 빌드하고 배치하기 위한 핵심 API처럼 생각되어 질수 있다. 이것은 XML타입과 자바 타입 그리고 XML SOAP메시지를 다루는 하위 레벨의 상세정보 사이의 맵핑의 복잡함을 개발자로부터 감춤으로써 웹서비스 애플리케이션를 빌드하기 위한 간단하고 튼튼한 플랫폼을 제공한다. JAX-RPC는 두가지 프로그래밍 모델을 제공함으로써 이론적틀로 불려지는 메소드를 소개한다. 자바 클래스와 비상태유지 EJB컴포넌트를 사용해서 웹서비스의 종점(endpoint)을 개발하기 위한 서버측 모델, 로컬 객체처럼 웹서비스에 접근하는 자바 클라이언트를 빌드하기 위한 클라이언트측 모델이 두가지다. JAX-RPC 1.1은 SOAP 1.1의 사용과 Mircosoft .NET과 같은 다른 기술과 함께 빌드된 다른 웹서비스와의 상호작동가능성을 위임한다. 많은 J2EE 1.4 애플리케이션 서버(Oracle의 OC4J 10.1.3, Sun One Application Server, 그리고 IBM WebSphere V6)은 JAX-RPC를 지원한다.

만약에 당신이 비지니스 로직을 수행하는 비상태유지 세션 EJB나 자바 클래스를 가지고 있다면 J2EE 1.4는 당신을 JAX-RPC내에서 표준적인 방법내에서 service처럼 그것을 드러내도록 한다. 만약에 당신이 J2EE를 사용해서 service를 빌드하고 있다면 당신은 표준적인 WSDL에 추가적으로 다양한 글들이 필요할것이다.

  • 맵핑파일, 자바와 WSDL의 맵핑 정보를 가지는 XML파일. 대부분의 경우에 이 파일은 좀더 복잡하거나 변경된 맵핑의 경우에만 요구된다.
  • 웹서비스 종점(endpoint)을 드러내기 위해 J2EE서버에 의해 사용되는 service종점(endpoint) 인터페이스. 이 인터페이스는 java.rmi.Remote인터페이스를 다음의 예제처럼 확장해야 한다.

package time; 
import java.rmi.RemoteException; 
import java.rmi.Remote; 
 public interface TimeService extends Remote 
 
 public String getDateTime (String namethrows 
 RemoteException; 
}

  • 종점(endpoint) 인터페이스, WSDL의 위치나 자바에서 WSDL로의 맵핑등을 서술하는 웹서비스 배치 서술자(webservices.xml등)
  • 오라클 애플리케이션 서버를 위한 oracle-webservice.xml같은 업체의 특성적인 배치 서술자

우리는 이후 글에서 SOA애플리케이션의 service계층을 빌드하는것에 대해서 얘기할것이다.

첫번째 일면에서 보면 service를 위한 그런 요구사항은 의욕을 상실하게 할것처럼 보인다. 어쨋든 대부분의 SOA업체는 선호하는 디자인 툴을 제공함으로써 개발자의 작업량을 쉽게 한다. 예를 들면 오라클은 오라클 JDeveloper 10g개발툴에서 웹서비스 디자인 기능을 제공하고 IBM의 웹스피어 WSAD툴은 SOA개발을 간단하게 한다.

마침내 먼저 말했던것처럼, 상호운용성은 service기반 애플리케이션의 중요관점의 하나이다. 만약에 당신이 재사용가능한 service를 원한다면 다른 J2EE플랫폼뿐 아니라 .NET같은 이기종의 플랫폼과 함께 상호운용가능하게 만들어야 한다. 당신은 당신의 서비스가 UDDI와 같은 service디렉토리안에 배치되거나 등록되길 요구하고 그것을 찾고 사용하는 고객이 있다는것을 예견할수 없다. 당신이 당신의 service를 빌드할때 그것을 WS-I Basic Profile에 적합하도록 만들어라. WS-I는 플랫폼, OS와 개발 언어를 통해 웹서비스의 상호운용성에 포커스를 두는 오라클, IBM, MS, sun과 같은 SOA플랫폼 업체의 오픈된 업체협회이다. J2EE 1.4는 WS-I기본 프로파일에 적합하도록 요구한다. 그리고 당신의 애플리케이션 서버는 상호운용가능한 service를 생성해야만 한다.

비지니스프로세스 계층#

다른 SOA의 약속은 당신이 존재하는 service로부터 새로운 애플리케이션을 빌드할수 있다는 것이다. SOA가 가져오는 가장 중요한 이익은 service통합처럼 종종 참조되는 비지니스프로세스 모델링의 표준화이다. 당신은 기존 시스템을 넘어서 추상화의 웹서비스 기반계층을 빌드할수 있고 그 결과로써 비지니스프로세스를 모으기 위해서 그것들에게 영향을 끼친다. 추가적으로 SOA플랫폼 업체는 디자인하기 위해서 툴과 서버를 제공하고 있고 그 비지니스 처리를 수행한다. 이 영향은 Business Process Execution Language (BPEL)라는 이름의 OASIS표준의 의해 표준화되고 있다. 대부분의 플랫폼 업체들은 이 표준에 충실하고 있다. BPEL은 기본적으로 프로그래밍 언어이지만 XML내에서 표현된다.

이것은 BPEL정의 프로세스의 개략이다.

<process>

 <!– Definition and roles of process participants -->
 <partnerLinks> ... </partnerLinks> 

 <!- Data/state used within the process --> 
 <variables> ... </variables> 

 <!- Properties that enable conversations -->
 <correlationSets> ... </correlationSets>
 
 <!- Exception handling -->
 <faultHandlers> ... </faultHandlers>

 <!- Error recovery – undoing actions --> 
 <compensationHandlers> ... </compensationHandlers> 

 <!- Concurrent events with process itself -->
 <eventHandlers> ... </eventHandlers> 

 </process>  

BPEL은 다음을 제공한다.

  • 프로세스 상호작동하는 service를 위한 partnerlinks
  • 조작되는 데이터를 위한 변수
  • 비동기적인 호출사이의 관련 메시지를 위한 상관성
  • 문제의 메시지 정의를 위한 결점
  • 문제의 경우에 수행되는 배상 핸들러
  • 특별한 형태내에서 예견되는 이벤트와 함께 분배를 처리하도록 하는 이벤트 핸들러

BPEL문법이 수월하지 않음에도 불구하고 비지니스프로세스의 그래픽적인 표현은 선호된다. 그래서 당신은 존재하는 service로 부터 비지니스프로레스를 모으기 위한 GUI디자인 툴로부터 쉽게 작업을 수행할수 있다. 게다가 비지니스프로세스를 생성하는것은 만약에 당신이 당신의 비지니스 프로세스를 이해하고 당신의 필요로 인해 필요한 service를 배치한다면 비교적 간단한 작업이다. Oracle BPEL Designer는 eclipse또는 JDeveloper플러그인처럼 사용될수 있고 당신이 비지니스프로세스를 디자인하는데 도움을 준다. service를 디자인하고 개발하는것을 좀더 쉽게 한다.

추가적으로 당신은 생성된 비지니스 프로세스를 실행하기 위해 높은 성능의 처리환경(또는 서버)과 테스트하고 배치된 프로세스를 상태를 모니터링하기 위한 관리툴이 필요하다. 오라클과 IBM과 같은 대부분의 SOA플랫폼 업체는 지금 비지니스프로세스를 배치하기 위한 견고한 플랫폼을 가지고 있다. 예를 들면 오라클은 비지니스프로레스를 배치하고 수행하는 Oracle BPEL Process Manager와 비지니스프로세스를 테스트하고 모니터링하는 오라클 BPEL콘솔을 제공한다.

표현 계층: 데이터 바인딩 문제#

표현계층은 유저관점에서 보면 가장 중요하다. 이 계층은 JSP, JSF, portlets또는 개별적인 자바 클라이언트와 같은 기술들로 빌드된다. 개발자를 위해 표현레이어와 비지니스로직 그리고 service레이어 사이의 느슨한 커플링을 수행하기 위해 고생스럽다. 오랜 기간동안 사용되고 있는 많은 MVC프레임워크는 view또는 표현 레이어 그리고 데이터나 비지니스로직을 제공하는 model 사이의 느슨한 커플링을 허락한다. 이것은 최소한이 효과로 view나 model을 변경하게 한다. 이것은 표현레이어와 service레이어 사이에 우리가 원하는 느슨한 커플링의 타입을 달성하도록 도와준다. 어쨌든 중요한 문제는 다양한 종류의 클라이언트(JSP, 자바 클라이언트 그리고 EJB또는 웹서비스와 같은 service)사이에 데이터를 바인딩하는데 표준적인 방법이 없다는 것이다. 그리고 클라이언트는 service레이어의 구현을 정확하게 참조하는 방법을 알아야만 한다. 예를 들면 service는 service를 부트스트랩하거나 데이터를 전송하기 위한 웹서비스또는 EJB를 사용해서 빌드한다. 그리고 SOA의 목적을 부순다. JSR-227 는 XML기반 메타데이터 정의의 세트를 통해 데이터바인딩 service를 정의함으로써 J2EE애플리케이션을 위한 service의 데이터바인딩을 표준화하기 위해 생성되었다.

JSR-227은 개발자에게 웹서비스, 비상태유지 EJB또는 표준적인 자바 클래스가 될수 있는 비지니스 service를 사용함으로써 데이터컨트롤을 생성하게 한다. 데이터 컨트롤은 수집(collections-XML메타데이터를 사용하는 service를 제공하는 속성과 기능)을 서술한다. 데이터 컨트롤은 나중에 선언된 바인딩을 통해 UI컴포넌트에 의해 사용될수 있고 service레이어를 통해 표현 레이어를 완벽하게 디커플링한다.

Best Practices#

여기에 service기반의 애플리케이션을 빌드할때 가장 좋은 연습에 대한 글이 있다.

1. 허위때문에 구현기술로 뛰어들지 마라. 당신의 조직을 위한 웹서비스가 어떤 특성을 만들지에 대해서 주의깊게 고려하라. RMI와 같은 전통적인 기술을 사용해서 service기반의 애플리케이션을 빌드하는것은 웹서비스를 사용하는것보다 당신의 경우에 더 효과적일수도 있다.(역자 주 : 굳이 최신기술이 당신의 환경에 적합한것이 아니라 경우에 따라 기존의 기술이 더 효과적일수도 있다는 말이다.)

2. service의 모듈방식은 매우 중요하다. 거친(fine-grained ) service를 빌드하지 말라. 이것은 강력한 커플링과 부서지기 쉬운 구조를 만들수도 있다.

3. 대부분의 애플리케이션을 위해서 상호운용성은 매우 중요하다. WS-I에 충실하라. 당신이 선호하는 클라이언트와 함께 상호운용성을 위한 테스트를 필히 수행하라.

4. 만약에 당신의 애플리케이션을 위하 웹서비스를 사용하는데 적합하지 않다면 여기에 대안이 있다. 많은 BPEL프로세스관리자(예를 들면 오라클 BPEL프로세스 관리자)는 당신에게 기초적인 프로토콜을 사용하게 한다.

결말#

이 글에서 나는 SOA에 대한 소개를 했고 자바를 사용해서 처음으로 service기반의 애플리케이션을 개발할때 당신을 도와줄수 있는 가이드라인을 제공했다. 당신은 당신의 투자를 추후에 입증할수 있는 좋은 연습구문을 사용해서 service기반의 애플리케이션을 빌드할수 있다.

관련 리소스#

* "Service-Oriented Architecture: Beyond Web Services" by Ted Farrell
* "Service-Oriented Architecture: Parts 1 and 2" by Samudra Gupta
* "What is Service-Oriented Architecture?" by Hao He
* "Opening the Black Box of Integration" by Mike Lehmann

Debu Panda is a principal product manager of the Oracle Application Server development team.

Add new attachment

Only authorized users are allowed to upload new attachments.

List of attachments

Kind Attachment Name Size Version Date Modified Author Change note
jpg
sao3.jpg 36.7 kB 1 06-Apr-2006 09:45 218.235.119.117
gif
soa1.gif 3.4 kB 1 06-Apr-2006 09:45 218.235.119.117
jpg
soa2.jpg 16.6 kB 1 06-Apr-2006 09:45 218.235.119.117
« This page (revision-1) was last changed on 06-Apr-2006 09:45 by UnknownAuthor