[Design of JBoss Remoting, Unified Invokers] - Re: Remoting 3: Decision time...
by trustin
The following is the log of the chat David and I had on Monday.
trustin: Yes, but I didn't have a chance to reply yet.
trustin: I think the road map you mentioned there is pretty much same to what we've discussed so far.
trustin: The question would probably be .. 'is it ready to go CR?'
dmlloyd: probably not without more tests
dmlloyd: featurewise, yes
trustin: I think we can go CR first and write tests to cover the code and stablize it.
trustin: as long as it is stable featurewise
dmlloyd: it is, unless someone can think of anything I missed
trustin: I never think you missed something. :)
trustin: I think there are potential audiences for 3.0 anyway
trustin: It can be configured without JBossMC and we could provide a simple bootstrapper so that one can run it standalone quickly.
trustin: then we can attract users who want to use a flexible remoting layer for their application first and then try JBossMC integration if nice tutorial is provided.
dmlloyd: I have examples of how to configure it manually
dmlloyd: not many examples, but I do have examples :)
trustin: Yes. What I meant was a very simple 1-3 liner helper to attract people ;)
trustin: such a helper could cover most simple 'default' setup and some additional parameters that about 80% (?) users will need.
dmlloyd: the tricky part is that there is no standard protocol yet
dmlloyd: the multiplex handler is raw - no security
dmlloyd: things like classloading have been put off
trustin: Could we make the helper extensible so that a user can choose a transport and specify parameters dynamically (with reasonable default values)?
dmlloyd: sure, but I'm just saying that there really aren't any reasonable default values yet
trustin: the basic protocol? and we could change the default in 3.1 as soon as the SSH-based one is ready?
dmlloyd: I don't want people to use the basic protocol in production though. It mainly exists so that there's a model for other protocol implementations to follow
dmlloyd: basic protocol uses a connection per client rather than maintaining a connection independently of services and clients
trustin: hmm then who would be a target audience?
dmlloyd: people who want to use the API to begin defining services, I guess
dmlloyd: and clients
dmlloyd: while deferring connection implementation details
dmlloyd: the framework is designed to be used in an IoC environment and it shows, I think
trustin: but you don't want them to use the basic protocol in production - I'm confused.
dmlloyd: right, in production people should be using the multiplex protocol with some kind of security layer
dmlloyd: the thing is, all the features that would make R3 useful have been deferred to 3.1 or later
trustin: then the target audience for 3.0 would be limited to someone who is in the course of developing a service and will be in production after we release 3.1?
dmlloyd: yes, that was my conclusion
trustin: We have built R3 on top of flexible marshalling layer and XNIO-based scalable networking layer, so I think it will attract some people who wants to use it in a private network only? We could add SSL support for the basic protocol (via XNIO) in 3.0 though.
trustin: I might be missing something but from my understanding, current R3 has more features than plain RMI or other related technologies except for R2.
dmlloyd: well, it has more potential features anyway :)
dmlloyd: it's the most pluggable framework out there
dmlloyd: XNIO doesn't have SSL support currently
trustin: dmlloyd: Let's steal some from Netty
trustin: Shall I implement one? ;)
trustin: I actually think SSL is not even necessary to attract users with 3.0.
dmlloyd: I suppose what we need is a user guide
trustin: we could focus on SSH instead of SSL to save some time (not much)
dmlloyd: yeah, SSH will be a big priority
trustin: Yes. We need it otherwise going GA wouldn't help us attract people IMHO.
dmlloyd: maybe we could just live with not attracting many people with 3.0 :)
trustin: :)
dmlloyd: as far as SSL goes - I did not yet implement it because I wanted to be sure that the API is correct
dmlloyd: and there's a lot to know about how SSL can be used before being able to say that definitively
trustin: How SSL can be used?
dmlloyd: yes
trustin: to assure confidentiality of communication?
dmlloyd: special cases, unusual usage patterns etc.
trustin: from XNIO standpoint?
dmlloyd: yes
trustin: Ah I see.
dmlloyd: I want the API to be as simple as possible
trustin: We are talking about 3~4 projects when we talk about R3 :D
dmlloyd: yes :)
dmlloyd: if SSL support appeared in XNIO, R3 would be able to use it immediately
trustin: Yes, with no sweat :)
dmlloyd: but for streaming over a single channel I think we will need full SSH support, since it gives the ability to open independent channels
dmlloyd: though I could enhance the multiplex protocol to support independent channels as well
trustin: Agreed.
trustin: I guess the conversation so far seems to answer your questions in the forum pretty enough. Did we miss something?
dmlloyd: how shall we promote it
dmlloyd: I suppose that in the announcement I should make it clear what it can and cannot do
trustin: You mean promoting to JBoss.org developers or users?
dmlloyd: and explain that the target audience are those who want to start developing applications and services in anticipation of 3.1 and 3.2
dmlloyd: they're one and the same from my perspective :)
trustin: ah OK. :)
trustin: I like the idea about the announcement which shows the road map.
trustin: I think the road map should be shown in the front page of our project home page, too.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4198393#4198393
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4198393
15 years, 4 months
[Design of JBoss ESB] - Re: StartProcessInstanceCommand: Return token id/process ins
by camunda
Hi Burr.
burrsutter wrote : Do you also find the need for synchronous processing within jBPM? Where the calling thread should be blocked as each node (assumes no wait-states) is executed and control is returned to the calling thread when the process instance is completed?
|
I see this being a main advantage of jBPM over other architectures. It makes it easily usable in a lot of different scenarios, like even 2-tier architectures or Seam Pageflow. Since you can easily change the behaviour to use JMS to decouple it from the client thread (something I think the most process engines do) by just adding a "async=true" flag, I don't see any downside of it.
If you want to get rid of the async flag you could even introduce a global configuration property in jbpm to change the default, should be a too big problem.
Despite the value for different use cases of jbpm I think "borrowing the client thread" has the big advantage, that java developers can easily understand what is going on. And it is easy to write Unit-Tests (since you do exactly know what happened after a call returns). So actually I am a big fan of it! And I know quite some projects or developers who are on my side I think :-) I think, this is one of the unique selling points of jbpm. Don't make it as unnecessary complex as other big unhandy process engines (unless there is a very good reason to ;-)).
Hence, the interessting question is, with the async flag in place, why should it be changed? What would be the advantage of it?
Cheers
Bernd
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4198375#4198375
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4198375
15 years, 4 months