[jboss-dev] Bind interfaces coming from ServiceBindingManager

[Brian Stansberry]

Carlo de Wolf wrote:
> Brian Stansberry wrote:
>> David M. Lloyd wrote:
>>> On 04/23/2009 05:37 PM, Brian Stansberry wrote:
>>>> I think the binding interface for services that open sockets should 
>>>> be coming from the ServiceBindingManager, same as the ports do. 
>>>> Currently most services use ${jboss.bind.address} to inject the 
>>>> address directly into the consuming service. But that precludes a 
>>>> management tool using SBM as a central configuration point for all 
>>>> address/port usage in the server.[1] Currently it's mostly only 
>>>> useful for the ports; if admins wanted to use something other than 
>>>> ${jboss.bind.address} for a particular service they'd have to go 
>>>> elsewhere in the tool to configure that.
>>>>
>>>> Thoughts?
>>>
>>> Good idea.
>>>
>>> On this topic, it might be a Nice Thing to have a custom XML type for 
>>> service binding configuration, so rather than saying:
>>>
>>> <!-- Remote classloading service -->
>>> <bean class="org.jboss.services.binding.ServiceBindingMetadata">
>>>     <property name="serviceName">jboss:service=WebService</property>
>>>     <property name="port">8083</property>
>>> </bean>
>>>
>>> You could say:
>>>
>>> <declare-service-binding xmlns="urn:jboss:binding-manager:1.0">
>>>    <service name="jboss:service=WebService"/>
>>>    <bind address="${jboss.bind.address}" port="8083"/>
>>> </declare-service-binding>
>>>
>>> or whatever.  And instead of injecting the value with bean tags like 
>>> this:
>>>
>>> <value>
>>>     <value-factory bean="ServiceBindingManager" 
>>> method="getStringBinding">
>>>         <parameter>UnifiedInvokerConnector</parameter>
>>>         <parameter>${host}</parameter>
>>>     </value-factory>
>>> </value>
>>>
>>> you could have e.g.
>>>
>>> <string-binding-value xmlns="urn:jboss:binding-manager:1.0" 
>>> service-name="UnifiedInvokerConnector" input="${host}"/>
>>>
>>> Then if (and when) the class name/layout of the service binding data 
>>> changes (and judging from the differences between what's in 
>>> Branch_5_x and http://www.jboss.org/community/docs/DOC-9038 I'd say 
>>> we've already had a few such changes), then the same files will 
>>> continue to work.
>>>
>>> Basically, while using xmlns="urn:jboss:bean-deployer:2.0" can be 
>>> useful for users to assemble their applications and for certain 
>>> internal applications, we should not be using this as a configuration 
>>> file format since it exposes implementation details of the underlying 
>>> services, which then makes it tough for us to change said services.
>>>
>>
>> Good idea. https://jira.jboss.org/jira/browse/JBAS-6829
>>
>> Fortunately, the diffs between that design wiki page and the current 
>> stuff happened before 5.0.0.GA. But your point is well taken.
>>
> While we're at it. It would also be better if ServiceBindingManager is 
> not part of the VDF bootstrap.
> I want to get to a point where we can 'hide' the complete VDF bootstrap 
> and do everything in a post-boot Profile Service style.
> That way the service-binding.xml can theoretically go into deploy. 
> (It'll probable need to go into conf because it must be handled before 
> anything comes up.)

It's in bootstrap solely because it needs to come before 
conf/jboss-service.xml in Branch_5_x. It's a hack until we have the 
planned subprofile-based ProfileService in trunk.

> (Hmm, why don't we deploy all these conf files?)
> Or we could tell the Profile Service to do some 'to be named' directory 
> first.

The way I've seen Emanuel's future ProfileService prototypes working in 
trunk, the subprofiles that make up an overall profile are much more 
fine grained, representing individual capabilities, and are deployed in 
order. The whole conf/jboss-service.xml concept goes away. And 
ServiceBindingManager then becomes a subprofile that deploys early, 
outside of bootstrap.

> It would still leave one configuration item on which the Profile Service 
> itself will bind. But even that can be changed afterwards when 
> service-binding.xml is deployed if Profile Service is dynamic enough (or 
> multiple bindings).
> 

You're talking about remote connectivity to the ProfileService?  That 
already deploys late, via deploy/profileservice-jboss-beans.xml.

> Carlo
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development


-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com