Having been involved with individuals who
<inadvertently> introduce race conditions on either the DB or Webapp
layers
causes me to be careful around <junior> engineers who
are coding SoapServices which are in fact not SOAPServices but instead
are
<dumb>Proxies assembling data points
from n number of SOAPclients
In those particular scenarios
You will have to have introduce some sort of architectural
constraint where a developer that desires a complexDataType
resultset
would NOT inadvertently introduce a SOAPService which is NOT a soap service per se but is a soap
client to n number of unknown SOAP Services
but WILL return the correct complexDataType from
SOAPService
I cannot speak in a comprehensive manner as to the
efficacy of CORBA
but my understanding of CORBA states that
CORBA supports marshalling discrete elements of known datatype from client thru
IIOP to to ORB implementor
Whether you are using CORBA or I am using RPC
it seems that we both are using 2 differing implementations of the same concept
that is
SomeClientRequestsDatatype ->
DeliversRequestViaSomeTransportSpecificDatatype
->ServerAcknowledgesRequestAndAcksWithRequestedDataPoint
Perhaps you can shed some light on how CORBA could
be used in this scenario?
Martin-
This e-mail communication and any attachments may contain confidential and
privileged information for the use of the
designated recipients named above.
If you are not the intended recipient, you are hereby notified that you have
received
this communication in error and that any review, disclosure,
dissemination, distribution or copying of it or its
contents
----- Original Message -----
Sent: Tuesday, October 24, 2006 8:04
AM
Subject: AW: AXIS 1.4: invoke request
after web service sent response to client
Are you saying that the architectural concept of having a
CLIENT going to an AGENT passing on to
a SERVER is bad? :-/
In my mind an AGENT is two-fold as described by .-1
what all about is the then CORBA? :-)
Josef Stadelmann
would be helpful if you looked at the
definition of atomic transactions and the principle of
atomicity
redesigning a web service that itself is a client to another
web service may possibly invite a race condition
AxisClient1 calls AxisService1 and expects
output from AxisService1
AxisService1 calls AxisService2 and expects
output from AxisService2
AxisService2 calls AxisService3 and expects
output from AxisService3
AxisService3 calls AxisService1 (AxisService3
is contending for output for AxisService1 but so is
AxisClient1)
therefore AxisService3 AND AxisClient1 are both vying for the same resource
(AxisService1)
from a purely architectural
perspective this is BAD DESIGN
If you want more than 1 data item then
your AxisSoapService should return a complex datatype which wholly contains
all of the data points you desire
Please read this discussion of atomicity by
svend frolund
Martin --
This e-mail communication and any attachments may contain confidential
and privileged information for the use of the
designated recipients
named above. If you are not the intended recipient, you are hereby notified
that you have received
this communication in error and that any review,
disclosure, dissemination, distribution or copying of it or its
contents
----- Original Message -----
Sent: Tuesday, October 24, 2006 6:32
AM
Subject: AXIS 1.4: invoke request
after web service sent response to client
Hi all,
I am curious is it possible to configure AXIS server to
invoke another web service as client after response is send to
client.
for example Transaction like:
1. Client No. 1
invokes method of Axis service No. 1
2. Axis service No 1 responses to
Client No. 1
3. Axis service No 1 invokes web service No. 2 as
Client No. 2
4. Axis service No 1 receives response from service No.
2.
5. Transaction is commited.
Thanks in
advance,
Kestas
