Dear Alessio,

thank you for your reply and sorry for my late respond.

My acutal job is to code/design a billing engine, that may talk to a

accounting legacy application and a salesforce instance via

Webservices.

Bulk processing like  this can be perfectly implemented using

MDB's/SLSB, so that's the reason why i am prefering a

EJB based solution.

1) transactional intergation

As a consequence of this, we may initiate  our Webservice client

request from an transactional context. So it would be cool to

integrate this into a connector based webervices client endpoint.

Ressource pooling or better say a control over the connection

to a service portal with cost (like SF) is also of importance.

I remember in Apache CXF (that seems to be the origin of JBoss CXF)

commes with a connector support. So it would be interesting to

see the best fit adaption for JBoss (+CXF).

2) adress rewriting

There is another thing that is beneficial solved with connectors: adressing. 

Creating the stubs for a Web-service leaves the

URI inside the WSDL  as the default adress to connect with

the target. So imagine your sofware is beeing built and tested with

Jenkins calling a Legacy-App test instance using  Websrvices.

Then the deployer take the proven ear and puts it (after a functional

acceptance test) to the production, without changing the ear.

So how would your make sure, that your application server contacts

the productive legacy app and not the test instance of jenkins ??

IBM Webshpere has a solution for this issue. They call it WS-profiles,

where they store the rewriting adressesl. For the JBoss app server

and also Apache-CXF this issue was'nt focused by nearly nobody.

That makes me weired ................. brrrrr

So where to place the adress-rewriting ?

Answer:

1) Create a service file in the deploy directory, of all web-services, you

want to rewrite their default adresses, i called the file: wsRewriting-service.xml

that contains:

<?xml version="1.0" encoding="UTF-8"?>

<server>

          <mbean code="org.jboss.naming.JNDIBindingServiceMgr" name="jboss.apps.Billing:name=InfoBeanRef1">

                 <attribute name="BindingsConfig" serialDataType="jbxb">

                   <jndi:bindings xmlns:xs="http://www.w3.org/2001/XMLSchema-instance"

                                  xmlns:jndi="urn:jboss:jndi-binding-service:1.0"

                                  xs:schemaLocation="urn:jboss:jndi-binding-service resource:jndi-binding-service_1_0.xsd">

                       <jndi:binding name="NovisionAccountingRedrAddr">

                           <jndi:value trim="true">http://xxx.xxx.xx.xx:1234/.....</jndi:value>

                       </jndi:binding>

              <jndi:binding nam.....................

              </jndi:binding>

                   </jndi:bindings>

                  </attribute>

          </mbean>

</server>

This seems to load the adresses into the NS, whem JBoss is starting.

And inside my JAVA Code:

where TARGET_URL was simply lookup'ed.

This way has one advantage, that all adresses are stored in the

deploy directory, similar to the datasource files of connectors/jdbc ressources.

This looks like to be a good solution precenting us to feed test data

into production.

3) ... your ideas

i hope my way of adress storage/rewriting is OK for you. If you have another

standardized or easier method let me know.

The connector oriented integration of webservice clients is from my point

of view a little bit neglected. The EJB layer is responsible for IO and transactional

issues, to what is the better place to issue a webservices client call ?

... issue 2 solved by myself, but 1 still prending ...

sending my best regards from bavaria .

Groovie