datasource like adress rewriting for webservice client (inside a ejb3 session bean)

[thegroove]

Dear Sirs,

i am trying to develop an EAI application, that has to access several (outbound)

webservices. Due tue the application requirements we want to run the web-services

client request inside a transaction context (2phase commit) and want to glue it with

other IO operations (as far as possible)

[ .. so no Spring solutions please! We are actually do  lot of with MDB's and transactional batch processing and transaction]

My understanding of an deployable application is, that its linkage with

real physical ressources shall be done by the app-server, to be concrete

resouces definitions.

For JPA/Databasse access this is quite well defined, some *ds.xml define the

physical connections to the database(s). Each development stage

(dev,test, integration, prodmirror, prod) has its own physical context.

Without any changes or recompilations i can easily deply my ear-file

into each stage. So how can this process been kept up with webservice

clients?

The application server i am using is a JBoss6.1 (free an later also the

commercial version).

The thing that makes me worry is, that the client side adressiing seemed to be

completly overlooked in most of WS-articles an posting i have investigated the

past 3 days.

Well i also took a considered the EndpointRegistry service inside the JMX-console.

I think there seemed to be a mean inside for to overwrite th default address of the

WSDL definition but unfortunately i was not able to find any explanation on the web.

So thank you in advance for any helpful ideas or tips (code or whatever you have)!

A solution with a JNDI entry, that can be "deployed" into the deploy-directory would be perfect!

(further question) What about ressource-pooling with web-services, is this also possible ?

I guess that the WS-provides wnats to limit the amount of web-service access, would

be ressource pooling (similar to jdbc pools) an option ?

Groovie

[asoldano]

Hi,

sorry, I'm not sure I completely grasp your issue/doubt, can you perhaps explain it further with some examples?

Thanks

[thegroove]

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:

	JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
	/* stack loggers around in outputstream */
	factory.getInInterceptors().add(new LoggingInInterceptor());
	factory.getOutInterceptors().add(new LoggingOutInterceptor());
	factory.setServiceClass(AccountingBean.class);
	factory.setAddress(TARGET_URL);

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