내 직장에서 최근에 SOA 이니셔티브를 시작했습니다. 1 년 동안 가장 큰 벤더 (IBM과 오라클)를 조사한 결과, 어느 것이 사용되는지 결정 중이며 현재 전체 SOA 스택 (애플리케이션 서버, BAM, 프로세스 서버, ESB, UDDI와 같은 솔루션 등).공급 업체가 제공 한 SOA 스택을 사용하는 조직은 얼마나됩니까?
SOA를 실제로 사용하고있는 조직은 얼마나됩니까? 이 기술은 더 나은 증거를 보여 줍니까? 나는 'Silver Bullet'증후군을 두려워합니다.
저는 SOA 샵에서 일하고 있습니다. 우리는 자체 스택을 판매합니다. 아마도 우리가 사들였습니다!) 비즈니스가보다 원활하게 진행될 수 있도록 도울 수 있습니다.
사람들은 서비스로 모든 것을 만들기 시작하고, 당신은 ESB를 삽입하기 전에 한대로 당신은 많은 상호 연결 및 인터페이스와 끝까지 : 때
문제는 온다. 이로 인해 변경이 매우 어려워집니다.
휴먼 인터페이스와 함께 BPM을 사용하는 경우 : 사람들은 포틀릿을 가져 오지 않습니다. 개별 포틀릿을 하나의 태스크로 만드는 대신 BPM의 오브젝트를 무효화하는 많은 작업을 수행합니다. 필요한 경우이 많은 항목을 확장 할 수 있지만 이는 사용자에게 적절하지 않을 수 있습니다.
모두 구현되었습니다. 대규모 시스템 변경이므로 슬라이스별로 슬라이싱 해보십시오. (예 : 웹 서비스가있는 기존 시스템을 전면에 배치하고 위에 새 UI를 작성한 다음 이전 시스템으로 이동 한 UI 호출을 새로운 시스템으로 점진적으로 대체하십시오.) 이렇게하면 사용자 수용을 돕고 일을하는 데 훨씬 안전한 방법입니다. 경영자는이 접근법 (관리하기가 더 어렵습니다)을 원치 않지만 이점을 강조합니다. 많이.
코드없는 개발로 판매됩니다. 이것은 존재하지 않으며 아마도 결코 존재하지 않습니다. 코드를 작성하지 않아도 코드이 작동하는 방법을 알지 못하면 코드가 불완전하거나 잘못 작성되거나 유지 보수가 불가능할 수 있습니다.
SOA가 잘 수행되면 비즈니스가 6 배로 돌아갈 수 있다고 본 것에서 보면 멋지다. 그것이 나쁘게 끝나면 아마 당신의 기존 시스템보다 더 나쁘지는 않을 것이지만 더 나아지지는 않을 것입니다. 그리고 당신은 그 사이에 값 비싸고 아픈 시간을 가질 것입니다.
나는 고객 목록을 줄 수는 있지만 꼭해야한다면 망설이게 될 것입니다. 스택이 끝날 때마다 거대한 브랜드 이름을 사용한다고 말하면 충분합니다.