1 2 3 4 Previous Next 51 Replies Latest reply on Sep 25, 2006 11:44 AM by kurtstam Go to original post
      • 45. Re: Registry Design
        marklittle
        marklittle Sep 5, 2006 6:09 AM (in response to mugdho)

         

        "Kevin.Conner@jboss.com" wrote:
        Good, I'm glad that's clear :-)

        It may be that I have misunderstood the discussion but my concerns were the following
        - talk of defining the interface in SOAP and embedding in a servlet container
        - talk of clustering facades for non clustered implementations

        While both of these may be important from an implementation and deployment perspective, neither is relevant to the service interface being defined.

        The priority for now is to work out the requirements for this interface and, while we should keep the implementation details in mind, these details should not distract us from the specification of the interface.


        Agreed. Talking about SOAP and clustering is immediately taking us down the implementation route. Although they are relevant to the topic (Registry Design), I think it would be easier if we tried to keep each topic narrowly focussed. We already had a discussion around the API, http://www.jboss.com/index.html?module=bb&op=viewtopic&t=81236 where we agreed to use JAX-R.

        We shouldn't be thinking about implementing a registry at this stage: believe me, it'll take more time than we have available to us for the first GA. Plus, it's a product/project in its own right (there are several companies whose sole reason to exist is to sell a registry). Where I think we should be going with this is: given we'll use JAX-R for now, what does that mean for the ESB? What JAX-R implementations are out there that we can use? Do we have to implement our own JAX-R system (hopefully not). Assuming we have JAX-R support, what existing registry implementations can be tied into it?

          • Actions
        • 46. Re: Registry Design
          anil.saldhana
          anil.saldhana Sep 13, 2006 2:58 PM (in response to mugdho)

          Assuming you want to prototype and plan to use JAXR against jUDDI, here are some relevant details.

          * Pick up Scout/juddi versions from jboss-4.0.4.GA
* Create a version of the juddi transport interface. Scout will use this transport to communicate to juddi. So you can make a local call here (not use soap or any transport).
Eg:
http://viewcvs.labs.jboss.com/cgi-bin/viewcvs.cgi/jbosstest/build.xml?only_with_tag=Branch_4_0

The system property is:
<sysproperty key="juddi.proxy.transportClass" value="org.jboss.jaxr.juddi.transport.SaajTransport"/>


* There is a bloated JUDDI Servlet that picks up the incoming soap message, parses the uddi op and then calls its internal infrastructure. So you will need to peek in and assume that you have the uddi op (as you are making a local call in the transport) and pick up the infrastructure call and plug it into the transport that you used in aforementioned step.

http://viewcvs.labs.jboss.com/cgi-bin/viewcvs.cgi/contrib/varia/src/main/org/jboss/jaxr/juddi/JUDDIServlet.java?only_with_tag=Branch_4_0

So basically you have removed the extra step of marshalling in the transport and unmarshalling in a servlet. You have combined the scout and juddi via a local call in the transport.

Underneath, Scout uses juddi proxy to communicate and this transport interface is part of it.


          This info is for Kurt.

            • Actions
          • 47. Re: Registry Design
            kurtstam
            kurtstam Sep 13, 2006 9:39 PM (in response to mugdho)

            Thanks Anil, I'm going down that road. For now I'm making SOAP calls to trace down the calls. When I deploy juddi to tomcat this works great, however when the juddi.war is deployed to jboss-4.0.4GA most calls result in a stack trace:

            21:14:33,000 INFO [STDOUT] 2006-09-13 21:14:33,000 [http-0.0.0.0-8080-2] INFO org.apache.juddi.util.jdbc.ConnectionManager - Using JNDI to aquire a JDBC DataSource with name: java:comp/env/jdbc/juddiDB
            21:14:33,359 INFO [STDOUT] 2006-09-13 21:14:33,359 [http-0.0.0.0-8080-2] ERROR org.apache.juddi.registry.AbstractService - NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces.
            org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or change an object in a way which is incorrect with regard to namespaces.
            at org.apache.xerces.dom.AttrNSImpl.setName(Unknown Source)
            at org.apache.xerces.dom.AttrNSImpl.(Unknown Source)
            at org.apache.xerces.dom.CoreDocumentImpl.createAttributeNS(Unknown Source)
            at org.apache.xerces.dom.ElementImpl.setAttributeNS(Unknown Source)
            at org.jboss.ws.soap.SOAPElementImpl.setAttributeNS(SOAPElementImpl.java:616)
            at org.jboss.util.xml.DOMUtils.copyAttributes(DOMUtils.java:315)
            at org.jboss.ws.soap.SOAPFactoryImpl.createElement(SOAPFactoryImpl.java:81)
            at org.jboss.ws.soap.SOAPBodyImpl.addDocument(SOAPBodyImpl.java:82)
            at org.apache.juddi.registry.AbstractService.doPost(AbstractService.java:192)
            at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
            at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)

            I'm trying to figure out what's going on here. I'd like to have this working before creating the local call mechnism, also because it may come in handy to make soap calls from some client tool. I think we want to insert data using a client tool.

            More people seem to report this issue, using xalan and xerces. Maybe it's a conflict with the libs in java5.



              • Actions
            • 48. Re: Registry Design
              kurtstam
              kurtstam Sep 15, 2006 1:39 PM (in response to mugdho)

              I have updated the http://labs.jboss.com/wiki/Jbossesb/JAXR page and I added a page just for jUDDI http://labs.jboss.com/wiki/JudyEvaluation

              This far it looks like we ESB -> JAXR -> Scout -> XMLRepository will work great. For our default reposity we can use a embedded version of jUDDI, so that we can make local calls to the registry. However if you have your own XML repository one would need to configure Scout to use SOAP.

                • Actions
              • 49. Re: Registry Design
                anil.saldhana
                anil.saldhana Sep 15, 2006 2:22 PM (in response to mugdho)

                http://viewcvs.labs.jboss.com/cgi-bin/viewcvs.cgi/contrib/varia/src/main/org/jboss/jaxr/juddi/JUDDIServlet.java?rev=1.4&content-type=text/vnd.viewcvs-markup

                I had to carefully construct the soap message such that I would not hit this issue where xerces does not like the use of xmlns namespace be assigned to anything other than the standard xml namespace. As you can see, it does not like:

                xmlns="urn:juddi-org:api_v1"


                  • Actions
                • 50. Re: Registry Design
                  kconner
                  kconner Sep 18, 2006 4:59 AM (in response to mugdho)

                  This is a default namespace declaration and would be a peculiar bug is xerces didn't like it. This is widely used in XML processing.

                  How does xerces fail when you define a default namespace?

                  Kev

                    • Actions
                  • 51. Re: Registry Design
                    kurtstam
                    kurtstam Sep 25, 2006 11:44 AM (in response to mugdho)

                    Yep it was a juddi bug setting the (wrong) namespace, see

                    https://issues.apache.org/jira/browse/JUDDI-91

                    --Kurt

                      • Actions
                    1 2 3 4 Previous Next