Сначала несколько ошибок с семантикой:
Вы создали массив с помощью ArrayNew (1), но вы неявным образом принудительно вводите каждый индекс массива в Struct, заклинивая ключи на конце, что меняет его тип (поскольку ColdFusion динамически типизируется). Рассмотрим:
<cfloop from="1" to="10" index="i">
<cfset personArray[i] = StructNew() />
<cfset personArray[i].object = createObject("component", "person")>
<cfset personArray[i].name = "personname" />
<cfset personArray[i].surname = "personsurname" />
</cfloop>
Теперь personArray остается истинным массивом, а не передается в Struct перед передачей.
Однако существует гораздо более серьезная проблема ...
Обмен сообщениями через Web-сервис через SOAP не предназначен для облегчения поддержки передачи сложных бизнес-объектов из точки в точку; Это распространенное заблуждение, которое сбивает с толку и расстраивает разработчиков, которые только начинают работать с SOA. Это не проблема, свойственная ColdFusion и / или .NET - это низкоуровневое ограничение SOAP.
Давайте пока предположим, что был способ сделать то, что вы хотели, и в вашем вышеупомянутом компоненте "Персона", который в рамках ColdFusion существует как целостный объект со своими собственными свойствами и методами, некоторые из которые включают в себя поддержание состояния (скажем, isPersonLoggedIn ()) и внутренне, что управляется функциональностью, присутствующей в ColdFusion (т. е. автоматической обработкой CFID & CFTOKEN, доступом к общей области SESSION и т. д.)
Теперь, если вы гипотетически могли передать зарегистрированный объект "Person" в приложение .NET, а затем это приложение .NET решает вызвать isPersonLoggedIn () на своем конце - как бы оно могло узнать как это сделать? У него нет понимания CFID или CFTOKEN, нет понятия разделяемой памяти (или, по крайней мере, того, как ColdFusion ожидает обрабатывать совместно используемую память) - и не существует ничего, чтобы перевести эти понятия по проводам, поскольку (конечно) поддержание указанного состояния существует в пределах физической границы оперативной памяти на CF-сервере.
Хотя это и дикая аналогия, она, как мы надеемся, должна прояснить более ясную картину того, почему вы не можете делать то, что вы пытаетесь - передать сложный бизнес-объект по проводам через механизм, который (в своей основе) представляет собой поток XML.
Когда вы разрабатываете сервисы на основе SOAP (потребители и производители), вам нужно думать с точки зрения простых значений: найдите имя этого пользователя. Дайте мне номер телефона этого сотрудника. Скажите, сколько записей в этой базе данных для данного идентификатора отдела.
В отличие от: Возьмите этот бизнес-объект, который представляет все функциональные возможности, которые мы можем выполнять с «Лицом» в пределах нашего приложения, о котором не знает ни одно другое приложение в мире, - и волшебным образом передайте это любому приложению и ожидайте, что он будет вести себя так же.
Заберите очки:
Подумайте о переосмыслении вашего дизайна. Вместо передачи самого объекта Person, методы проектирования, которые будут искать только определенные дискретные значения, основанные на объекте person (т. Е. PersonID, PersonName, NumberOfPeople и т. Д.)
См. в этой таблице типов данных для связи с веб-сервисом в ColdFusion .
В противном случае, люди, которые создают службу .NET, спросят вас о большом количестве предварительно скомпилированных классов на вашем конце, которые должны быть интегрированы на их конце, чтобы понимать ваши бизнес-объекты. ... и с этого момента вы больше не общаетесь через веб-сервисы через SOAP - вы общаетесь по телефону ... с их сотрудниками по разработке ... каждый раз, когда меняется один бизнес-объект, и вам обоим приходится переработать код.
Для дальнейшего чтения взгляните на мой ответ для кого-то в StackOverflow, который задал обратный вопрос .