나는 우리 조직의 상태 기반 웹 서비스에 대한 필요가
stateful webservices상태 유지 Webservice를
중복. 그러나 온라인으로 읽는 모든 곳에서 상태가 좋은 웹 서비스를 구축하는 것은 나쁜 프로그래밍이지만 아무도 이유를 밝히지는 못한다고 말합니다. 나는 그것에 대해 나쁘다는 것을 이해하지 못한다고 생각합니다. 나는 또한 왜 그들이 당신이 webservice에 국가를 가질 수 있도록하기 위해 일을 줄 것인지 이해하지 못합니다.
그래서 내 질문에, 왜 나쁜 프로그래밍이 상태 유지 웹 서비스를 사용하고 있으며 왜 허용 될 것이라고 생각하십니까?
웹 서비스의 모든 목적은 확장 성이 뛰어난 방식으로 한 트랜잭션에서 기능을 전달하는 것입니다. 이것은 물건을 단순하고 원자 적으로 유지하는 것을 의미합니다.
작업을 수행하기 위해 여러 번 호출해야하는 경우 트랜잭션이 중단 될 가능성이 큽니다. 고객이 다시 돌아오고 있습니까? 그들은 끝났습니까? 트랜잭션은 얼마나 오래 열려 있어야합니까? 그들이 추락 했습니까? 롤백은 어떻게 처리해야합니까?
이 질문에 대한 대답은 서비스를 실행하는 데 필요한 리소스에 근본적인 영향을 줄 수 있습니다. 그래서 모두가 한 번에 모든 것을 할 것을 권장합니다.
우수 답변! 또한 작업이 상태 저장 인 경우 서버가 실패하면 어떻게됩니까? (그리고 그렇게 될 것이다.그래서 우리는 서버 클러스터를 운영합니다.) 모든 상태가 손실됩니다. Stateless를 사용하면 아무 일도 일어나지 않은 것처럼 클러스터의 다음 서버로 요청을 다시 제출할 수 있습니다. –
전혀 아닙니다. 웹 서비스는 원격 응용 프로그램 간의 시장 전반에 걸친 공통 통합 기술입니다. 우리가 처리하는 대부분의 작업이 무국적이기 때문에 대부분 상태 비 저장이므로 ... 실제로 상태가없는 접근이 올바르지 않은 경우 여러 가지 비 상태 유지 서비스를 사용하는 사람들이 오해 할 수 있습니다. – BonanzaOne
여기에 내가 생각할 수있는 몇 가지 이유가 있습니다 :
해야합니다 상태를 유지하는 비용은 서버 측이 부담하기 - 서비스 소비자는 거의 웹 브라우저 없다, 그래서 쿠키가 없습니다. 이는 서버 성능을 저하시키고 설계 복잡성을 증가시킵니다.
서비스 소비자는 벙어리 브라우저가 아닌 지능적인 프로그램입니다. 이와 같이 프로그램은 (거의 항상) 자신의 상태를 유지합니다. 즉, 서비스를 제공 할 때 소비자는 원하는 데이터를 정확하게 요구합니다. 서버에서 상태를 유지 관리하는 것은 쓸모없고 불필요하게됩니다.
트랜잭션 - 클라이언트의 대부분이 지능적이기 때문에 서비스는 시스템의 매달린 지점이며, 사용자가 상태 변경을 알려야 할 시점을 결정합니다. 즉, 상태를 유지 관리하는 경우 트랜잭션 작업을 완료하기 위해 서비스 호출 사이를 기다려야 할 수 있습니다. 고객이 다음 번 서비스 요청을하게 될 것이라는 보장은 없습니다.
이 많은 이유가 있지만, 이러한 내가 내 머리 :
의 맨 위에 떨어져 생각할 수있는 것들 나는 그것이 신화
의 종류 구글이 할 수있는 경우라고 생각됩니다 스테이트 풀 웹 응용 프로그램을 확장 가능하게 만든 다음 왜 스테이트 풀 웹 서비스를 확장 할 수 없습니까? 확장 성을 줄이는 것은 앱 서버에 관한 것입니다.
웹 사이트 또는 웹 서비스가있는 경우에도 궁극적 인 목적은 더 나은 서비스를 제공하는 것입니다. "stateful"이 서비스를 향상시키는 것이라면, 주저하지 말고 함께하십시오.
Google의 어떤 부분에 대해 이야기하고 있는지 명확히 할 수 있습니다. 주요 google.com은 '상태있는'것이 아닙니다. – NotMe
다른 방식으로 보겠습니다.이 서비스는 상태 저장을 위해 무엇이 필요합니까? 그것은 creativly 연기와 mirror'd 수 있습니까? –