0 Replies Latest reply on Apr 28, 2004 5:32 AM by jecop

    publishing deployed Axis services in the embedded JUDDI

    jecop

      I played around with publishing my web services in the embedded JUDDI and posted my work so far as a patch on Sourceforge (see http://sourceforge.net/tracker/index.php?func=detail&aid=940772&group_id=22866&atid=376687)

      In the current patch the AxisService MBean sends a notification containing just the service name, which gets picked up by the JuddiService MBean. This then does the registration or deregistration
      using parameters set in file deploy\jboss-net.sar\META-INF\jboss-service.xml:

      <-mbean code="org.jboss.net.uddi.server.UddiService"
       name="jboss.net:service=Uddi"->
       <-attribute name="OperatorName"->J.B.Oss<-/attribute->
       <-attribute name="OperatorMailAddress"->admin@jboss.org<-/attribute->
       <-attribute name="SecurityDomain"->java:/jaas/jboss.net-uddi<-/attribute->
       <-attribute name="BusinessEntity"->YourCompany<-/attribute->
       <-attribute name="RootAccessPoint"->localhost:8080/jboss-net/services/<-/attribute->
       <-attribute name="PublisherName"->&lt;NOBODY&gt;<-/attribute->
       <-attribute name="PublisherPassword"->valid<-/attribute->
       <-attribute name="DropOnStartResource"->META-INF/juddi_drop_hsql.ddl<-/attribute->
       <-attribute name="CreateOnStartResource"->META-INF/juddi_create_hsql.ddl<-/attribute->
       <-!-- attribute name="DropOnStopResource"->META-INF/juddi_drop_hsql.ddl<-/attribute --->
       <-depends optional-attribute-name="WebServiceDeployer"->jboss.net:service=Axis<-/depends->
       <-depends optional-attribute-name="DataSource"->jboss.jca:service=DataSourceBinding,name=DefaultDS<-/depends->
       <-/mbean->
      (apologies for the <- ->syntax, but I found no other way to stop the forum app from interpreting the XML)


      The better approach would be for the AxisService to provide not just the service name, but also the URL where it will be publicly accessible, and remove the parameter RootAccessPoint above.

      The file axis-config contains the following:
      <-!-- In preparation for UDDI registration. In the event you prefer not
       register your web services, comment out the following section --->
       <-publish->
       <-parameter name="publish.url" value="https://www.utopiansoft.com"/->
       <-/publish->


      I do not think this was put there for the same intention as the RootAccessPoint I defined, but assume it is instead the URL if the (external) UDDI service you want to use to publish services in.
      Can anybody tell me if that assumption is correct?

      Rather then make the AxisService responsible for publishing in external URLs I propose to let the AxisService send a notification (like implemented in the patch)
      and create a new MBean, listening for those events and responsible for remote UDDI registration. This makes the system more configurable (e.g. allow registration in multiple UDDI's) and decouples the service deployment (in control of the application) from the remote registration , which depends on a response from a remote service, so can take a long time to complete.
      In this case, the remote UDDI URL becomes parameter for this new MBEAN,
      together the other information required for a publication: username+password to authenticate with the remote service, business entity under which the service is deployed

      Then I would like to replace this publish.url parameter with the RootAccessPoint parameter I currently defined for the JUDDI service.
      e.g. If my JBoss server's public URL is http://www.company.com, the root access point is defined as

      http://www.company.com/jboss.net/services/

      and the Axis notification contains this URL + service name. the receiver of the notification (JUDDIService or remote UDDI registration MBean) uses this to publish the service access point

      I would like people's opinion

      * on the proposed approach
      * if the axis service should create the URL to the service and have that as a string in the notification or if a richer construct is required (e.g. a XML structure with service elements, containing name and url attributes


      Jeroen