[Design of JBoss ESB] - Re: Registry Service Design
by mark.little＠jboss.com
"kurt.stam(a)jboss.com" wrote : We will soon have an embeddedable JAXR/UDDI component using Apache Scout as the JAXR implementation, a local transport implementation to support local java calls, and a slightly modified jUDDI to support these direct java calls (and soon there after hopefully RMI calls too). OK so far so good. Now the ESB has access to any kind of XML registry (it'd be ebXML or UDDI), and by default it will use embedded jUDDI.
|
| Now what if other systems want to access this registry?
|
As long as the registry implementation is pluggable, then anyone who wants to replace our out-of-the-box implementation with their own will have to determine the best deployment configuration for themselves. This works fine as long as the interface we're using (JAX-R) does not expose any deployment/implementation choices: I assume it doesn't.
What I'm driving at is that as long as the interface is right, this is just another server and clients/services don't need to know (probably couldn't care) whether it is co-located or running in another address space.
So what you're asking below is really specific to our out-of-the-box deployment, true?
anonymous wrote :
| I see 3 scenarios of how you could do this:
| 1. If the registry is embedded, those systems can use JAXR and RMI (Scout with our RMI-Transport) to connect to the UDDI embedded in the JBossESB.
| 2. Those systems can call to their very own embedded jUDDI, which is configured to use the same database. Or use their own registry database with somekind of replication.
| 3. What if the client is not java based? Then you could deploy juddi.war and point it to the same registry database (or in jboss - versions newer then 4.0.2 you already have juddi build-in when running 'all'.). Now you have a soap webservice you can go to (for UDDI).
|
I think this covers the bases as far as the 4.0 GA is concerned: shared or independent deployments. We just need to make sure that we can support those configurations fairly easily as far as the user is concerned, i.e., "use this config for a single shared Registry Service, and this one for independent co-located Registry Service".
anonymous wrote :
| Do these scenarios seem right? Does it cover all real world needs? BTW I'm not talking about clustering and/or caching, we can worry about that later.
|
| We could take it to the next level and bring up a Registry Service in the JBossESB.
|
We definitely need to support that.
anonymous wrote :
| All clients can/should connect to this one and it can query to other registries in your business. If we do this, what kind of XML protocol should we support? Our own, or both UDDI and ebXML. Do we need something like this for the GA release?
|
| I'd love some feedback on this :).
|
| --Kurt
|
The default deployment for our Registry Service should be a single instance per ESB. That's the easiest for people to understand and manage. Once we go beyond the GA, we can add in caching, fault tolerance etc.
What do you mean by "what kind of XML protocol"?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973181#3973181
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973181
19 years, 6 months
[Design of JBoss Portal] - Re: Virtual hosts and multiple portal server instances
by thomas.heute＠jboss.com
"yxyang" wrote : (3)Navigation menu is urgly. Navigation portlet is so important that all deployments are needed.
| (4)User portlet is not fully implemented yet... Example, once you update the profile, not any indication appear on the page. Nobody knows whether the update success or not until you try it out by logout/login.
|
| <...>
|
| (2)i have my own generic nativation portlet. which itsown is a WAR DIRECTORY. You can enter the directory to modify the configurations anytime.
| (3)I will rewrite the user portlet myself in the next few days.
1 - this is out of topic, we try here to agree on the concept of multi-host and its implementation within portal
2 - How comes we didn't receive your contribution on the navigation portlet and when will you be done with the user portlet enhancement and providing us with a patch ?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973172#3973172
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973172
19 years, 6 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Incorporating Remoting http transport into Messaging
by ron_sigal
I'm starting this thread to discuss the integration of the JBossRemoting http transport into messaging. With some changes to Messaging code and some changes to Remoting code the test org.jboss.example.jms.http.HttpExample passes.
The Messaging changes revolve around JMSWireFormat:
1. JMSWireFormat can't expect to get passed ObjectInputStreams and ObjectOutputStreams. This has been discussed already, although I can't find the reference. I changed it to create object streams as necessary. However, when they are created, e.g.,
oos = SerializationStreamFactory.getManagerInstance("key").createOutput(out);
"key" has to be replaced by a suitable value. I assume it would be acceptable to just hard code "jboss", but the solution to problem 2) below involves passing in the server's InvokerLocator, so it's easy to do a quick check for any specific instructions about serialization. By the way, I see that in ServerPeer, the key "jms" is associated with jboss serialization, but I don't see any use of "jms" anywhere, so I commented that out. Since ServerPeer doesn't currently have access to the InvokerLocator, I also commented out the registration of a JMSWireFormat keyed on "jms".
2. JMS uses instances of SerializableMarshaller and SerializableUnMarshaller in some default cases. However, the http transport needs to use subclasses HTTPMarshaller and HTTPUnMarshaller, which means JMSWireFormat needs to know what transport is being used. An easy way to determine the transport would be to look at the InvokerLocator, but currently the InvokerLocator doesn't seem to be available everywhere it would be needed. Instances of JMSWireFormat are created in the following classes:
JMSRemotingConnection - no problem: it has the InvokerLocator
ClientConnectionFactoryDelegate - no problem: it already gets the InvokerLocator
ServerConnectionEndpoint - I changed the constructor so that ServerConnectionFactoryEndpoint can pass in the InvokerLocator
TestWireFormat - it calls the JMSWireFormat default constructor, which defaults to the socket transport and jboss serialization
It was also necessary to change the ServerConnectionFactoryEndpoint constructor to pass in the InvokerLocator, so it could pass it to ServerConnectionEndpoint.
3. A third change was necessary in JMSWireFormat, due to the way the server side http invoker (CoyoteInvoker) returns invocation results. In particular, since it doesn't know if it's talking to the client side http invoker or some other foreign client, it can't necessarily return the result wrapped in an InvocationResponse. We made some changes to the http transport so that the client side can tell the server side that it's a remoting invoker, but that involves putting a flag in the InvocationRequest. Since JMSWireFormat doesn't wrap messaging messages in an InvocationRequest, the changes don't help JMSWireFormat in general (though it solves a problem with null responses from internal Remoting requests). So, I changed the decision tree in JMSWireFormat.write() to accept arbitrary objects.
4. The http transport needs tomcat jars.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973170#3973170
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973170
19 years, 6 months
[Design of POJO Server] - Incomplete Deployment Exception
by adrian＠jboss.org
I've implemented the incomplete deployment exception,
example output:
| 2006-09-21 05:53:55,398 ERROR [org.jboss.system.server.profileservice.ProfileServiceBootstrap] Failed to load profile: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS):
|
| *** DEPLOYMENTS MISSING DEPLOYERS: Name
|
| file:/home/ejort/mc-vdf-work/build/output/jboss-5.0.0.Beta/server/default/deploy/bsh-deployer.xml
| file:/home/ejort/mc-vdf-work/build/output/jboss-5.0.0.Beta/server/default/deploy/ear-deployer.xml
| file:/home/ejort/mc-vdf-work/build/output/jboss-5.0.0.Beta/server/default/deploy/ejb-deployer.xml
| file:/home/ejort/mc-vdf-work/build/output/jboss-5.0.0.Beta/server/default/deploy/ejb3-interceptors-aop.xml
| file:/home/ejort/mc-vdf-work/build/output/jboss-5.0.0.Beta/server/default/deploy/http-invoker.sar/invoker.war/
| file:/home/ejort/mc-vdf-work/build/output/jboss-5.0.0.Beta/server/default/deploy/jbossweb-tomcat6.sar/ROOT.war/
| file:/home/ejort/mc-vdf-work/build/output/jboss-5.0.0.Beta/server/default/deploy/jms/jbossmq-httpil.sar/jbossmq-httpil.war/
| file:/home/ejort/mc-vdf-work/build/output/jboss-5.0.0.Beta/server/default/deploy/jmx-console.war/
| file:/home/ejort/mc-vdf-work/build/output/jboss-5.0.0.Beta/server/default/deploy/management/console-mgr.sar/web-console.war/
|
| *** CONTEXTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
|
| jboss.ejb3:service=EJB3Deployer
| -> jboss.ejb:service=EJBDeployer{Start:** NOT FOUND **}
| -> jboss.ejb:service=EJBDeployer{Create:** NOT FOUND **}
|
|
| *** CONTEXTS IN ERROR: Name -> Error
|
| jboss.ejb:service=EJBDeployer -> ** NOT FOUND **
|
This brought up the issue that we need a way
to identify what deployments we expect only to provide classloading.
For now, I'm excluding .jar files with a HACK.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973149#3973149
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973149
19 years, 6 months
[Design of JBoss Portal] - Re: Virtual hosts and multiple portal server instances
by yxyang
"sverker" wrote :
| I've come to the conclusion that it is simply not supported by JBoss Portal architecture to have it serving multiple virtual hosts, nor to run multiple instances of the portal server itself.
|
| While running multiple instances of the portal server maybe isn't that high priority (isn't required by my applications at least), the ability to support virtual hosts is.
|
JBoss portal does have a few limitations:
(1)default portal should be there as an example.
(2)Virtual host not supported.
(3)Navigation menu is urgly. Navigation portlet is so important that all deployments are needed.
(4)User portlet is not fully implemented yet... Example, once you update the profile, not any indication appear on the page. Nobody knows whether the update success or not until you try it out by logout/login.
But you can acheive the virtual host features or running multiple portal instance easily.
(1)I have running semi-virtual hosting on jboss. What i used to solve the problem is using "http redirect".
(2)i have my own generic nativation portlet. which itsown is a WAR DIRECTORY. You can enter the directory to modify the configurations anytime.
(3)I will rewrite the user portlet myself in the next few days.
yang
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973132#3973132
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973132
19 years, 6 months
[Design of JBoss jBPM] - Fault handling in BPEL
by alex.guizar＠jboss.com
Fault handling is basically running an alternate activity when a fault is detected in the main activity of the process or one of its nested scopes. While the principle is simple, the ability to perform an arbitrary activity in response to a fault makes handling it a multi-step, long duration procedure which must be tracked and logged.
Things get even better. The reaction to a fault varies according to the state of the scope where the fault is thrown. What if a fault occurs when another fault is being handled already? The following picture from the BPEL spec explains the state changes:
Transition exited is taken when the fault handler completes, whereas faulted is taken when the handler fails. In the latter case the fault is rethrown to the enclosing scope.
The package org.jbpm.bpel.exe.state implements the above state diagram. The design follows the state pattern.
Class ScopeState plays the State role. Other classes in the same package represent the concrete states. Note that TerminatingState corresponds to the Canceling state above. The rename follows a terminology change between BPEL4WS 1.1 and WS-BPEL 2.0. The Context corresponds to ScopeInstance. When a fault occurs, method faulted is invoked on the scopeInstance, passing the available fault details. This method delegates to its peer in ScopeState for state-dependent behavior.
JIRA issue BPEL-9: fault and termination handling is currently on my plate. What is left to do is fill in the blanks in transition methods and make sure everything works according to the spec. I'd like to mention that the existing foundation was laid by Juan Carlos Cantu, a good friend of mine and a former member of the jBPM team.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3973123#3973123
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3973123
19 years, 6 months