[Design of JBoss Build System] - Build System Meeting Agenda Mar 01, 2007
by pgier
Progress Since Last Meeting
Created plugin to generate non-maven repository artifacts. The plugin is called jboss-deploy-maven-plugin
Tested the maven-wagon-webdav plugin - IT has started setting up a snapshot repository and we decided that the easiest way to upload artifacts is through webdav. The maven webdav plugin is still in beta, but it seems to work for what we need.
We started discussing some guidelines for uploading artifacts to the repositories. The wiki entries are JBossRepository and MavenRepository
Some progress was made on the JBossRetro maven plugin, but it still needs some more work.
Talked to IT about cvs to svn migration. They are working on it, and said that next week they should be able to start on the projects we requested (Serialization, repository.jboss.com, etc)
Issues to Discuss
Plan for mavenizing app server.
Any other issues to discuss?
Goals for next meeting
Finish jboss-retro plugin, and add configuration to parent pom.
Finish setting up the snapshot repository.
Set up cruise control for maven builds - this is dependent on the snapshot repository
Start creating maven builds for app server and projects that it depends on.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024291#4024291
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024291
17 years, 10 months
[Design of JBoss ESB] - Re: The message is important!
by mark.little＠jboss.com
Wow, this topic hasn't been active for over a year ;-)
"driedtoast" wrote : I do like the concept of breaking out the translation of the model from the model. In this approach you can start to imagine the bus taking on a whole service approach internally.
|
Yes, we've been saying from the start that we want to use SOA internally as well as externally to the ESB.
anonymous wrote :
| For example,
|
|
| Utility Services:
|
| - TRANSPORT - protocol that is used to connect to services
| - JMS
| - SMTP
| - TCP/IP
| - HTTP
| - JNDI/Local invocations
|
If you take a look at the original architectural requirements I think you'll see this concept in the dispatchers, which are services to all intents and purposes. They receive messages and then do something with them. That "something" may be to augment the message (e.g., add a security context), or it may be to send them to a transport level service for transmission between endpoints.
anonymous wrote :
| - FORMAT - format of the resulting or incoming information to the bus
| - XML
| - JSON
| - SOAP
| - etc...
|
Within the bus we have a normalized message format (actually we support a range and provide implementations of a couple). Other formats make sense when going outside of the ESB, or coming into the ESB, to/from ESB-unaware components. We call the facilitators of those kinds of interactions Gateways.
anonymous wrote :
| - ROUTE - Routing of a message based on content or location
|
Yes, we have a CBR service.
anonymous wrote :
| - CACHE - responds to messages that are flagged cacheable?
|
Yes, you could have a cache service through which all interactions for certain endpoints go, exactly like HTTP caches. You could even tie this into CBR.
anonymous wrote :
| Auditing and Monitoring Services:
|
| - NOTIFY - Notifications of the messages within the system
|
| - AUDITING - Storing the message
| - DB
| - LOG
| - Etc..
|
|
| Business Services:
|
| - Actions - Services that are put into the bus for business logic
|
|
| The whole thing could be tied together with a BPM strategy.
| For example,
|
| Transport -> Starts process XYZ
| Process starts to run
| XYZ -> FORMAT/TRANFORMATION to MODEL
| XYZ -> ROUTE
| XYZ -> CACHE
| NO CACHE: XYZ -> ACTION XYZ
| XYZ -> FORMAT
| XYZ -> TRANSPORT
|
|
| Or alternatively
|
| TRANSPORT - > XYZ
| XYZ -> FORMAT/TRANFORMATION to MODEL
| XYZ -> ROUTE
| XYZ -> FORMAT
| XYZ -> TRANSPORT (External service)
| XYZ -> AUDIT
| XYZ -> FORMAT
| XYZ -> TRANSPORT
|
And that's precisely what we're aiming for. We're looking at closer integration with the likes of jBPM or BPEL to drive this kind of flow.
anonymous wrote :
|
| The idea would be that when a message comes in, the process starts based on the message/service. The service really being a process.
|
| Thoughts?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024228#4024228
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024228
17 years, 10 months
[Design of JBoss ESB] - Virtual Registries?
by driedtoast
I have been looking at incorporating various frameworks into the ESB and it seems that the registry is only one per ESB (is this correct?).
It would be great if we could have a concept of a virtual registry to connect up to say microcontainer, spring, etc...
You configure the registry:
| <registry id="myregistryid" type="spring" location="/applicationContext.xml"/>
|
|
| <registry id="myregistryidB" type="uddi" location="http://localhost:9001/juddi"/>
|
Where the location can be url or classpath reference.
And the reference to services / actions:
| <action name="SpringBeanName" registryid="myregistryid" >
|
| </action>
|
|
The name would looks up in the spring application context for class or another frameworks component architecture like microcontainer.
If no registry id is found then it defaults to the default setting in the current configuration.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024225#4024225
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4024225
17 years, 10 months