2 Replies Latest reply on Jan 17, 2013 3:49 PM by Christian Groove

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

    Christian Groove Newbie

      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



      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 ?



        • 1. Re: datasource like adress rewriting for webservice client (inside a ejb3 session bean)
          Alessio Soldano Master


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


          • 2. Re: datasource like adress rewriting for webservice client (inside a ejb3 session bean)
            Christian Groove Newbie

            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


            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 ?




            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"?>


                      <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"


                                              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 nam.....................







            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());




            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 .