Thankyou, I was afraid I might have to resort to this :)
Actually, it is not a bad option. Now my next question is where do I
put the client.axis2.xml so I can read it? Can I get a context that
will tell me the path that `./` accesses? My initial investigations
suggest that it may be my user directory, which is certainly not
helpful and I don't really want to hard code the path to somewhere.
Furthermore, it would be nice if client.axis2.xml could be in the aar.
btw, I have happily and succesfully created clients accessing thier
own axis2.xml via an explicit configuration context before, but the
clients have never been web services themselves.
thanks for the synapse tip, but I think this code is already too far
gone for a switch like that :)
Matt
----------------------
Matt Roberts
email: [EMAIL PROTECTED]
skype: mattr__
current favourite: ants :)
On 03/03/2008, at 1:03 PM, Anthony Bull wrote:
Hi Matthew, off the top of my head, you will need a separate XML
configuration file for configuring your "client"/outgoing messages.
Then pass that through to the configuration context, instead of the
file you have for your server. Thus your incoming security to your
middle man web service uses the configuration details in your
services.xml file, and the messages then get packaged up with the
security configurations in your axis2-client.xml file. You can
either create a new serviceClient for every request that comes
through or implement some type of pooling mechanism for the service
clients (as creating a service client is an expensive operation).
You will also need to consider whether the messages that you are
sending through to the back end service all use the same
authentication credentials or if these credentials are derived from
the incoming messages your middle man receives.
ConfigurationContext context =
ConfigurationContextFactory
.createConfigurationContextFromFileSystem( repositoryPath,
repositoryPath + "/conf/axis2-client.xml");
ServiceStub service =
new ServiceStub( context, serviceEndpoint);
If this was my project however, I'd use an Apache Synapse mediator
as your middle man instead of writing an Axis 2 service. You may
want to consider that, as it will end up being simpler to manage.
cheers,
Ants.
Matthew Roberts wrote:
Hi there,
I have an axis2 service that is actually just a middle man. It
exposes some services, but really it just does some small amount of
work and passes the service request on to another service.
As a result, I have some of the classes (the client connection
classes) from the back end service in my middle man service. This
has not been a problem so far, but now I am trying to secure the
communication with rampart and I am having some trouble working out
how I can set the inflow and outflow of the communications with the
back end service. For the back end service itself, there is not
problem, but where to I put configuration setting for the back end
client that is embedded in the middle man?
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Anthony
------------------------------------- Anthony Bull
Senior Developer
Black Coffee Software Ltd
PO Box 10-192 The Terrace
Wellington, New Zealand
[EMAIL PROTECTED]
Ph +64 4 472 8818
Fax +64 4 472 8811
------------------------------------- www.bcsoft.co.nz
--------------------------------------------------------------- This
email may contain confidential or privileged information, and is
intended for use only by the addressee, or addressees. If you are
not the intended recipient please advise the sender immediately and
do not copy, use or disclose the contents to any other person or
organisation.
Black Coffee Software Ltd accepts no responsibility for viruses
received with this email, or to any changes made to the original
content. Any views or opinions expressed in this email may be
personal to the sender and are not necessarily those of Black Coffee
Software Ltd.
---------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]