Java 및 .NET 기술을 사용하여 Ajax를 통한 상호운용성 실현

Marina Fisher, Gerald Beuchelt, 썬 마이크로시스템즈, 2007년 8월

기사 인덱스

Web 2.0은 O'Reilly Media에서 정의한 용어로, 인터넷의 현재와 예측할 수 있는 다음 세대를 기술하는 데 사용됩니다. 이제 웹은 단순히 단일 애플리케이션을 위한 전달 메카니즘이었던 것과는 대조적으로, 애플리케이션이 구축될 플랫폼으로서 진화하고 있습니다. Web 2.0 애플리케이션의 예로는 사용자가 기여하는 컨텐츠의 경우 MySpace 및 Wikipedia를, 다른 애플리케이션이 구축될 수 있는 플랫폼의 경우에는 Google Maps 및 Calendars를 들 수 있습니다. 이러한 것들과 함께 새로운 개발 패러다임인 Ajax가 있습니다. 이것은 Web 2.0 애플리케이션을 수행하는 데 더 향상된 사용자 경험을 제공할 것입니다.

Ajax의 배경 이론은 간단합니다. 과거에 웹 사이트 또는 애플리케이션을 사용할 때는 페이지를 표시하기 위해 서버로부터 요청을 생성하고 응답을 기다려야 계속할 수 있었습니다. 대부분의 경우, 이 방식은 페이지의 작은 부분만 업데이트될 때 매우 비효율적일 수 있습니다. 그러한 부분이 비동기적으로 업데이트된다면, 사용자는 전체 페이지 리프레시를 기다리며 아무 일 없이 앉아있지 않아도 되며 비동기적으로 다운로드한 새로운 조각을 기다리는 동안 그들이 가지고 있는 정보에 대해 작업을 할 수도 있는 것입니다. Ajax에서는 XMLHTTPRequest 객체라고 하는 브라우저 객체를 통해 이것을 실현합니다. 이 객체는 백엔드 서비스로 요청을 하도록 JavaScript로 제어할 수 있으며 그러한 서비스로부터의 응답을 처리하는 callback 함수를 설정할 수 있습니다. 그 후 JavaScript 코드는 브라우저의 DOM(Document Object Model)을 사용하여 페이지에서 업데이트된 부분을 정확히 제 위치에 씀으로써 비동기적인 업데이트를 제공합니다. 이것의 훌륭한 예는 Google Maps로, XMLHttpRequest를 사용하여 사용자가 현재 보고 있는 지도 영역에 이웃한 부분을 다운로드합니다. 사용자가 지도에서 마우스를 드래그할 때, 새 영역들이 이미 캐시되어 있었으므로 왕복 지연(round trip delay) 없이 즉시 표시되며, 이것이 바로 Google Maps가 웹에서 '킬러 애플리케이션'의 지위에 오르게 한 특징입니다.

그림 1에서는 Ajax 기술이 브라우저와 웹 서버 사이에서 상호작용하는 방법을 고도의 아키텍처 뷰를 통해 보여줍니다.

 

클라이언트 쪽에서 Ajax 애플리케이션은 XMLHttpRequest에 의존하여 원격의 백엔드 서비스를 호출하며 매시업(mashup)이라고 하는 것을 생성합니다. 백엔드 서비스는 웹 서비스를 포함하여 아마 복잡한 값들을 리턴할 것입니다. 즉, SOAP로 암호화된 결과를 리턴하거나 HTML 마크업으로부터 text-over-http, Excel 스프레드시트와 같은 문서 형식인 CSV 등의 형태로 뭔가를 반환할 수 있는 웹 애플리케이션을 리턴할 것입니다. 그 후 클라이언트에서는 JavaScript를 사용하여 컨텐츠를 통합 정리하고 일반 사용자에게 매시업을 제공합니다.

JavaScript 프로그래머가 단순한 스크립트 언어로서의 JavaScript로 별다른 준비 없이 매시업을 생성하면서 다양한 형식의 파싱을 처리해야 할 때 문제가 발생합니다.

이러한 문제와 JavaScript로 개발할 때의 고유한 복잡성을 고려하여, 툴 업체들은 서버 측 패러다임을 Ajax 애플리케이션 구축에 사용하도록 하는 툴킷을 내놓고 있습니다. 이론은 간단합니다. JSP 또는 ASP.NET과 같은 기술이 이를 위해 수년 간 사용되어 왔으며, 이 때 애플리케이션 개발자들은 나중에 클라이언트로 전달되어 수행될 HTML과 JavaScript 마크업을 '생성'하는 서버 애플리케이션을 구축합니다. 이 기법은 Ajax 애플리케이션 개발에도 아주 적합합니다. 또한 Dojo, Google Web Toolkit과 같은 수많은 오픈 소스 툴킷이 존재하며 그들 중 Yahoo Ajax Library는 Ajax 애플리케이션 구축을 지원하기도 합니다. 그러나 상호운용성의 문제를 유발할 수 있으므로 이러한 방식에도 주의가 필요합니다. 매시업 애플리케이션이 다른 기술 스택상에서 수행되는 웹 서비스를 사용해야 하는 경우를 고려해봅시다. 이 부분에서 상호운용성 이슈들이 발생합니다. 이 기사의 나머지 부분에서 일부 이슈에 대해 살펴보겠습니다.

"Java EE .NET Interoperability: Integration Strategy, Patterns, and Best Practices"에 따르면, 프리젠테이션, 비즈니스, 통합 및 리소스 계층 전반에 걸쳐 Java와 .NET의 상호운용성 제한조건들이 발생했다고 합니다. Web 2.0으로 인해 이것이 한층 더 복잡해집니다. 특히 매시업 시나리오에 있어서 브라우저와 서비스 계층 간에 상호운용성 문제가 발생할 수 있습니다. 초기 웹 애플리케이션의 경우, 브라우저는 단일한 프리젠테이션 계층으로 밀접하게 결합되어 있었고, 그 컨텐츠는 이 계층에 의해 지시되었습니다. 매시업의 경우, 브라우저는 더 이상 단일 서버에 밀접하게 결합되어 있지 않으며, 모든 정보를 하나의 사용할 수 있는 애플리케이션으로 조합하기 위해 서드 파티를 포함하여 수많은 다양한 것들로부터 컨텐츠를 받을 수 있습니다. 게다가, 각 서버들이 관리해야 하는 수많은 다양한 브러우저 기술 플랫폼이 존재하여, 고유의 복잡성을 가진 '다 대 다' 관계를 형성합니다. 사용자의 애플리케이션이 인터넷에서 광범위하게 사용 가능하게 되고 여러 브라우저를 통해 액세스될 것이기 때문에, 바로 이러한 때에 다양한 브라우저하에서 Web 2.0 애플리케이션의 기능 테스트는 필수입니다.

먼저 웹 서비스를 사용하기 위해 ASP.NET이 어떻게 Ajax를 사용하는지 살펴봅시다.

ASP.NET Ajax의 일부로 Microsoft는 웹 서비스를 위한 HTTP 핸들러를 확장하여, 사용자가 ASP.NET Ajax 가능 플랫폼에서 수행되며 '/js'로 끝나는 웹 서비스를 호출하는 경우 ASP.NET Ajax는 이 웹 서비스 호출 시 사용될 수 있는 JavaScript 프록시를 자동 생성하도록 했습니다. 이것이 작동하도록 하려면 사용자는 서비스에 ScriptService() 속성을 추가해야 합니다. 이 방식을 사용하면 Ajax에서 웹 서비스를 호출하는 경우와 관련한 복잡함이 줄어듭니다. 그림 2가 이에 대한 예제입니다.

 

다음은 [ScriptService()]가 가능한 웹 서비스에 /js를 붙여서 자동 생성된 JS 코드 샘플입니다.

var WebService=function() {
this._timeout = 0;
this._userContext = null;
this._succeeded = null;
this._failed = null;
}
WebService.prototype={
HelloWorld:Sys.Net._WebMethod._createProxyMethod(this,"HelloWorld", "WebService.HelloWorld",false),_get_path: function() { return WebService.get_path(); },
    set_timeout: function(value) { this._timeout = value; },
    get_timeout: function() { return this._timeout; },
    set_defaultUserContext: function(value) { this._userContext = value; },
    get_defaultUserContext: function() { return this._userContext; },
    set_defaultSucceededCallback: function(value) { this._succeeded = value; },
    get_defaultSucceededCallback: function() { return this._succeeded; },
    set_defaultFailedCallback: function(value) { this._failed = value; },
    get_defaultFailedCallback: function() { return this._failed; }
}
WebService._staticInstance = new WebService();
WebService.set_path = function(value) { WebService._staticInstance._path = value; }
WebService.get_path = function() { return WebService._staticInstance._path; }
WebService.set_timeout = function(value) { WebService._staticInstance._timeout = value; }
WebService.get_timeout = function() { return WebService._staticInstance._timeout; }
WebService.set_defaultUserContext = function(value) { WebService._staticInstance._userContext = value; }
WebService.get_defaultUserContext = function() { return WebService._staticInstance._userContext; }
WebService.set_defaultSucceededCallback = function(value) { WebService._staticInstance._succeeded = value; }
WebService.get_defaultSucceededCallback = function() { return WebService._staticInstance._succeeded; }
WebService.set_defaultFailedCallback = function(value) { WebService._staticInstance._failed = value; }
WebService.get_defaultFailedCallback = function() { return WebService._staticInstance._failed; }
WebService.set_path("/AjaxEnabledWebSite2/WebService.asmx");
WebService.HelloWorld= function(onSuccess,onFailed,userContext) {WebService._staticInstance.HelloWorld(onSuccess,onFailed,userContext); }

이제 이 웹 서비스에 액세스하기 위해 개발자들이 해야할 일은 이 URI에 대한 JavaScript 레퍼런스를 생성하고 브라우저 캐시에 Microsoft ASP.NET Ajax JavaScript 라이브러리를 소유하는 일 뿐입니다. 그러한 방법 즉, 웹 서비스로 언급하는 방법은 프록시를 통해 쉽게 수행됩니다. Microsoft는 한 단계 더 나아가, ServiceReference 개념을 서버 측 코드에 추가함으로써 이것이 더 간단해지도록 했습니다. 이 서버 측 코드는 수행될 때 모든 필요한 JavaScript를 생성합니다.

ASP.NET에서 서버 레퍼런스는 다음과 같습니다.

<Services>
    <atlas:ServiceReference Path="MyWebService.asmx" />
</Services>

기본적으로, 이것은 ASP.NET에 의해 JavaScript 블럭으로 파싱되며, 이 JavaScript 블럭에서 서비스의 URI를 호출하고 '/js'를 뒤에 붙여서 JavaScript 프록시를 돌려받도록 하며 그 프록시를 캐시에 로드하여 사용자의 나머지 코드가 그것을 액세스할 수 있도록 합니다.

그러나 원격 서비스가 Microsoft 스택상에서 작성되지 않았거나 스택은 Microsoft이지만 ASP.NET Ajax가 가능하지 않다면 어떤 일이 생길까? URI에 '/js'를 붙이게 되면 HTTP 400(잘못된 요청) 오류가 발생할 것입니다. 별도 설치 과정이 필요 없는 상호운용성은 당연히 실현할 수 없습니다. 예방책을 찾는다면, Microsoft WCF(Windows Communication Foundation) "Indigo"를 살펴볼 수 있습니다. WCF 프레임워크는 API를 제공하여 ReST(Representational State Transfer) 및 POX(Plain Old XML)를 지원하며, 이 둘 모두 Java 쪽에서 지원됩니다. SOAP 또한 널리 사용되는 상호운용성 표준 중 하나로 남습니다. 이들 두 옵션은 매시업 개발자들에게 유연성을 제공합니다. 다음의 다이아그램은 가능한 통합을 간략하게 보여줍니다.

그림 3.Ajax 및 Web Service 구성요소 간의 상호작용
 

전통적인 SOAP 기반의 상호운용성

 Java 측에서 간단한 Ajax 애플리케이션으로 시작하는 경우, jMaki Ajax 플러그인이 있는 NetBeans 오픈 소스 IDE를 사용한 후, Dojo Fish Eye 같은 비주얼 컴포넌트를 index.jsp 페이지에 드래그 앤 드롭하고 대화형 custom-built Hello World 위젯을 추가할 것입니다. Hello World는 다른 jMaki 컴포넌트와 마찬가지로 세 가지 요소로 구성됩니다 - HTML, CSS 및 JavaScript. 이 위젯은 XMLHttpRequest 객체를 통해 서버로 개별 문자를 비동기적으로 전달함으로써 텍스트 필드에 사용자가 입력한 내용을 동적으로 표시합니다. 다음 코드에서는 사용자 입력을 처리하는 JavaScript 로직을 보여줍니다.

var wid = widget.uuid;
    var service = widget.service;

    function getXmlHttpReq(url) {
        if (window.XMLHttpRequest) {
            return new XMLHttpRequest();
        } else if (window.ActiveXObject) {
            return new ActiveXObject("Microsoft.XMLHTTP");
        }
    }
    this.submitData = function() {
        var target = document.getElementById(uuid + "_hello");
        var req = getXmlHttpReq(service);
        req.onreadystatechange = function() {
            if (req.readyState == 4) {
                if (req.status == 200) {
                    target.innerHTML = req.responseText;
                }
            }
        };
        req.open("POST", service, true);
        var name= document.getElementById(uuid + "_name");
        req.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
        req.send("name=" + name.value + "&uuid=" + wid);
    }
   
}
var jshello = new HelloWorld();
jmaki.attributes.put(widget.uuid, jshello);

 우리는 이미 XMLHttpRequest 객체 생성, open() 및 send() 메소드, 그리고 onreadystatechange 설정을 검토했으며, 이들은 응답을 처리하는 callback 함수를 정의합니다. readyState == 4 는 요청이 로드되었음을 나타냅니다. request status == 200은 HTTP 상태가 "OK"임을 표시합니다. 즉, 비동기식 요청이 리턴되었으며 응답은 req.responesText()를 통해 얻습니다. index.jsp 페이지 또한 아래와 같이 매우 간단합니다.

그림 4. Index.jsp 페이지
 

위젯에 액세스하는 방법은 다음과 같습니다.

<a:ajax name="helloworld" service="helloService.jsp" />

 

jMaki 애플리케이션을 구축 및 수행하는 경우 오픈 소스 GlassFish 애플리케이션 서버 하에서는 애플리케이션을 자동으로 컴파일하고 전개합니다. 애플리케이션 서버와 함께 단일 배포(distribution) 형식으로 NetBeans IDE를 다운로드할 수 있습니다.

 

그림 5.HelloWorld Ajax 애플리케이션
 

다음으로 우리 애플리케이션을 변경하여 그것을 .NET 웹 서비스와 통합해 봅시다. 다음에 사용자에게 환영 메시지를 리턴하는 Hello .NET 서비스가 있습니다.

그림 6. ASP.NET HelloService
 

이 웹 서비스는 IIS 하에서 전개될 준비가 된 상태이며 호출하면 다음을 볼 수 있습니다.

그림 7. IIS 하에 전개된 .NET WS
 

다음으로, 아래와 같이 .NET Web Service WSDL을 NetBeans IDE로 임포트하여 해당 결과를 자동 생성하도록 합니다.

그림 8. ASP.NET Web Services WSDL
 

Java 기반 Ajax 애플리케이션의 helloService.jsp를 .NET 서비스로 업데이트해 봅시다. 다음은 helloService.jsp 목록입니다.

<ol>
<%@page import="org.tempuri.*" %>    
<%
    String name= request.getParameter("name");
    
    // Access the .NET Web Service
    NetService1Soap service = new NetService1().getNetService1Soap();
    String res = service.helloService(name);
    out.println();
    out.println(res);
%>
</ol>

 애플리케이션을 재구축하고 실행하면 다음과 같은 결과가 생성됩니다.

 그림 9. .Net Web Service에 액세스하는 Java Ajax 클라이언트
 

여기에서 설명한 것은 SOAP를 기반 통신 프로토콜로 사용하여 .NET 서비스와 jMaki Ajax 애플리케이션 사이에 상호 운용하는 방법입니다. Web 2.0 사용자가 늘어남과 동시에, Yahoo, Flickr 및 많은 다른 업체에서 제공하는 ReSTful 웹 서비스가 상당히 인기가 있습니다. ReST 스타일의 웹 서비스는 HTTP 프로토콜의 URI-addressable semantics를 통해 액세스되며, 클라이언트 측의 통합 작업을 상당히 단순화해 줍니다. 결론적으로, .NET과 Java 스택 사이의 Web 2.0 서비스 상호운용성은 점차적으로 ReST쪽으로 이동하고 있습니다.

RWCF와의 ReST/POX 상호운용성

전에 "Indigo"로 알려졌던 WCF(Windows Communication Foundation)는 .NET Framework 3.0의 통신 스택입니다. 특히 WS-Security, WS-ReliableMessaging, MTOM 및 WS-Policy와 같은 다수의 WS-* 프로토콜이 이제 주요 웹 서비스 스택의 일부가 되었습니다. 이전에 개발자들은 Microsoft의 제한된 지원만을 받을 수 있었으며 실제로 얼리 어답터를 대상으로 했었던 WSE(Web Services Enhancement) 패키지에 의지해야 했습니다. 또한, 많은 WS-* 스펙이 최근 생겨난 특성이므로, SOAP 스택을 구현한 WSE와 기타 WS-* 간의 상호운용성은 불완전했습니다.

WCF가 이 상황을 변화시켜서, 생각해 두었던 WS-* 지원을 다시 설계하고 썬의 WSIT(Web Services Interoperability Technologies)와 다른 회사의 SOAP 스택을 상대로 테스트도 하고 있습니다. WS-* 프로토콜 중 어느 것을 가능하게 하는 작업은 대개 어렵지 않으며 가끔 몇 라인의 코드 또는 전개 시 .config 파일의 몇 가지 설정이면 됩니다.

또 다른 눈에 띄는 개선점은 WCF 웹 서버를 위한 ReST(POX - "Plain Old XML"라고도 함) 작업 모드입니다. 구현 시점에서, POX 서비스는 전통적인 웹 서비스를 위한 API와 인프라를 사용하지만 유선상으로 송신되기 전에 메시지에서 SOAP envelope 및 헤더를 떼어냅니다. 이것은 MessageVersion을 None으로 설정함으로써 이뤄집니다. 이는 구성 파일에 커스텀 바인딩을 생성하여 수행합니다.

애플리케이션을 재구축하고 실행하면 다음과 같은 결과가 생성됩니다.

<system.serviceModel>
    <services>
      <service name="MyService">
        <endpoint 
          address="service" 
          contract="IMyService" 
          binding="customBinding" 
          bindingConfiguration="poxBinding" />
      </service>
    </services>
    <bindings>
      <customBinding>
        <binding name="poxBinding">
          <textMessageEncoding 
            messageVersion="None" />
          <httpTransport 
            manualAddressing="true" />
        </binding>
     < /customBinding>
    </bindings>
  </system.serviceModel>

주목해야 할 몇 가지 세부사항이 있습니다. ServiceContract() 속성을 통해 웹 서비스용 인터페이스를 정의하고 꾸미는 것, 즉 SOA의 contract 주도형 개발(contract-driven development) 주의에 따르는 것은 WCF의 좋은 스타일이라 할 수 있습니다. POX 서비스의 경우 POX 서비스의 서명 함수(signature)는 다음과 같아야 합니다.

Message thisIsAPoxMethod(Message request)

들어오는 Message는 들어오는 ReST 요청의 환경(context)을 결정하는 데 사용될 수 있습니다. 예를 들어, HTTP GET에 대한 URI 요청은 Message.Properties.Via 속성 값을 평가하여 얻을 수 있습니다.

다음은 실제 .NET ReST/POX 웹 서비스 Service.cs로, jMaki Ajax 프레임워크로 구현된 Ajax 애플리케이션에서 호출할 것입니다. 이 서비스는 시간을 반환합니다.

using System;
using System.ServiceModel;
using System.Runtime.Serialization;

using System.Runtime.Serialization;
using System.ServiceModel.Channels;
using System.Net;
[ServiceContract()]
public interface IMyService
{
    // Add action and ReplyAction
    [OperationContract(Action = "*", ReplyAction = "*")]
    Message MyOperation1(Message request);
}

// Add ServiceBehaviour
[ServiceBehavior(AddressFilterMode = AddressFilterMode.Prefix)]
public class MyService : IMyService
{
    // Rewrite the method to take and return Message
    public Message MyOperation1(Message request)
    {
        return Message.CreateMessage(MessageVersion.None, 
                                     String.Empty, 
                                     (object)DateTime.Now.ToString("T"));
    }
}

서비스를 호출한 결과는 다음과 같습니다.

그림 10. WCF ReST 스타일 웹 서비스 호출
 

이제 NetBeans IDE를 열고 앞에서 구현된 .NET ReST 스타일의 서비스에 액세스하는 Ajax 애플리케이션을 jMaki Ajax 프레임워크를 사용하여 구현합니다. 크로스 도메인 .NET 웹 서비스에 액세스하려면, 서비스 URL을 XMLHttpRequest의 property 파일인 xhp.json에 지정해야 합니다. 이 파일은 웹 프로젝트의 resources 폴더 아래에 있습니다.

{"id": "localtime", 
         "url":"http://localhost:1651/WCF_POX_Service/Service.svc/service",
         "apikey" : "appid=jmaki-key"
        }

이제 기본 웹 페이지인 index.jsp에서, Flickr 이미지나 시계 같은 매시업 페이지에 필요한 비주얼 컴포넌트를 추가합니다. 이 시계는 다음과 같은 방식으로 원격 .NET 서비스에서 시간을 가져오도록 구성될 것입니다.

 jmaki.doAjax({url: 'http://localhost:8081/AjaxEx/xhp?key=localtime', callback: function(req) { var _req=req; postProcess(_req);}});

 다음은 NetBeans 플러그인으로 사용할 수 있는 jMaki Ajax 프레임워크를 사용한 애플리케이션 코드의 일부입니다.

그림 11. jMaki NetBeans 플러그인을 사용한 Ajax 애플리케이션
 

다음은 매시업 애플리케이션의 샘플을 수행한 결과입니다.

그림 12. .NET ReST 스타일 WS를 사용한 Ajax 상호운용성 샘플
 

이 Ajax 샘플은 ASP.NET Ajax ReST/POX 스타일 서비스를 포함한 다른 리소스로부터 컨텐츠를 가져옴으로써 상호운용성을 달성하는 것을 볼 수 있습니다.

ASP.NET Ajax에 대한 추가 정보

ASP.NET Ajax는 2007년 초에 릴리스되었습니다. 초기 릴리스에는 스크립트 매니저 및 업데이트 패널(업데이트할 수 있는 컨텐츠의 영역을 정의)과 같은 몇 가지 중요한 기능이 포함되어 있습니다. Microsoft의 개발자 커뮤니티 사이트에서 매우 다양한 위젯들을 구할 수 있습니다. 이러한 위젯의 통합은 아직 NetBeans에서의 jMaki/Dojo 통합에서처럼 완전하지는 않지만 관심있는 개발자들은 코드에 접근하여 솔루션 개발을 시작할 수 있습니다. 주요 ASP.NET Ajax 런타임과 위젯 둘 다에 대한 소스 코드를 사용할 수 있습니다. Microsoft는 적절한 Visual Studio 통합을 약속했으며 IDE의 'Orcas' 릴리스를 준비하고 있는 것으로 보입니다.

ASP.NET Ajax Bridge 컴포넌트(jMaki에서 XMLHttpRequest Proxy와 유사)의 미래에 대해서 몇 가지 큰 혼란이 있었습니다. 브리지 컴포넌트는 초기 "Atlas" 프리뷰의 일부였으나 결국 제외되었습니다. 이 핵심 Ajax 런타임에 다시 들어갈 수도 있다는 Microsoft의 공개 포럼에서의 일부 암시가 있었지만 아직까지 시기에 대한 어떤 명확한 표시는 없습니다.

새로운 기능 및 확장된 특징에 대한 요구를 만족시키기 위해 Microsoft는 "ASP.NET Ajax Futures"라는 릴리스 확장 기능을 시연하기 시작했습니다. 일례로 현행 2007년 5월 릴리스의 경우 Microsoft의 "Silverlight" 리치 클라이언트 애플리케이션 플랫폼과 함께 사용하기 위한 새 컴포넌트를 특징으로 포함하고 있습니다.

결론 

Web 2.0은 사용자 경험에 있어서 상당히 앞서 간 것이며, 동시에 기반 기술 및 툴킷은 여전히 진화하고 있습니다. 다양한 인터넷 애플리케이션이 생성될 수 있도록 Ajax 및 관련 프레임워크가 계속해서 성장하고 강력해지면서, 애플리케이션을 구축하는 방법과 사용할 기법을 결정하는 데 있어서 주요 변수로 상호운용성을 고려하는 것이 사용자에게 많이 권장되고 있습니다. 그러한 것에는 XML 또는 JSON과 같은 표준에 기반한 데이터 교환 형식을 선택하고, 실제 처리 로직으로부터 데이터 변환을 분해하며, 브라우저의 크로스 도메인 보안 계획을 제압하기 위해 클라이언트 측 또는 서버 측 프록시에 대해 결정하는 것 등이 포함됩니다. 이러한 요소들과 다른 많은 요소들이 Web 2.0 애플리케이션의 상호운용성을 위해 기여합니다. 뿐만 아니라, Sun, Google, IBM, BEA 및 기타 업계 선두 업체들은 OpenAjax Alliance에서 공동 연구를 통하여 산업 전반에 걸친 공통 Ajax 플랫폼의 비전을 촉진함으로써 더 높은 수준의 상호운용성을 가능하게 하고 있습니다. 다수의 혁신적인 Sun Web 2.0 기술을 Sun Web Developer Pack으로 모았으며, 여기에는 특히 ReSTful Web Services API, WADL, ROME API, project jMaki 외 다수가 포함되어 있습니다.

리소스

• Representational State Transfer
• NetBeans IDE
• jMaki Ajax plugin for NetBeans
• NetBeans JavaScript Editor
• GlassFish open source application server
• Ajax implementation by Microsoft
• ASP.NET Ajax Control Toolkit
• Windows Communication Foundation
• WCF ReST and POX sample
• "Java EE .NET Interoperability: Integration Strategies, Patterns, and Best Practices." Marina Fisher, Ray Lai, Sonu Sharma, Laurence Moroney
• Windows Vista Developer Center
• Windows Vista Developer CenterJava WSIT Tutorial
• JavaOne '07: Services Interoperability with Java Technology and .NET: Technologies and Tools for Web 2.0 TS-8840
• Sun Web Developer Pack

이 아티클의 영문 원본은 http://java.sun.com/developer/technicalArticles/J2EE/AJAX/interop/ 에서 볼 수 있습니다.

 

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.