1 2 3 Previous Next 149 Replies Latest reply: Mar 24, 2010 8:55 AM by Andy Taylor RSS

Integration with AS6

Clebert Suconic Master

A bit of archeological history first:

 

There are several services on the application server that will need to create and destroy destinations within messaging services. (Talking in JMS terms, queues and topics).

 

Users also deploy destinations within their ZIP archives (EARs, WARS, SARs.... etc). In the past this was done by describing the MBean definition for the Queue or Topic.This has been a "tradition" since JBoss 3 with JBossMQ.

 

When I made the transition between JBoss MQ to JBoss Messaging, I changed all the tests to deploy/undeploy destinations within JBoss Messaging, immediately Adrian Brock complained that we would also like to test stuff with other Messaging providers.  So, I hate to say Adrian was right back then.. I wouldn't need to do anything now... :-)

 

 

The proposal:

 

There is a project called Messaging within AS6 that has a bunch of MC facades to JBoss Messaging 1.4.

 

My prooposal here is simple:

 

We get rid of all that, and make this Messaging project to be a SPI, where any service that needs to create a destination will talk to those beans instead.

 

 

I would do something like:

 

 

interface MessagingSPI

{

    createQueue(String name);

    createTopic(String name);

}

 

And have a MessageProviderBean defined within JBAS. Any request to create/destroy a queue should be made to that Bean.

 


I'm not sure if there are any security concerns for the application server. Like, how to apply security rules.. etc...  but I guess that's a concern for the application server guys. I would start with something simple now, and we expand later.

 

 

If that's not possible, I will provide something for the Testsuite only.

  • 1. Re: Integration with AS6
    Tim Fox Master

    Scope creep.

     

    Basically we just need to get the test suite to work with HornetQ.

     

    We just need to do something similar to what the TCK does. There's a simple interface for create/destroy queue that you implement for each provider, this allows the tck to deploy/undeploy the various queues it needs.

     

    This is just for getting the test suite to run. I'm not sure why we're talking about "other services" now.

     

    We have short timescales here. Let's keep it simple.

  • 2. Re: Integration with AS6
    Clebert Suconic Master

    it would be the same complexity over the testsuite or as a basic service. I'm planning something simple.

  • 3. Re: Integration with AS6
    Clebert Suconic Master
    If AS guys later want to expand more stuff... it would be up to them.
  • 4. Re: Integration with AS6
    Tim Fox Master

    It's when you talk about "other services" it worries me.

     

    Can you be more specific about what these "other services" are.

     

    I can't think of anything in JBoss AS currently that needs to create queues etc.

  • 5. Re: Integration with AS6
    Clebert Suconic Master

    I know about at least one case whiting EJB3.

     

    and a lot of users are accostumed to deploy destinations within their XMLs and zips. if we have a simple Bean like this, they could add MC annotations to their deployers.

  • 6. Re: Integration with AS6
    Tim Fox Master

    This is something that is currently supported with JBM in AS 5?

     

    If not then it's scope creep. We just need to get the test suite to run

  • 7. Re: Integration with AS6
    Clebert Suconic Master

    Yes... there is a method within EJB3 that can create a destination. ATM it's calling a method within JBM 1.4 (I don't remember where createTopic / createQueue are located within JBM 1.4 ATM, but it doesn't really matter now)

     

    And users can deploy destinations within their files.. all they need is to define a MBean.

     

    I'm not going to do anything complex though....  I will just do the same work as I would do on the testsuite. It will just be placed somewhere else instead.

  • 8. Re: Integration with AS6
    Brian Stansberry Master

    A few comments:

     

    First, for sure the AS needs to support users deploying queues/topics via some sort of descriptor file. If the schema for that descriptor doesn't expose HornetQ internals, all the better. I suspect that's the main thing Adrian was looking for.

     

    The way the AS handles such a descriptor is we create a type of deployer that parses the file and creates a metadata pojo (which would need to be written). The deployer attaches that metadata pojo to the DeploymentUnit (object representing the thing being deployed), DeploymentUnit gets passed down the chain of deployers. Another deployer sees that the DeploymentUnit has the metadata pojo attached, takes the metadata object and does what's necessary to install the queue/topic with the MC. (Perhaps invokes your SPI method, passing the metadata object instead of a String).

     

    How generic all that is depends on how generic the descriptor schema and metadata pojo is. If it includes everything a messaging server would need to know to create a queue/topic, then it's reusable

     

    Second, in 90% of the AS testsuite tests the test driver is a remote client. So you shouldn't expect to invoke a local API/SPI from the test itself. And you shouldn't plan on opening a remote interface to your SPI. The AS exposes a couple remote interfaces for deploying stuff, tests need to use those. There's the legacy MainDeployer API that most tests use (passes the URL of a test archive to the MainDeployer) and the newer ProfileService ManagementView/DeploymentManager API. The former is easier, but is based on deployment descriptors. Most tests though are going to involve deployment descriptors, if not for messaging then for other stuff used by the test, e.g. EJBs.

     

    Third, about the stuff in the AS source tree messaging module. Most of that allows the embedded console (and Jopr) to manage the messaging server and deployed queues/topics. It exposes the AS ProfileService's ManagedObject view of your beans. Tim, I was lacking in caffeine the other day when we chatted; Charles Crouch woke me up later. Managing this stuff via JMX is not adequate; JMX does not offer a proper persistence solution. If people change configuration options via the console, those changes need to be persisted so they still apply after server restart. That's what the ProfileService ManagedObject stuff allows. So, part of the integration task is we need to update that stuff.

  • 9. Re: Integration with AS6
    Clebert Suconic Master

    So from what I talked to AS guys today, the correct way to do things over AS6 is to provide deployers so users can create pretty XMLs instead of ugly MC Bean descriptors. That's the way AS guys want it integrated.

     

    Brian told me this is not so difficult to be done... so I will look into this on monday (maybe some time over the weekend also).

     

    It's a bit more than what I expected but I will at least take a look. If it becomes complex I will drop it and just go to the MC option at the moment and leave the deployer for later. I will keep this thread informed.

  • 10. Re: Integration with AS6
    Tim Fox Master

    [I can't work out how to reply to a message inline with these stupid new forums, so I've had to copy and paste manually]

     

    [Brian]

    few comments:

     

    First, for sure the AS needs to support users deploying queues/topics via some sort of descriptor file

    [/Brian]

     

    HornetQ already exposes all it's configuration data via configuration files

     

     

    [Brian]

    . If the schema for that descriptor doesn't expose HornetQ internals, all the better.

    [/Brian]

     

    That's a pipe dream. Every messaging system configures itself in a completely different way. Are you expecting some kind of grand unified messaging ontology that can be applied to all messaging systems? It will never happen.

     

    [Brian]

    I suspect that's the main thing Adrian was looking for.

    [/Brian]

     

    The original task here is to get the AS test suite to run, not some more ambitious plan of changing the way HornetQ deploys things. What should have been done is to abstract out deployment *for the test suite* through some kind of simple deploy/undeploy API - in a similar way how the Sun JMS TCK works.

     

    [Brian]

    The way the AS handles such a descriptor is we create a type of deployer that parses the file and creates a metadata pojo (which would need to be written). The deployer attaches that metadata pojo to the DeploymentUnit (object representing the thing being deployed), DeploymentUnit gets passed down the chain of deployers. Another deployer sees that the DeploymentUnit has the metadata pojo attached, takes the metadata object and does what's necessary to install the queue/topic with the MC. (Perhaps invokes your SPI method, passing the metadata object instead of a String).

    [/Brian]

     

    Not sure how relevant that is. Like I say, HornetQ does it's own deployment of configuration files.

     

    [Brian]

    How generic all that is depends on how generic the descriptor schema and metadata pojo is. If it includes everything a messaging server would need to know to create a queue/topic, then it's reusable

    [/Brian]

     

    Pipe dream again.Every messaging system will have a different set of attributes for queue/topics. For your grand ontology you'd just end up with an ugly superset of all the options in all the messaging systems.

     

    HornetQ inside JBoss AS is only one way HornetQ can be deployed. HornetQ can be used as a standalone server, it will be usable inside MRG and also inside JBoss AS. We already have quite a lot of users using HornetQ in AS 4 and AS5. This is done by them running a script against the app server to create some profiles and do some tweaking. Simple.

     

    In all these deployment scenarios HornetQ must be configured the same way - via the HornetQ configuration files. This must be consistent. We have people running standalone, or in AS4/5 and used to one way of configuration and then tell them they have to learn a completely different way of configuring it for AS6. If that's the case I'll just tell them not to bother and just run the script instead against AS 6.

     

    [Brian]

     

    Second, in 90% of the AS testsuite tests the test driver is a remote client. So you shouldn't expect to invoke a local API/SPI from the test itself. And you shouldn't plan on opening a remote interface to your SPI. The AS exposes a couple remote interfaces for deploying stuff, tests need to use those. There's the legacy MainDeployer API that most tests use (passes the URL of a test archive to the MainDeployer) and the newer ProfileService ManagementView/DeploymentManager API. The former is easier, but is based on deployment descriptors. Most tests though are going to involve deployment descriptors, if not for messaging then for other stuff used by the test, e.g. EJBs.

    [/Brian]

     

    We can just define a simple test suite specific API for deploying/undeploying. Similar to what Sun JMS TCK does. This would be part of the AS test suite.

     

    [Brian]

    Third, about the stuff in the AS source tree messaging module. Most of that allows the embedded console (and Jopr) to manage the messaging server and deployed queues/topics. It exposes the AS ProfileService's ManagedObject view of your beans. Tim, I was lacking in caffeine the other day when we chatted; Charles Crouch woke me up later. Managing this stuff via JMX is not adequate; JMX does not offer a proper persistence solution. If people change configuration options via the console, those changes need to be persisted so they still apply after server restart. That's what the ProfileService ManagedObject stuff allows. So, part of the integration task is we need to update that stuff.

    [/Brian]

     

    Any HornetQ settings that aren't currently persisted (they should all be), should be persisted in HornetQ. If they aren't we will fix that in HornetQ. We don't rely on the profile service for that persistence. We do it ourselves. As mentioned before, HornetQ can be run in many different confirgurations, embedded, standalone etc, not all of which have a profile service or MC, so we can't rely on that.

  • 11. Re: Integration with AS6
    Emanuel Muckenhuber Master
    Of course the actual deployment has to be handled by HornetQ.
  • 12. Re: Integration with AS6
    Emanuel Muckenhuber Master
    Of course the actual deployment has to be handled by HornetQ.

    The deployers basically are a pipeline for metadata processing. This means that the parsed configuration files (which you already seem to have) just run through different states where other deployers may or may not use or modify this metadata. Other components like torquebox provide a different configuration to create a queue for example. They would then just need to create the HornetQ specific configuration and attach it to the deployment. Also reastEasy is just taking the ejb3 metadata and creating a web meatdata if needed. In the end everything will end up in the responsible 'real' deployer, which handles the actual deployment like HornetQ for messaging, Jboss.Web for web and so on.

    Ultimately, what we want to have is a domain specific configuration file (which can be validated) instead of exposing too many implementation details. Taking ALRs example he sent to the core a while ago, it's:

    <mbean code="org.jboss.jms.server.destination.QueueService"
          name="jboss.messaging.destination:service=Queue,name=DLQ"
          xmbean-dd="xmdesc/Queue-xmbean.xml">
          <depends optional-attribute-name="ServerPeer">
                      jboss.messaging:service=ServerPeer
          </depends>
          <attribute name="JNDIName">queue/MyQueue</attribute>
          <depends>jboss.messaging:service=PostOffice</depends>
    </mbean>

    versus

    <queue name="queue/MyQueue">
      <depends name="someDependencyRealNameNotJMXObjectName" />
    </queue>

    From a user perspective it should not matter if you create a MBean, MC Bean or just call createQueue directly to do this. So how this real deployer looks in the end depends on what's needed. You maybe just want to create a MC Bean internally (attach BeanMetaData) calling HornetQ, so that others can easily inject/depend on a queue instead of doing that directly.

    I imagine that you cannot depend on other services to handle the persistence for HornetQ and that's not the point. The persistence done by ProfileService targets the metadata which runs through the deployers - so other deployers trying to process this metadata will have the updated information as well.

    Maybe you can point us to an example deployment which you use to deploy stuff in AS5? I'm basically just trying to outline some underlying concepts how things are working. MC is already integrated with ProfileService, so this might simplify that - although it would make sense to talk about ProfileService later, since what can be done depends on how the integration looks like in the end.
  • 13. Re: Integration with AS6
    Emanuel Muckenhuber Master
    oops, syntax hightlighting did not really work out
  • 14. Re: Integration with AS6
    Tim Fox Master

    ALR's example is not good.

     

    That queue MBean descriptor is from JBoss Messaging, not HornetQ.

     

    JBoss Messaging config is far more complex and verbose.

     

    It was a key design decision in HornetQ to simplify the configuration. We think we have a very clean and concise configuration without all the MBean crap we used to have with JBM.

     

    The last thing I want to do is create yet another set of configuration for a mythical "generic" messaging system. IMO this is a waste of time and will just confuse users.

1 2 3 Previous Next