JSF Central - Ivankovits and Kitching's Orchestra: Conversations, JPA, and more
JSF Central

 
 Home 
 
 Products 
 
 Articles & Books 
 
 Resources 
Community Chat
 
Ivankovits and Kitching's Orchestra: Conversations, JPA, and more
by Kito Mann
16 Feb 2009 00:10 CDT

In this podcast JSFCentral editor-in-chief Kito D. Mann interviews Mario Ivankovits and Simon Kitching. Mario is a senior developer for OPS EDV in Austria. He is the founder of the Apache MyFaces Orchestra project, which has proven its stability and robustness in production in the web applications developed by his company. Simon also works at OPS and is one of the most active contributors to the MyFaces Orchestra project.


Podcast (MP3)
Welcome to the JSFCentral podcast #11 for the week of February 17, 2009. This series of podcasts features interviews, news, and commentary for those working with JavaServer Faces technology. In this podcast JSFCentral editor-in-chief Kito D. Mann interviews Mario Ivankovits and Simon Kitching. Mario is a senior developer for OPS EDV in Austria. He is the founder of the Apache MyFaces Orchestra project, which has proven its stability and robustness in production in the web applications developed by his company. Simon also works at OPS and is one of the most active contributors to the MyFaces Orchestra project. This was recorded in March of 2008 at JSFDays in Vienna, Austria.
Kito I am here at JSFDays 2008 in Vienna, Austria, with a couple people who are working on a fairly new project from Apache MyFaces. Why don't you guys say your name and say what you do for a living. Then we will talk about the actual product itself.
Mario Hi Kito. My name is Mario Ivankovits and I work for a software company in Austria doing a lot of web application development.
Simon My name is Simon Kitching, I have been a Java developer for quite a few years now. I have just recently moved to Vienna and ended up working with Mario. He had this great new idea and I have been really lucky to work with him on it.
Kito Okay, so this new idea is something called MyFaces Orchestra, which is one of the newer additions to the ever growing group of MyFaces sub-projects. Tell us a little bit about what Orchestra is.
Mario Orchestra tries to be a solution for helping people working with, let's say wizard-like page flows and persistence and stuff like that. As a Tomahawk developer, where I came from -- from MyFaces -- we were very centric to create tags for everything, so we started with a conversation tag; so like ,you will have tag and that is where you will add your beans and things like this.

When we were sitting together reviewing what I did, the others looked at me a little bit strange and said "it's too complicated. Let's make something different. Let's make something which is as easy as an HTTP session." So the idea was born to create a custom scope, and since JSF is not extensible in this area, we researched what matches best and so we came to Spring. Then the Apache MyFaces Fusion project was born, but Fusion was not accepted by the community and so it is Orchestra now.

Kito So why wasn't Fusion accepted?
Mario You probably know there is a friendly company called Oracle which also has a Fusion project, which also is oriented in some JSF functionalities. I am not exactly sure what it does, but it was enough to make them happy if we didn't call ours Fusion, but Orchestra.
Kito I think what Mario is leaving out is the fact that lots of Oracle people are involved with MyFaces and Trinidad and everything.
Simon We like to keep them happy. They do a lot of good work.
Kito Yes indeed. So you are saying basically that Orchestra allows you to add a new scope to your JSF applications, and in order to do that you are using Spring. There is a little more to it than just the scope, right? Just to take a step back, explain what exactly a conversation scope is.
Simon Alright, there are the standard scopes that have come with servlets for ages. There's the application scope - not really much use at all. There is the request scope which is very useful, and then there is the session scope. I think as soon as you have been programming with complicated applications for a while, you realize that you are using session scope all the time. After a while the memory builds up and builds up and builds up, because the problem is it's hard to get things out of session scope once you have used them. The idea of a conversation scope is that when you are working in one part of the application, you group all the beans that you need together in that conversation. When the user leaves that part of the application you can throw the whole lot away together. That is basically the idea of a conversation scope. It is also grouped with a kind of a use case of a wizard. Again a wizard is a set of pages you work through where you have a bunch of beans and objects in the background and when you are finished with it, you can throw the lot away. So the user experience and the beans you need to support that user experience are really the same thing. A conversation is used both to describe the page flow, or people use this term to describe a page flow and we also use it to describe a group of beans.
Kito Right. And another side effect of this is that if you have a couple different browser windows, this is one of the things that Orchestra does, right?
Mario There's support for multiple browser windows, but to be fair I have to say we also have no solution if the user opens a browser window with a right mouse click, and opens a new window, and true, there is no chance to hook into this. But there is an ongoing effort to avoid this, to prohibit the user from opening a new window this way. But you can provide links which open a new window, which then you have the same session but it works in a completely different, we call it conversation context, where you can have the same conversations as in the other window let's say, but with completely separated data.
Simon This is the other side of the problem with the HTTP sessions, is that somebody can open three or four tabs or three or four browser windows, and they are still using the same HTTP session. So if you have a bean in the session and you manipulate it in one window and you manipulate it in the other window, things get really confused at the back end.

The data is colliding. So as Mario said, if you group things into conversations then you can have one lot of beans associated with one window and one lot of beans associated with a different window, even though they are the same classes. There is the bean A that we have one instance, and somewhere else you have a different interest of the same managed bean. The two don't collide. The trick is -- as Mario said -- is to actually figure out which window belongs to which group of beans. There are some tricks you can use, particularly cooperating with the user so to allow this, but there are still some cases where the user can make it completely impossible for the back end to track. And there is no solution that we can think of at the moment for that.

Kito Alright, so we know that Orchestra helps with conversations. What else can you do with Orchestra?
Mario I would say one of the things of Orchestra is that it concentrates on solving one problem. It does not have a big impact into applications by providing thousands of features. Probably one thing I would like to mention is the navigation handler we have, which allows you to add parameters to the URL, making them bookmarkable - at least one half. So you have a navigation rule which then has a URL parameter fetch from an EL expression, from your backing bean. For sure you have to use the FacesContextto read this value in the next step but at least the first half is done. We will see what JSF 2.0 or something like this brings in the future.
Simon That was really a feature that we added in order to support these multiple window beans, and it turns out to be a useful feature for other purposes as well. But the biggest thing - Mario perhaps will talk more about this - is to be able to attach a persistence context to one of these conversations that we have. Mario?
Mario This is where we also heavily use the Spring framework. Basically it is that we synchronize the persistence context of the persistence layer with the lifetime of the conversation. Conversation lifetime can be handled by using our API or we have two different conversation scopes at the moment. By synchronizing this thing, it allows us to get rid of the lazy initialization exceptions and it also works better with optimistic locking.
Kito So basically you get rid of the lazy initialization exceptions. For the few people who haven't actually seen this exception, why would you get it?
Mario You get it if you fetch an entity from the database which has a one-to-many relationship in there. You often have to configure this, being a lazy relationship and not an eager one. The database just provides--in case of the full list of entities it is associated to, you get just the proxy. Then you pass this entity to the user interface layer where a data table, for example, tries to print out the entities of the association. And then the persistence layer must fetch this data, and normally the persistence context is already closed, so it is not possible to fetch the state on the user interface tier. Orchestra provides a bridge between these two layers.
Kito Okay, and what sort of persistence layers can you use with Orchestra?
Mario Virtually any JPA persistence layer but you can also use plain Hibernate -- we provide an adapter for this. I would say you can probably use virtually any persistence layer, as we have created Orchestra's code base very modular, so you can literally replace everything you would like to. You can have your own scopes, you can have your own persistence layers, you can have - probably it should be able to run in another outside of a servlet engine. So you have the framework adapter which then tries to make the bridge from a user environment to Orchestra. We already have on the mailing list a guy who wanted to use Orchestra to execute his (batch jobs.
Kito Oh really?
Simon That's a new one for me.
Mario Also in this case, just provide a local framework adapter which just stores the information Orchestra needs on the local map, and you are done for using Orchestra in desk frameworks without any servlet container.
Simon I should say that it has got the different layers. It has the plain old conversations where you can store objects. Then you've got being able to restore persistent entities, which you have loaded from the database into our conversation. This has a lot of very useful things, such as the fact that your UI can anytime walk through the object and display stuff, and not worry about the fact that your persistence context is gone and you can't navigate relationships from this object anymore. That is, of course, assuming that your presentation layer has got access to the database. You can't have a presentation context unless you have got direct access to the database. If you have a security-sensitive application you are typically going to use the full EJB stack. You are going to have a database way, way back down the backend somewhere, very secured. You are going to have an EJB server that has your business methods that talk to the database. You are then going to have a web tier that only talks to the business services and cannot talk to the database.

In this setup your business service are building an object that is going to be serialized and passed back to the presentation layer for use. In that case - it's a common trap -- your business service returns an object that has a whole bunch of lazy initialized fields that haven't been initialized. Then you try and navigate them on the UI and they are simply not there. That's a problem. Orchestra can't help with that particular problem, again because your UI doesn't have access to the database. You just have to suffer the pain -- a bit more work to get that secure. For a whole lot of applications you don't really want to go to that length. You want to do something simple. Typically your presentation layer does have the persistent stuff in the same layer, and you have got access to the database. In that case, by attaching a persistence context to an Orchestra conversation and having it live across a dozen or two dozen requests, you can not worry about these uninitialized relations. If the UI ends up on a page where it needs that data, it calls the methods on your persistent objects, and they then use the persistence context to fetch the data at that time. That's where you would get a lazy initialization exception if you weren't using extended context associated with a conversation scope, and that - for that whole class of application at least - is no longer a problem.

Kito Right and by using Orchestra you don't have to worry about--let's say the Spring open session and view filter and all that kind of stuff. You can have Orchestra manage all that stuff for you. So let's say I had a JSF application and I was moving along and I said "I really want all these great features in Orchestra," what do I have to do? How do I integrate Orchestra into my application?
Mario Basically you download Orchestra from the Apache MyFaces homepage or use Maven to fetch it. You have to use Spring. You have to do a little bit of setup, but it's well documented.
Simon The first step is just copying and pasting stuff out of the configuration files to set up Orchestra itself. Then you have to move your managed bean definitions out of your Faces config and into the Spring configuration file, because Orchestra simply cannot add hooks to stuff that's in the managed bean definitions in JSF. It's not extensible enough. Once you have done that, you just annotate every one of your managed beans with the appropriate conversation that you want it to be in. .
Mario Or you use the Spring XML configuration.
Kito Okay so you can do either-or.
Mario There's no need to use annotations, we also are compatible to Java 1.4 so we are not relying on annotations. Then you have to put the beans in the Spring configuration to the appropriate scope -- in one of Orchestra's conversation scopes. I think the hardest part probably - but it's not Orchestra related, but it's about this topic - is to find the conversations in this application, and to say how big should the conversation be, or how small is it, how fine grained it should be. So this is something you have to learn, but you have to learn with every possible conversation implementation, and there isn't one that would help you here.
Simon The nice thing is that's a progressive process you can go through. Even simply putting all of your session beans into a single conversation scope that lives forever is already of great benefit. That allows you to support multiple windows for a start, because you have then got all of these beans that used to be session except they are grouped per window. You can then go through and slowly, one-by-one or group-by-group, move these from a global, from an application wide conversation into more focused conversations so that the beans get thrown away earlier. Over time you can slowly improve the memory usage of your application just by discovering these conversations or working to actually reveal them.
Kito You guys had said there were a couple of different conversation scopes, can you talk a little bit more about that?
Mario Basically we provide two conversation scopes out of the box. One is a manual conversation scope, which has a configurable timeout so you have to end the conversation using the API or wait for the timeout. You can disable this timeout, or there is what we call now an access scope, so as long as you access one of the beans, the conversation stays alive. As soon as the request has no access to beans, the conversation goes away.
Kito So, what if that request accesses a bean outside of that conversation? Would it go away in that case?
Mario You have to define which beans go into a conversation. There is not much magic for adding beans automatically in a conversation, so you have to do it in the Spring configuration. There is a special Orchestra extension for Spring which allows it to define a conversation name. If you do not use a conversation name then only this one bean can be in the conversation. The conversation then has to have the bean name. Or you configure multiple beans with the same conversation name so then you can have, for example, the wizard: page one, page two, page three. Every page has its own bean for some reason, probably to split the logic of the various pages also into the various beans, to have it a little bit cleaner. But all beans live in the same conversation so they can exchange entities without any problem and all the beans stay alive for the whole page flow.
Kito Exactly.
Simon A very controversial one. Mario and I have talked about this many times.
Mario I think he means the real view controller, not this controller.
Simon The view controller, yeah. There has been a - I think it's called a view controller -- in the Apache Shale project for a long, long while. I am sure the idea was not new then. It's simply the chance to get call backs about the JSF lifecycle, "Hey, we are about to render this page." "Hey, we are about to store some data that the user has submitted into your backing beans." Those sorts of things. There are a couple of features you need when you are really dealing with conversations and we needed a view controller of some sort in order to enable those things in Orchestra. Ideally, well it was my point of view that we simply reuse the Shale one, or somebody else's one, but unfortunately it was missing a couple of hooks and there is not a lot of development going on in Shale, so Orchestra has borrowed the best ideas from it and added a few more configurability features, and now has its own. It's not a core, core concept of Orchestra. The core concepts are conversations, persistence associated with conversations. But it is needed to support a couple of the use cases that you would also use conversations for. So Orchestra provides its own as well. That doesn't mean you can't mix and match. You could have the Shale one in your application as well, I am sure.
Kito Okay, so another product out there that does conversation management and persistence context is JBoss Seam. How does Orchestra relate to Seam?
Mario Seam introduced the conversation scope, in reality. I think it was the first one that had this.
Kito The first one I think that at least made it a popular concept.
Mario Yeah, and very direct. I didn't manage to get in touch with how the conversation definition and flow works, so I think probably I should have spent more time in looking into the documentation and one week or two to get into the concept.
Simon The problem is that Seam is such a big thing to take on, isn't it? The moment you download it, there is a lot of information to take on there. It is not immediately clear what it does or how it is used. There are a lot of better books available now, and maybe we should again have a second look. But Orchestra is a much smaller tighter-focused project. Probably a reasonable amount of overlap in the functionality, but Orchestra does just conversations and just persistence associated with conversations. And that's it: you can read the documentation in 20 minutes, you can probably be pretty comfortable with 100% of the feature set in an hour.
Mario Especially if you already use Spring, you already know the concepts -- how to use with persistence -- and by plugging in Orchestra, you don't have to change your code. I think one of the key benefits of Orchestra is - especially with already built applications -- that you can start using it at some point in time and not have to build your application again.
Kito Right, so it tends to work very well in projects where you already have the application, and you say "okay now I am going to add some conversations," and you can just add Orchestra.
Mario It helps you to modernize your application without throwing away the work you have already done. I think that's the point.
Kito Okay, so, I know Spring Web Flow also does dialogue management, and also has sort of a dialogue type scope, and also has JSF integration to some degree. How do you see Orchestra in the Spring ecosystem, looking at Spring Web Flow 2.0 -- the new one that is coming out --and also Spring 2.5 and those types of products?
Simon The thing about the Spring Web Flow one is that it requires you to define your navigation flows in its own state engine format. That's obviously very powerful. It's very clear where your pages are flowing and how and why. It then uses that to drive the conversation stuff. It knows when to create a group of beans and when to destroy them, because you have defined that information with the state engine and because every navigation goes through the state engine - at least that's my understanding from reading the page. The problem with that, of course, is that you have to buy into their state engine concept. If you want to use standard JSF navigation, you simply cannot use Spring Web Flow conversations. I am not saying anything negative about the Spring Web Flow approach, it's just a more -- it's a package. You buy into both.

Orchestra again can add conversations without adding much else in the way of imposition on your application. In terms of Spring itself, Orchestra really isn't highly dependent on Spring. What Orchestra needs is a dependency injection framework that allows us to plug in an extra scope. Spring is a damn good framework and it allows us to do this, but theoretically Google Guice, PicoContainer, NanoContainer, whatever you want would probably also work fine. We have got it structured so it can do other things but haven't bothered because Spring works for us.

Mario I also had a request to make Orchestra work with another dependency injection framework. It is practical again, and the only thing is if you use the persistence synchronization, then the dependency injection framework or some other library has to provide some hooks. But you can use Orchestra without any persistence, so it is fairly easy to use something else than Spring.
Kito Okay, alright, well I think that is about all the questions I have off the top of my head. Anything else you want to add about Orchestra, about JSFDays, MyFaces. Anything else?
Mario Yeah, I am happy to be in this community. We've had very fine sweet days in JSFDays here, and I can say: use Orchestra!
Simon Yeah, or even better, come along and contribute to Orchestra.
Kito There you go.
Simon It's not a huge code base, so if you are interested in this area see if it works for you. If it doesn't quite work for you...
Mario come to the mail list, we will help you.
Simon Exactly.
Kito I must admit, you guys have been very good about fixing bugs and stuff when they come up. I have definitely seen a lot of activity there, which is cool.
Simon Yeah we have had a couple of people, for example, saying "hey we would like to use that in a portlet."
Kito Exactly
Simon We don't use portlets but that is fine. It has our attention now, hopefully.
Mario Martin Marinschek helped us a little bit with getting to the bottom of things.
Kito I noticed he had it in a demo earlier today so something must be working. Alright, well thank you, Simon and Mario. I appreciate it.
Announcer That's it for this edition of the JSFCentral podcast. The music for this podcast was composed and performed by Kito Mann. Thank you for listening.


RSS feed(all feeds)

The Editor's Desk
Podcasts
Inside Facelets
In the Trenches

Site version 1.83  Report web site problems

Copyright (C) 2003-2015 Virtua, Inc. All Rights Reserved. Java, JavaServer Faces, and all Java-based marks are trademarks or registered trademarks of Oracle Corporation. in the United States and other countries. Virtua, Inc. is independent of Oracle Corporation. All other trademarks are the sole property of their respective owners.