|
Martin
you are right in many aspect. I am a newby to SOAP &
WS, but have some years with OO and
CORBA too.
the architectural
concept for MY agent, for shure, it requires
constraints.
i.e. a client needs to know the
service an agent can provide without knowing the details how the
agent gets to the answer. for the client the
agent is the server, the service provider. Beneficial
for
the client. It has to know only one interface, one
"contract".
would you allow to say, an agent is a broker and knows
where a certain service is delivered which can
fulfill the request of the client
asking?
asking just
a <dumb>proxy is for sure a no-go in my scenario, - but is
often seen with varying results.
i.e. I would myself not
ask just <any>agent when I intend to find a
"cheap-air-line-ticket-provider".
In this context I have to
know those agents working close with "air-line-ticket-providers", but not
more.
I.e. I would myself not ask
an "air-line-ticket-proving-agent" when I seek a car for which I
intend
to spend a certain budget but
expect otherwhise the best matching/performing care for my
money.
As a client, asking a
"cheap-airline-tickets-provider-agent" can be beneficial
i.e. I do not have to sort out
and work-up all the varying details (datatypes)
provided by various n types of
"air-line-ticket-providers"
to be able to get the best
price/performance match. How the agent sorts out details returnd from the
servers
is the secret of the agent in charge as
a server to its client.
As long as the agent can provide to the client
what the client wants, all is OK for the client.
I think it also a very common
mistake that client's know too much about servers, which has a bad impact
when the server changes.
But, not knowing anything about a server and just
asking a <dumb>proxy points to
a <dumb>client,
(unless the client is introspecting by intention
the server on a dedicated interface.)
This could be an
administrative function for an agent in an atempt to find new
matching servers,
new "air-line-ticket-providers". New
servers to deal with when the client intends to pay.
etc.etc.
Implementing an agent can
be of great help. it can take the burden of sorting out all kind of late changes
at
the server side edge.
Given the case that an agent deals with 3 service
providers, maybe 4 tomorrow. the client
shall not know about this. In
this case a server can shut down, the client is still served
unless there are no more
servers, in which case the agent
migth have a suggestion or the like, and tell the client
that he can wait unless
at least one server
is back, or can cancel his request, or offers him an asynchronous
callback if forseen.
Should a server change and the agent
does not come clear with this change. Nothing will happend to the client.
The client gets
served. But the agent will possibly be modified to adopt for
the changed/new type answer of one
of it's service providers. (i.e.
refine the RPC or CORBA IDL to the new/changed server, then get/generate) new
stubs to talk
properly to the new/changed server(s)).
Over all, the result is a
system more "resilent to change" I would also call it a more robust
system.
As a SOAP/WS newby, I can not yet
see how to implement this best using SOAP/WS,
but with CORBA I would build my
"expert-agent" with this architectural constraints in mind.
Josef
-----Ursprüngliche
Nachricht-----
Von: Martin Gainty [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 24. Oktober 2006 14:59 An: [email protected] Betreff: Re: AXIS 1.4: invoke request after web service sent response to client
|
