[Design of JBoss ESB] - SOA Software integration document
by ScottDawson
This is regarding JBESB-2143 and the SOA Software-JBoss ESB integration document described in that JIRA entry. I read the document with interest because we have recently integrated JBoss ESB with the SOA Software registry (Service Manager) as described in the document (with good help from some JBoss employees, I should add).
I noticed one minor flaw in the document: in step 4 'Change the workflow...', the 'After' section of XML doesn't match the text description (or the way that we did it). I think it should look something like this, so that the function element and the step attribute are correct:
<action id="1" name="@create">
| <results>
| <unconditional-result old-status="Created" status="Draft" step="100" owner="${caller}"/>
| </results>
| <post-functions>
| <function type="publish" />
| </post-functions>
| </action>
|
I'm looking at the version of the document currently found here:http://anonsvn.jboss.org/repos/labs/labs/jbossesb/branches/JBESB_4_4...
In addition to the steps listed in the document, we found it necessary to upgrade to scout-1.0rc2.aop.jar but I don't think that will be necessary in releases subsequent to JBoss ESB 4.4.GA.
One additional thing we did was add a tModel for org.jboss.soa.esb.:category but I'm not sure if that is truly necessary.
Best regards,
Scott Dawson
Unisys
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207852#4207852
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207852
15 years, 4 months
[Design the new POJO MicroContainer] - Re: How to reliably determine if BeanMetaData contains depen
by kabir.khan＠jboss.com
With the following hacked KCC initialVisit() works here. I have only showed methods that I was forced to return something from to stop NPEs. The dependencies are picked out correctly now, and the failing tests pass, but it is horrible. I don't think I should need to create KCC's when reading the metadata?
| private boolean hasInjectedBeans(BeanMetaData beanMetaData)
| {
| DependencyBeanMetaDataVisitor visitor = new DependencyBeanMetaDataVisitor(beanMetaData);
|
| beanMetaData.initialVisit(visitor);
| return visitor.getHasDependencies();
| }
|
| private static class DependencyBeanMetaDataVisitor extends AbstractMetaDataVisitor
| {
| private boolean hasDependencies;
|
| protected DependencyBeanMetaDataVisitor(BeanMetaData bmd)
| {
| super(bmd, new DependencyMetaDataKernelControllerContext(bmd));
| }
|
| public boolean getHasDependencies()
| {
| return hasDependencies;
| }
|
| public void addDependency(DependencyItem dependency)
| {
| if (!((String)dependency.getIDependOn()).startsWith("jboss.kernel:service="))
| {
| //TODO revisit
| //Ignore the kernel dependencies
| hasDependencies = true;
| }
| }
| }
|
| private static class DependencyMetaDataKernelControllerContext extends JBossObject implements KernelControllerContext
| {
| private static final Kernel kernel = new Kernel();
| private BeanMetaData beanMetaData;
|
| public DependencyMetaDataKernelControllerContext(BeanMetaData beanMetaData)
| {
| this.beanMetaData = beanMetaData;
| }
|
| public BeanMetaData getBeanMetaData()
| {
| return beanMetaData;
| }
|
| public Kernel getKernel()
| {
| return kernel;
| }
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207809#4207809
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207809
15 years, 4 months
[Design of JBossCache] - Re: Evolution of TcpDelegatingCacheLoaders/TcpCacheServers
by manik.surtani＠jboss.com
Rebuilding the cache loader/cache server pair is definitely on the cards, and if you want to get involved you are more than welcome.
My goals for this redesign are:
1. Treat the TcpCacheServer (TCS) as a standalone module. I.e., it could be used directly, without the TcpCacheLoader (TCL).
2. The TCS would be able to "speak" 3 different protocols (and should detect which protocol is in use and select the appropriate handler).
3. These protocols are: Memcached ASCII protocol, Memcached binary protocol, as well as a custom designed binary protocol.
4. The first two would allow people to reuse existing Memcached client libraries with JBC.
5. The third one will allow us to encode additional information - such as cluster topology and failover information - when serving responses to clients that understand this.
6. The TCL would be one such client, speaking the jbc custom protocol.
7. Both the TCS and TCL would be heavily multithreaded, minimally synchronized, probably making use of Netty or Apache MINA as a layer over NIO sockets.
8. The TCL should support reconnects (this is already there, some of this code could be reused)
9. The TCL should support failover (responses from the TCS could contain piggybacked info on TCS cluster topology). TCL would then be able to fail over to alternate TCS instances.
10. TCL *may* even be able to support load balancing via pluggable LB policies.
Pretty big stuff. :)
I'm not so keen on consistent hashing on the client (TCL), since with plans I have for data partitioning (JBCACHE-60) this will end up on the server side anyway. The client can then be simpler, just selecting a server and handling failover, possibly load balancing, etc.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207803#4207803
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207803
15 years, 4 months
[Design the new POJO MicroContainer] - Re: How to reliably determine if BeanMetaData contains depen
by kabir.khan＠jboss.com
I have had a look at creating my own BeanMetaDataVisitor implementation for use in AspectBeanMetaDataFactory
| private boolean hasInjectedBeans(BeanMetaData beanMetaData)
| {
| DependencyBeanMetaDataVisitor visitor = new DependencyBeanMetaDataVisitor(beanMetaData);
|
| beanMetaData.describeVisit(visitor);
| beanMetaData.initialVisit(visitor);
|
| return beanMetaData.getHasDependencies();
| }
|
|
| private static class DependencyBeanMetaDataVisitor extends AbstractMetaDataVisitor
| {
| private boolean hasDependencies;
|
| protected DependencyBeanMetaDataVisitor(BeanMetaData bmd)
| {
| // FIXME DependencyBeanMetaDataVisitor constructor
| super(bmd, new DependencyKernelControllerContext(bmd));
| }
|
| public boolean getHasDependencies()
| {
| return hasDependencies;
| }
|
| public void addDependency(DependencyItem dependency)
| {
| hasDependencies = true;
| }
| }
|
But describeVisit() does not work due to the underlying value not being picked up in AbstractInjectionValueMetaData
| @SuppressWarnings("deprecation")
| public void describeVisit(MetaDataVisitor visitor)
| {
| // no bean and not by_name
| if (getUnderlyingValue() == null)
| {
| ...
| }
| super.describeVisit(visitor);
| }
|
installVisit() gives NPEs since we don't have a KernelControllerContext for the created bean at this stage. I tried mocking one, but so far that does not work since it needs a reference to the kernel etc., but I will try a bit more.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207790#4207790
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207790
15 years, 4 months
[Design of JBossCache] - Evolution of TcpDelegatingCacheLoaders/TcpCacheServers
by akluge
Hi,
I am currently investigating the incorporation of JBC into an existing, large, environment. In the near future, I expect to touch on many issues from JBCACHE-789 (Proxy), 1259 (HA), and possibly 1262 (Executor).
The use of JBC centers on the FarCaching pattern mentioned in the wiki, but with some additions. As a proof of concept, I have a cluster of TcpCacheServers, along with several stand alone caches, with a custom cache loader. The cache loader extends the AbstractCacheLoader to implement a distributed hash table. It contains several TcpDelegatingCacheLoaders, and delegates requests to the appropriate one as determined by a consistent hashing algorithm.
I am looking at a number of issues now, such as event notifications, failovers and recoveries, and generally improving the structure.
I thought it would be useful to touch base with whoever is active on these fronts on the JBC side, and hopefully some of what I do will be useful for a wider audience over time. If I know the JBC design goals, I might be able to work them in while addressing my own goals.
One of the first things I want to look at using reader and writer threads for the TcpDelegatingCacheLoaders and possibly the TcpCacheServers. My main desire here is to allow these classes to be easily extended to handle events. This leads to an immediate question: how sensitive should I be to backwards compatibility issues? I am quite tempted to rebuild this CacheServer/Cacheloader pair from the ground up.
Thanks for sharing your thoughts,
Alex
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207788#4207788
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207788
15 years, 4 months
[Design of JBoss jBPM] - Re: Concurrency in jBPM4
by tom.baeyens＠jboss.com
"roschmel" wrote : So in an ideal world you would exactly know where the process execution has crashed. This would mean committing every little step - but this is not really cool stuff.....
|
this is what we call a transactional script.
this is where jpdl is exactly suited for. see async="true". you can have the commit after every step.
"roschmel" wrote : So its first about knowing where the process have crashed - therefore you need logging information - just another topic I am currently discussing in the user forum.
|
no logging information is irrelevant. you need to map how you want java exceptions to affect the progress of your process.
for each potential failure of non transactional resources you need to decide : either the process continues or the process execution rolls back till the last committed point of execution.
"roschmel" wrote :
| And its about minimizing the chance, that a jBPM Transaction is getting rolled back. It is espacially about not considering a rollback as "a normal path of execution" - a rollback is for really bad things happended and not per design. So I think SOSE and retrying as a designed path of execution is simply wrong.
|
then i think you didn't get it yet.
"roschmel" wrote :
| What I would expect:
| If I have a process 1 waiting in state-A and waiting in state-B for the callback from an external system and both of them sending me the signal at the same time, I expect to have them executed just one after the other and I do not expect getting exception and letting the engine doing things twice.
|
this makes sense ! i didn't think if this use case yet.
should be really simple to get this one going. as we already have the exclusive job execution. that means that you can mark async messages or timers as being exclusive.
first, you have to make sure that all the progress in the process is made by the job executor. this would be possible to use the async command service. then you need to make sure that the async command service would set the exclusive flag to true.
then you need to make sure that all other jobs that are created in this process also set this exclusive flag to true.
good point!
we have all the infrastructure in place to make sure that we also cover this use case. i'll keep that in mind and hopefully this is fully documented by jbpm 4.0.0.GA
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207774#4207774
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207774
15 years, 4 months