JIRA

  • Log In Access more options
    • Online Help
    • GreenHopper Help
    • Agile Answers
    • Use Agile By Default
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What’s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Agile Access more options (Alt+g)
  • Create Issue
  • Mule
  • MULE-3495

Create ServiceBuilder similar to the EndpointBuilder

  • Agile Board
  • More Actions
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: Product Backlog
  • Component/s: Core: Configuration
  • Labels:
    None
  • User impact:
    Low
  • Affects Docs:
    Yes
  • Migration Impact:
    None
  • Similar Issues:
    None

Description

Endpoint builders are useful when we need to reference the same endpoint multiple times in the configuration and also simplify the code for dynamic creation of new endpoints at runtime. I would like to propose a ServiceBuilder, which is the extension of the same model to encompass services.

On the configuration level, the user would declare a service template outside of the <mule:model> and then refer the service template (possibly multiple times) inside the model. Looking up the service template from code would return a ServiceBuilder interface, which can be used for parameterizing and creating/looking up the appropriate service.

The service template can be either a separate tag (like <endpoint> vs <inbound-endpoint> and <outbound-endpoint>) or a wrapping tag, which would wrap a regular service tag. We need to provide some mechanism for parameterizing the services. I would suggest that we use the existing evaluators subsystem.

Here are examples for both proposed styles:

Overload the <service> tag
<?xml version="1.0" encoding="UTF-8"?>
<mule [...thousand and one namespace declarations]>

    <service name="MyHandler-Template">
	<inbound>
	    <inbound-endpoint address="jms://${template-parameter:CODE}-updates.topic"/>
	</inbound>
	<outbound>
	    <list-message-splitter-router>
		<outbound-endpoint ref="chatroom">
		    <transformers>
		    	<transformer class="com.mycompany.transformers.TickToMessage">
		    	   <property name="template">
		    	   Update for ${template-parameter:CODE}, 
		    	   price: ${xpath:/tick/last-px}
		    	   volume: ${xpath:/tick/acvol}
		    	   <property>
		    	</transformer>
		    </transformers>
		</<outbound-endpoint>
	    </list-message-splitter-router>
	</outbound>
    </service>

    <endpoint name="chatroom" address="xmpp://chatroom@jabber.mycompany.com:5222/"/>

    <model name="Pegi">
    
        <!-- Need to specify the name explicitly -->
        <service name="XMPP-Forwarder-6758" ref="MyHandler-Template">
            <parameter name="CODE" value="6758"/
        </service>
        <service name="Nintendo" ref="MyHandler-Template">
            <parameter name="CODE" value="7974"/
        </service>
    
    </model>
</mule>
Add a new <service-template> tag
<?xml version="1.0" encoding="UTF-8"?>
<mule [...thousand and one namespace declarations]>

    <service-template name="MyHandler-Template">
        <service name="XMPP-Forwarder-${template-parameter:CODE}">
		<inbound>
		    <inbound-endpoint address="jms://${template-parameter:CODE}-updates.topic"/>
		</inbound>
		<outbound>
		    <list-message-splitter-router>
			<outbound-endpoint ref="chatroom">
			    <transformers>
			    	<transformer class="com.mycompany.transformers.TickToMessage">
			    	   <property name="template">
			    	   Update for ${template-parameter:CODE}, 
			    	   price: ${xpath:/tick/last-px}
			    	   volume: ${xpath:/tick/acvol}
			    	   <property>
			    	</transformer>
			    </transformers>
			</<outbound-endpoint>
		    </list-message-splitter-router>
		</outbound>
        </service>
    <service-template>
    
    <endpoint name="chatroom" address="xmpp://chatroom@jabber.mycompany.com:5222/"/>

    <model name="Pegi">
    
        <!-- Name is defined in the template -->
        <service ref="MyHandler-Template">
            <parameter name="CODE" value="6758"/
        </service>

        <!-- Override the name defined in the template -->
        <service name="Nintendo" ref="MyHandler-Template">
            <parameter name="CODE" value="7974"/
        </service>
    
    </model>
</mule>

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
  • Transitions
  • Commits
  • Source
  • Builds
Hide
Permalink
Dirk Olmes added a comment - 30/Jun/08 03:11 AM

Implementing this means API and schema changes which is not going to happen before the next minor release.

Show
Dirk Olmes added a comment - 30/Jun/08 03:11 AM Implementing this means API and schema changes which is not going to happen before the next minor release.
Hide
Permalink
Ross Mason added a comment - 15/Nov/08 11:05 AM

This is an interesting concept. Can you tell me more about your use case? I am struggling to come up with a few real-world example where I'd want to duplicate a service configuration like this?

Show
Ross Mason added a comment - 15/Nov/08 11:05 AM This is an interesting concept. Can you tell me more about your use case? I am struggling to come up with a few real-world example where I'd want to duplicate a service configuration like this?
Hide
Permalink
Dimitar Dimitrov added a comment - 16/Nov/08 04:45 AM

Forgot to mention that the big win is when using service templates from the Java code (perhaps as one of the basis elements for a dynamic reconfiguration DSL).

The XML config in the issue's description was mostly for illustration, although such approach can be used to factor-out the frequently changing configuration parts in a separate files and have the templates (which should be much more stable) kept in Galaxy for example.

Show
Dimitar Dimitrov added a comment - 16/Nov/08 04:45 AM Forgot to mention that the big win is when using service templates from the Java code (perhaps as one of the basis elements for a dynamic reconfiguration DSL). The XML config in the issue's description was mostly for illustration, although such approach can be used to factor-out the frequently changing configuration parts in a separate files and have the templates (which should be much more stable) kept in Galaxy for example.

People

  • Assignee:
    Unassigned
    Reporter:
    Dimitar Dimitrov
Vote (2)
Watch (2)

Dates

  • Created:
    29/Jun/08 09:25 PM
    Updated:
    16/Nov/08 04:45 AM

Agile

  • View on Board
  • Atlassian JIRA (v5.0.7#734-sha1:8ad78a6)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for MuleForge. Try JIRA - bug tracking software for your team.