자바 서블릿에서 SOAP (Consuming Spring) 웹 서비스

Question

JAX-WS를 가리키는 umpteen 스레드가 제안한 것처럼 클라이언트에서 스텁을 생성하지 않고 SOAP 기반 스프링 웹 서비스를 사용할 방법이 있습니까?

나는이 웹 응용 프로그램을이, 봄 지원을 둘 APP1 & APP2을 말 :

여기 내 완벽한 시나리오입니다. APP2는 POJO (Reqeust 및 Response 객체)를 통해 Spring-WS로 API를 제공합니다. 비누. 이제 APP1에서 이러한 웹 서비스를 호출하려고하지만 WSDL frmo APP2를 사용하여 스텁을 작성하지 않아도됩니다. 이것이 가능한가? 당신이 볼 수있는 웹 서비스 방법은 CreateNewReqRequest을 받아 CreateNewReqResponse를 반환 지금

@PayloadRoot(localPart = "CreateNewRequest", namespace = "myNameSpace") 
public CreateNewReqResponse createNewRequest(CreateNewReqRequest requestObj) throws Exception 
{ 
    NewCase newCase = this.localSpringService.createNewCase(requestObj.getParam1(), requestObj.getParam2()); 
    CreateNewReqResponse response = this.objectFactory.createCreateNewReqResponse(); 
    CreateNewReqResponseObject responseObject = this.objectFactory 
      .createCreateNewReqResponseObject(); 
    if(null != newCase) 
    { 
     responseObject.setParam1(newCase.getParam1()); 
     responseObject.setParam2(newCase.setParam2()); 
     } 
     responseObject.setCaseRequestedDate(caseRequestedDate); 
    } 
    response.setResponseObject(responseObject); 
    return response; 
} 

:

은 자세한 내용을 보려면 여기를 내 웹 서비스의 작동 중 하나입니다. 내가 알아 내려고하는 것은 어떻게 App1에서이 웹 서비스를 호출 할 수 있는가하는 것입니다.이 클래스는 CreateNewReqRequest와 CreateNewReqResponse 클래스에 대한 단서가 없습니다. JAX-WS를 사용하여 APP1 (WSDL에서)에 스텁을 만드는 것 외에 다른 방법이 있습니까?

문제의 두 응용 프로그램 모두 자체적으로 개발되었지만 다른 서버에서 실행됩니다. 그 이유는 APP1이 웹 서비스를 직접 호출 할 수 없기 때문입니다 (상호 도메인 정책). 따라서 APP2에 노출 된 웹 서비스를 사용하는 서블릿을 APP1에 작성합니다.

Answer 1

하루가 끝날 때 SOAP은 HTTP 위에 단순한 프로토콜입니다. 따라서 JAX-WS 사용을 포기하고 싶다면 원시 HTTP 연결을 사용하고 SOAP 요청을 수작업으로 처리하고 직접 SOAP 응답을 파싱 할 수 있습니다. 이는 단순히 JAX-WS 클라이언트 스텁 인 휠을 다시 발명한다는 것을 의미합니다.

그래서 스텁 생성을 절대적으로 피하고 싶다면 HTTP 게시로 이동하여 WSDL 끝점 URL에서 메시지를 가져 오십시오.

클라이언트 스텁의 기능은 단순히 구현을 추상화 한 것입니다. 즉, SOAP/WSDL 및 http 연결을 다루지 않아도된다면 Java 객체를 통해보다 높은 수준의 SOAP을 처리 할 수 ​​있습니다.

Apache CXF 나 Axis와 같은 다른 라이브러리를 살펴볼 수도 있지만, 거기에서도 클라이언트 스텁을 생성해야합니다.

당신이 물어보고 싶은 질문은, 실제로 들어 와서 수동으로 http 연결과 SOAP XML을 사용하거나 프레임 워크가 당신을 위해 과감한 작업을 수행하도록 할 것인가하는 것입니다.

니틴의 댓글에 답글 달기가 귀하의 질문에 대답하기 위해

아래 다음, 1. 네, 당신은 당신이 스텁을 사용하고 있지만 모든 구문 분석되지 않을 경우 WSDL 변경, 수동으로해야합니다 경우 스텁을 다시 만들어야합니다 해당 코드를 변경하십시오. 그렇게 효과적으로 두 사람 사이에는 차이가 없습니다. WSDL (즉, 클라이언트와 서비스 간의 계약)이 변경되면 프로그램을 변경해야합니다. REST의 경우에도 마찬가지입니다. 즉, 서비스에 의해 게시 된 계약 (매개 변수 또는 동작 등)이 변경되면 클라이언트 코드를 변경해야합니다. 저것 도주하는 것이 없다. 바라건대, 공개 Webservices는 미래의 수정을 허용하는 그런 방법으로 설계되었을 것이며, 그러한 수정은 하룻밤 사이에 발생하지 않으므로 코드를 수정할 충분한 시간을 가질 수 있습니다. 이 문제는 웹 서비스가 구현 된 방식과 아무 관련이 없습니다. 즉, 스프링 웹 서비스는 아무 관련이 없습니다.

JAX-WS, Axis, CXF와 같은 SOAP 프레임 워크가 생성하는 클라이언트 스텁 포인트가 누락 된 것처럼 보입니다. 클라이언트 스텁은 웹 서비스와 대화하는 한 가지 방법입니다. 그것은 유일한 방법은 아닙니다. 클라이언트 스텁은 선호되는 방법입니다. SOAP 스텁을 수동으로 처리하는 데 드는 번거 로움을 추상화하기 때문입니다. 따라서, 바퀴를 발명하고 SOAP (XML) 구문 분석 라이브러리를 구현하는 대신, 작성중인 실제 응용 프로그램에 집중할 수 있습니다. 실제 프로그램에서 POJO 만 처리하면 SOAP 매직이 어떻게 일어나는지에 대해 걱정할 필요가 없습니다. 즉, SOAP 메시지에서 데이터를 변환하고 패키지하는 방법, HTTP 연결을 사용하여 SOAP 메시지를 서비스로 보내는 방법, 응답 처리, 응답 SOAP 메시지 구문 분석 및 관심있는 데이터 검색. 이 모든 것은 POJO를 사용하지 않아도됩니다. 요청에 대한 속성을 설정하고, 클라이언트 스텁 서비스 메소드에 대한 메소드 호출을 작성하고, 오브젝트를 수신합니다. 그 밖의 모든 것에 대해 (이상적으로) 걱정할 필요가 없습니다.

나는이 명백한 것을 조금 희망한다.

Answer 2

WebServiceTemplate 클래스를 살펴보십시오.