The WARS Architectural Style

Discussions

News: The WARS Architectural Style

  1. The WARS Architectural Style (24 messages)

    O'Reilly recently published the second of two articles on abandoning the use of MVC as an architectural style in command pattern frameworks. The second article illustrates a radical alternative to MVC called WARS.

    The WARS pattern splits up a command pattern framework into families of Workflow, Action, Representation and State components. A diagram of how WARS relates to MVC can be found at http://shocks.codehaus.org/images/mvc_wars_01.gif.

    One of the central concepts in the evolving WARS architectural style is the protocol-neutral representational mechanism. Representation components provide a bridge to the underlying state subsystem. Their job is to organize and represent the application's state so that it can be more easily accessed by developers. It doesn't matter if you're building Actions, new business rules to plug into the Workflow system, or Controller components for your UI, you've got to get at the data somehow.

    My concepts for the representation subsystem are fueled in a large part by Greg Wilkin's "Contentlets" ideas (http://www.mortbay.com/MB/log/gregw/?permalink=servletsMustDieSlowly.html)
    and Roy Fielding's Representational State Transfer (ReST) architectural style.

    After taking in a lot of the suggestions and criticisms of the community, I continued work on the Shocks Command Pattern Framework last month.

    Since December, I've begun the process of divorcing the Shocks framework from the Servlet API and have refined the architectural style to be more protocol-neutral and general purpose.

    The overall principles, that the total system could be decomposed into modular subsystems and that subsystem components each fulfilled one of four roles, still holds true. These roles can be captured into interfaces, and a clean division of component concerns can be made.

    The WARS architecture could be for middleware command pattern framework developers what MVC was to graphic user interface developers. It's a style that describes the best practices that are already in play.

    Read The WARS Architectural Style

    Other good news is that the Shocks project has moved to Codehaus and its website has been updated in anticipation of an upcoming alpha-3 release: http://shocks.codehaus.org. The release will come once a handful of hierarchical tests are ready.

    Any ideas and feedback are welcome. I'll do what I can to answer questions.

    Threaded Messages (24)

  2. MVC and Struts[ Go to top ]

    Reading through what you have to say about struts, mvc, and your own design wars a few thoughts come to mind...

    1) Why do you hold up the presence of the ActionForm class as an example of how struts is not MVC, or more specifically, how Forms do not conform to the idea of a model? I'm not sure that I disagree with your conclusion but would like to hear your reasons...I've thought the same in terms of struts as mvc, but perhaps for different reasons. Some of it, as I believe is mentioned, is because of the nature of web applications work: in theory in an mvc architecture, the controller should handle updating the model, but at the same time the view component should be listening for changes to the model and possibly refreshing based on these changes. Obviously, forms don't do this, so from that perspective they are not an exact fit, but at the same time, I'm not sure that this discrepancy rises to the level of a major concern, but more of a quibble that reflects the limitation of the medium(i.e., web applications). Does this mean that web applications can't be mvc? Or just that the ideas of mvc have to be reworked slightly when taken to the web?

    2) It seems that a lot of your criticism of struts is less on whether it actually helps in the construction of mvc apps or not, but more on its own internal architecture...is it supposed to be mvc itself, or simply faciliate those using it implement mvc-style architectures...though I don't doubt that the manner in which you are seeking to extend struts is quite useful in some scenarios, to judge a systems sufficiency based on the following:

    "the total system must be capable of continuous growth, it must be possible to add new subsystems or change old ones without disturbing the total system. It must be possible to include 'foreign' systems developed by other people without upsetting the total system"

    seems like it might be overreaching by a tad. Moreover, to judge a framework by the same criteria seems a little misguided. Certainly the degree to which a framework can be a catalyst to allowing the above is something that will substantially affect its usefulness, but does the framework itself have to be held to the same standard? Perhaps, but many developers using frameworks are less interested in extending them than in how much they will help them build their applications. Obviously if they can be extended easily that is gravy, but I'm not sure it would be the top criterion I would use to evaluate it(and I'm not convinced either that struts is so terribly difficult to extend...obviously as with anything it requires some poking around in the code, but it is probably one of the more/most cleanly designed open-source projects I have looked at). Either way I was not clear at times whether you were talking about the internals of the framework or the applications built on it.

    And is it even correct to say that struts violates these principles? I would argue that it depends on how one defines system and subsystem...the entirety of stuts to me is akin to a subsystem. And within any set of closesly related classes and logic, it is difficult, no matter how one designs it, to revise the their structure in a significant manner without upsetting some of other pieces that interact with it. In brief, ease of growth and integration within a system has a lot to do with at what level the system is designed allow it. To build with intention of allowing it at the absolute lowest level requires a lot of extra work, and perhaps not a huge return to boot(After all, the lower the level, the more detail to learn about it).

    In general I liked the ideas you are proposing. The whole workflow aspect is something I would very much like to see in struts, and the classloading, though not something I have found tremendous use for, is intriguing from a pure technical perspective. I also appreciated the research and history you provided on MVC. Based on my own readings about it, I would say one very obvious issue with it is even with something as often talked about and cited as MVC is, I'm not sure people are really talking about the same thing.

    -John
  3. Separation of Tiers[ Go to top ]

    Some of my colleagues and I have also been concerned about the tight coupling between the transport protocol (HTTP) and the MVC-type framework that many implementations such as Struts exhibit today.

    From that perspective, your decomposition of the solution into protocol-agnostic Action and Workflow components (among others), is a much better approach.

    However, Actions and Workflows are "Business Logic", and not necessarily "Presentation Logic" unless they influence screen flow. In an N-tier Enterprise Architecture, they would normally be implemented as Session Beans. In the degenerate case of a Web Architecture where there is no dedicated middle tier for business logic, they must be implemented as POJOs managed by the web container.

    My criticism of WARS (correct me if I am wrong) is that your Action and Workflow components are implemented as web tier components. Ideally, the framework must allow for them to be implemented either in the web tier or in the EJB middle tier (for an N-tier Enterprise Architecture). There must be a Business Delegate in the framework that makes the local/remote call transparent to the Presentation Tier.

    I may have glossed over the business logic/screen flow dichotomy here. Is there place in the framework to separate these out? i.e., have a separate set of components to manage business logic Actions and Workflows, and another set to manage screen flows (display this page if back-end logic returns this result, etc.). These then very neatly fall into the EJB middle tier and the Presentation (web) tier, respectively. In the degenerate case of a web architecture, the business logic components also move into the web tier.

    Does this make sense? I'd like to hear your thoughts on this.

    Regards,

    Ganesh Prasad
  4. Separation of Tiers[ Go to top ]

    Some of my colleagues and I have also been concerned about the tight coupling between the transport protocol (HTTP) and the MVC-type framework that many implementations such as Struts exhibit today.

    >


    If you're concerned about your MVC being tied to HTTP, take a look at WebWork. Both WW1.x and WW2 allow you to build web applications with Actions which have no dependencies on web classes. WW2 takes this even further by pulling out the core command pattern into XWork, a generic command pattern framework which has absolutely no web dependencies.

    > From that perspective, your decomposition of the solution into protocol-agnostic Action and Workflow components (among others), is a much better approach.
    >
    > However, Actions and Workflows are "Business Logic", and not necessarily "Presentation Logic" unless they influence screen flow. In an N-tier Enterprise Architecture, they would normally be implemented as Session Beans. In the degenerate case of a Web Architecture where there is no dedicated middle tier for business logic, they must be implemented as POJOs managed by the web container.
    >
    > My criticism of WARS (correct me if I am wrong) is that your Action and Workflow components are implemented as web tier components. Ideally, the framework must allow for them to be implemented either in the web tier or in the EJB middle tier (for an N-tier Enterprise Architecture). There must be a Business Delegate in the framework that makes the local/remote call transparent to the Presentation Tier.
    >

    I agree. In this respect I like Spring or Pico much better. Spring provides implementation transparency for your services, as your service implementations can be local POJOs, local EJBs looked up via JNDI, or even remote Objects looked up via JNDI. A lightweight container such as Spring or Pico can provide the glue between your presentation layer and your backend services, and allow each to evolve separately.
     
    Jason
  5. Separation of Tiers[ Go to top ]

    Are there any concrete examples of XWork/WW2 for non-Web-based applications? I've got a couple of apps taht need to have a Web and Swing-based view tacked on. I would love to be able to use a generic command processing framework for both of them, but I haven't been able to find one that fits the bill yet.
  6. Separation of Tiers[ Go to top ]

    Are there any concrete examples of XWork/WW2 for non-Web-based applications? >I've got a couple of apps taht need to have a Web and Swing-based view tacked on. >I would love to be able to use a generic command processing framework for both of >them, but I haven't been able to find one that fits the bill yet.


    It's a concern to me that we talk about frameworks and command
    architectures without ever discussing threading.
    All this work seems to get done in random threads
    and nobody seems to care or even consider it an issue.

    Java's approach to threading is a nightmare because 99%
    of the people i see have no idea how to use threads.
    A classic example is http://www.artima.com/forums/flat.jsp?forum=106&thread=29215
    where nobody noticed that the code was just wrong.

    A good framework would also have an application threading model
    so we wouldn't have to worry about deadlock, priority
    inversion, starvation, large latencies do to poor
    layer linkages, poor performance do to massive amounts
    of unecessary locking, poor quality of service, etc.
  7. Show us the way![ Go to top ]

    Are there any concrete examples of XWork/WW2 for non-Web-based applications? >I've got a couple of apps taht need to have a Web and Swing-based view tacked on. >I would love to be able to use a generic command processing framework for both of >them, but I haven't been able to find one that fits the bill yet.


    So help us write it!

    > It's a concern to me that we talk about frameworks and command
    > architectures without ever discussing threading.
    > All this work seems to get done in random threads
    > and nobody seems to care or even consider it an issue.

    You're considering it as an issue right now, though. I know I have a lot to learn about threading and thread safety, but one person can only do so much ;) Maybe you can help out with that?

    > Java's approach to threading is a nightmare because 99%
    > of the people i see have no idea how to use threads.
    > A classic example is http://www.artima.com/forums/flat.jsp?forum=106&thread=29215
    > where nobody noticed that the code was just wrong.
    >
    > A good framework would also have an application threading model
    > so we wouldn't have to worry about deadlock, priority
    > inversion, starvation, large latencies do to poor
    > layer linkages, poor performance do to massive amounts
    > of unecessary locking, poor quality of service, etc.

    You sound like you've given the matter some thought, which makes me want to give it more thought. But you're right of course. You should push these ideas in the big project lists, or write some articles on the matter for O'Reilly or TheServerSide. I know you'd probably find a very receptive audience.
  8. Separation of Tiers[ Go to top ]

    Are there any concrete examples of XWork/WW2 for non-Web-based applications? I've got a couple of apps taht need to have a Web and Swing-based view tacked on. I would love to be able to use a generic command processing framework for both of them, but I haven't been able to find one that fits the bill yet.



    I'm not sure if there are any good examples out there... I don't build Swing apps myself, and most of our users build web apps. I know some people were working on examples, but I don't think anything's been published.
  9. Are there any concrete examples of XWork/WW2 for non-Web-based applications? I've got a couple of apps taht need to have a Web and Swing-based view tacked on. I would love to be able to use a generic command processing framework for both of them, but I haven't been able to find one that fits the bill yet.

    >
    >
    > I'm not sure if there are any good examples out there... I don't build Swing apps myself, and most of our users build web apps. I know some people were working on examples, but I don't think anything's been published.

    Jason's right. A lot of us focus on web apps to the point that Swing and other thick-client GUIs get left out entirely. We could do more to support this. You might check out Droplets. Apparently they have some kind of SwinGUI --> J2EE bridge. That's the best I can offer at this point, though. Good luck!
  10. Agreed. Check out Webwork.[ Go to top ]

    Jason's right. Webwork does a lot of the protocol-neutral runtime state aggregation already--they've been doing a really good job at it for quite a while now. The protocol-neutral representational model is a ways off in Shocks.

    Jason, what's the plan to change WW to the Apache 2.0 license?

    --
    N. Alex Rupp
  11. Separation of Tiers[ Go to top ]

    Some of my colleagues and I have also been concerned about the tight coupling between the transport protocol (HTTP) and the MVC-type framework that many implementations such as Struts exhibit today.

    >
    > From that perspective, your decomposition of the solution into protocol-agnostic Action and Workflow components (among others), is a much better approach.
    >
    > However, Actions and Workflows are "Business Logic", and not necessarily "Presentation Logic" unless they influence screen flow.

    Not at all. The Actions and Workflows aren't Presentation logic at all. If you go to http://shocks.codehaus.org/images/mvc_wars_01.gif you'll see a split between the presentation logic and the server logic ;)

    Hopefully this helps
    --
    N. Alex Rupp
  12. 1) Why do you hold up the presence of the ActionForm class as an example of how struts is not MVC, or more specifically, how Forms do not conform to the idea of a model?


    I identify the terms "Model", "View" and "Controller" in their original context of a GUI MVC triad. I don't accept their use as architectural terms for components in command pattern frameworks. It's a matter of semantics, but it is an important distinction for me.

    > I'm not sure that I disagree with your conclusion but would like to hear your reasons...I've thought the same in terms of struts as mvc, but perhaps for different reasons.

    Perhaps. My reasons are based on research I've done on MVC and years of experience developing GUI apps.

    > Some of it, as I believe is mentioned, is because of the nature of web applications work: in theory in an mvc architecture, the controller should handle updating the model, but at the same time the view component should be listening for changes to the model and possibly refreshing based on these changes.

    Again, you're using a completely different terminology than I am. Controllers are buttons, slider bars and the pieces which correspond to a control panel in a user interface. The standard component library in Flash MX is a great example of controller components. Struts' re-interpretation of MVC is based on a misunderstanding of the purpose of MVC, which is why it is so confusing for GUI developers when they're making the transition to Java.

    > Obviously, forms don't do this, so from that perspective they are not an exact fit, but at the same time, I'm not sure that this discrepancy rises to the level of a major concern, but more of a quibble that reflects the limitation of the medium(i.e., web applications). Does this mean that web applications can't be mvc? Or just that the ideas of mvc have to be reworked slightly when taken to the web?

    Neither of the above ;) Web applications *can* be MVC, or at least the GUI components of a web application can be built as MVC triads in the traditional ST-80 sense. HTML has a set of pre-built controller components in its INPUT elements. It also allows you to plug in whatever view (IMG) components you like, but its model is next to impossible to use in traditional GUI MVC triads. Thus the reliance upon a server-side model and generation of content with servlet technology.

    > 2) It seems that a lot of your criticism of struts is less on whether it actually helps in the construction of mvc apps or not, but more on its own internal architecture...

    That is true. I love Struts. I just got the Struts in Action book and have been reading over it. The book gives me a whole new appreciation of the technology, from the user's perspective. I never had any trouble with Struts until I needed to extend it, which is when I embarked on this interface trek and began researching MVC's roots as a design pattern.

    > is it supposed to be mvc itself, or simply faciliate those using it implement mvc-style architectures...

    Neither. The failure to implement well defined MVC architectures comes from a misunderstanding of the terminology, particularly the "controller" term and its role in GUI components. Not until recently has the original research material for that been easily accessible, so many people have been flying blind unfortunately.

    > though I don't doubt that the manner in which you are seeking to extend struts is quite useful in some scenarios, to judge a systems sufficiency based on the following:
    >
    > "the total system must be capable of continuous growth, it must be possible to add new subsystems or change old ones without disturbing the total system. It must be possible to include 'foreign' systems developed by other people without upsetting the total system"
    >
    > seems like it might be overreaching by a tad.

    I like a good challenge.

    > Moreover, to judge a framework by the same criteria seems a little misguided.

    My "judgement" is derived directly from Reenskaug's early research. This is the yardstick by which I now evaluate frameworks. The Wafer project at Sourceforge does a straight-up feature comparison. What of the ability to add new features? If feature packs could be plugged into any framework, we'd find ourselves able to accomplish a lot more as a community by splitting up into specialized teams who each attack a specific feature (form validation, L1on, persistence, JSF compatibility, type conversion, JSR 94 rules implementation, State subsystem, etc).

    > Certainly the degree to which a framework can be a catalyst to allowing the above is something that will substantially affect its usefulness, but does the framework itself have to be held to the same standard? Perhaps, but many developers using frameworks are less interested in extending them than in how much they will help them build their applications.

    Agreed 100%, which is why I target my work to date toward Open Source middleware developers and not the end users ;) Again, the ability for third party software teams to add feature packs to a framework without having to ask permission of the framework's core developers would be a decided advantage in this case (I would think).

    > Obviously if they can be extended easily that is gravy, but I'm not sure it would be the top criterion I would use to evaluate it(and I'm not convinced either that struts is so terribly difficult to extend...obviously as with anything it requires some poking around in the code, but it is probably one of the more/most cleanly designed open-source projects I have looked at).

    You might be right. If you have something against interfaces, then Struts is definitely the package for you ;) I'm not trying to replace Struts. I'm just holding up a different mirror by which its developers might consider their work.

    > Either way I was not clear at times whether you were talking about the internals of the framework or the applications built on it.

    I see the internals and the applications built on them as the same thing. Action packs which introduce new business logic to the total system. Whether that business logic is general purpose (form validation, type conversion) or specific (altering credit records) should have no bearing on how it is added to the total system.

    > And is it even correct to say that struts violates these principles? I would argue that it depends on how one defines system and subsystem...the entirety of stuts to me is akin to a subsystem.

    Everything is a subsystem of the physical universe, it's a truism. Struts, as a system can be decomposed into subsystems. Not

    > And within any set of closesly related classes and logic, it is difficult, no matter how one designs it, to revise the their structure in a significant manner without upsetting some of other pieces that interact with it. In brief, ease of growth and integration within a system has a lot to do with at what level the system is designed allow it. To build with intention of allowing it at the absolute lowest level requires a lot of extra work, and perhaps not a huge return to boot(After all, the lower the level, the more detail to learn about it).

    I agree. I'm limiting the scope of my efforts to a JSR-94 rules engine, some nonspecific state machine (that UniMod looks cool), whatever action packs people want to add, and the protocol-neutral representational subsystem.

    > In general I liked the ideas you are proposing. The whole workflow aspect is something I would very much like to see in struts, and the classloading, though not something I have found tremendous use for, is intriguing from a pure technical perspective. I also appreciated the research and history you provided on MVC. Based on my own readings about it, I would say one very obvious issue with it is even with something as often talked about and cited as MVC is, I'm not sure people are really talking about the same thing.

    :-) Thanks, John. That's about as much as I could ever hope for. It's a really tricky topic and just getting to the point where people can agree on terms would be a huge step forward for me. I'm going to do everything I can to make these ideas palatable for the Struts guys. Even if they don't use any of my code, that's okay with me. I just want to talk about how we decompose the system so that it's easier to plug stuff into it. Anything we can do to make it easier for Open Source developers to contribute to the total system should help out the end users in the long run.

    Cheers,
    --
    N. Alex Rupp
  13. The WARS Architectural Style[ Go to top ]

    The concept seems awfully close to the one I'm using =)

    Representation:
    Domain field that contains the objects and their relationships. Objects themselves are state aware so one can perform operations on them at the client side and submit the changes either in bigger or smaller blocks.

    State: Object knows, persistence mechanism uses (to keep updates as fine-grained as possible) and persistence mechanism resets (after updates are done). Client connection can have a state too, e.g. a transaction that spans multiple requests.

    Workflow: A path that client submitted domain object needs to follow before response is sent back to client.

    Action:
    A workflow path consists of Action classes that perform discrete operations on domain objects e.g. security/cache/update/persistence/messaging/etc..

    The server model needs one more keyword, Support:
    Support classes/packages consist of transport/protocol layer, asynchronous messaging classes, database connection pooling, configuration classes and other non business logic or domain model stuff.

    I try to keep the server as light and simple as possible. Protocol weight is minimized (optimized serialization) and load requests as fast as possible. Moderate amount of domain objects are cached so that at least 95% of loads are from cache. The more complex your objects are, the more critical that 'rule' gets.

    45% of code is in domain objects, 45% in persistence layer and the rest in Workflow and Support. Persistence layer supports both history and versioning of domain objects so it cannot be done with ready made tools (Hibernate, CMP, JDO).

    Sorry if there're mistakes in my english..
  14. The WARS Architectural Style[ Go to top ]

    Nipsu,

    Looks great. Do you have some JavaDocs ?
  15. The WARS Architectural Style[ Go to top ]

    Nipsu,>

    > Looks great. Do you have some JavaDocs ?

    No, It's a closed source software =(, and it has some innovations critical to our success in the field (Engineering/Design/Project mgm.) we're on.

    My point was that it's not that hard (at least in lines of code) to implement a J2EE'ish system without the complexity that over general frameworks seem to implicitly have. And that the building blocks presented by Alex seem to make sense. Creating and designing your system features and domain model is far more challenging than implementing a simple framework for it.

    Simple thread / client implementation for swing clients is easy and effective if the concurrent number of clients keeps below 1000 (our stress test application causes 5% load on server with 200 simultaneos clients mimicking more than average user activity. Server configuration 2000+ Athlon XP with 256MB of memory). Web front end can be serviced by another machine if the web use is high but to keep things simple servlet containers like Jetty or LWS can be easily embedded so they can talk directly with your domain model.

    This design is not for huge web stores or such. It's for typical multitiered client/server systems with < 1000 of concurrent users. (Although I think that properly configured AMD 64 3200+ with 2GB of memory can easily handle at least 2000 concurrent connections if running with newest linux kernel)
  16. I'm about to roll an alpha-3 release of Shocks, which will include API docs and some unit tests. I was ready to roll the release two weeks ago, but I've been trying to add some tests before I do that. I imagine the alpha-3 will be out in the next week or so.
  17. Similarities abound.[ Go to top ]

    The concept seems awfully close to the one I'm using =)


    Hopefully! It's supposed to describe the best practices already in play :)

    > Representation:
    > Domain field that contains the objects and their relationships. Objects themselves are state aware so one can perform operations on them at the client side and submit the changes either in bigger or smaller blocks.

    My concept of representation components is that they are completely passive. They do not mutate the state at all. All state mutation is relegated to actions. Representation provides an abstraction to the State. I did a bunch of research on representational models. Primarily they fulfill a pragmatics role in making the applicatin's state more human-readable.

    > State: Object knows, persistence mechanism uses (to keep updates as fine-grained as possible) and persistence mechanism resets (after updates are done). Client connection can have a state too, e.g. a transaction that spans multiple requests.

    Sounds more or less analogous to mine ;)

    > Workflow: A path that client submitted domain object needs to follow before response is sent back to client.

    I've been convinced to go with a JSR-94 rules engine for the workflow subsystem. It's nice because (hopefully) then I won't have to worry about building one. :)

    > Action:
    > A workflow path consists of Action classes that perform discrete operations on domain objects e.g. security/cache/update/persistence/messaging/etc..

    Basically--and whatever custom actions the end users need for their business apps. I see actions as the only classes allowed to mutate the state at runtime.

    > The server model needs one more keyword, Support:
    > Support classes/packages consist of transport/protocol layer, asynchronous messaging classes, database connection pooling, configuration classes and other non business logic or domain model stuff.

    All of the DB connection pooling will be relegated to the J2EE container. Patching the State through to that tier will be the job of one Action package in the platform. I know people who've already built all of that stuff for JBoss and are building it again for Geronimo ;)

    > I try to keep the server as light and simple as possible. Protocol weight is minimized (optimized serialization) and load requests as fast as possible. Moderate amount of domain objects are cached so that at least 95% of loads are from cache. The more complex your objects are, the more critical that 'rule' gets.

    Sounds great :)

    > 45% of code is in domain objects, 45% in persistence layer and the rest in Workflow and Support. Persistence layer supports both history and versioning of domain objects so it cannot be done with ready made tools (Hibernate, CMP, JDO).

    That's too bad--rolling my own persistence engine is far beyond the scope of my work. I'd rather take advantage of all that existing infrastructure. I also know better--those guys have been working on the persistence issue for years. I don't have enough time to reinvent their wheel. It's enough to reinvent this one ;)

    > Sorry if there're mistakes in my english.

    Nah, it's great. Keep up the great work.
  18. taken from
    http://shocks.codehaus.org/
    "Controllers in the classical sense (no matter what your college professor might have told you) are the knobs, buttons, scroll-bars, text entry fields, radio buttons and "widgets" that allow end users to control the application."

    Wow, a new definition of the "C" in MVC. Somehow I find little evidence of that definition after looking through my mind, my GOF book's copy and the internet.

    Hmmm.
  19. That's too bad.[ Go to top ]

    My definition of "Controller" comes from the man who created MVC, so it's the "old" definition, not some "new" one I dreamt up in the shower ;)

    See http://heim.ifi.uio.no/~trygver/ for more information on MVC.
  20. That's too bad.[ Go to top ]

    Actually I don't think the source you cite even comes close to supporting your definition of "controllers", which seems to me to be what the rest of us tend to refer to as "controls".

    Here's Reenskaug's definition from the site you referenced:

    "A controller is the link between a user and the system. It provides the user with input by arranging for relevant views to present themselves in appropriate places on the screen. It provides means for user output by presenting the user with menus or other means of giving commands and data. The controller receives such user output, translates it into the appropriate
    messages and pass these messages on to one or more of the views."

    If you think this is synonymous with "knobs, buttons, scroll-bars, text entry fields, radio buttons and "widgets", then I wonder if you have understood the MVC pattern.
  21. That's too bad.[ Go to top ]

    My definition of "Controller" comes from the man who created MVC, so it's

    > the "old" definition, not some "new" one I dreamt up in the shower ;)

    Essentially I do not care which definition is right or wrong, one way or another it leads to misunderstanding of a given design which results in building the wrong/different/incompatible thing.

    Consider two developers making a design decision upon GUI and agreeing upon MVC and divide up the work. Each of them goes on and implements his part of the share, they meet again after one week and find out each one of them they build something completely different and incompatible.

    Some things in fine design/object design are accepted to be vague or unspecified for a good reason. if these things happen in architecture, results are undefined.
  22. Still over domain objects, right?[ Go to top ]

    Some of my colleagues and I have also been concerned about the tight

    >coupling between the transport protocol (HTTP) and the MVC-type
    >framework that many implementations such as Struts exhibit today.

    I guess i have been assuming that regardless of how the application
    is being adapted to its clients (jsp, soap, fat client, CGI, etc)
    that they are all just layers over the underlying domain objects.
    It sounds like that is not the case if struts and other technologies
    are tightly bound into domain objects.

    Is this a problem with struts or developers?
  23. Still over domain objects, right?[ Go to top ]

    Some of my colleagues and I have also been concerned about the tight

    > >coupling between the transport protocol (HTTP) and the MVC-type
    > >framework that many implementations such as Struts exhibit today.
    >
    > I guess i have been assuming that regardless of how the application
    > is being adapted to its clients (jsp, soap, fat client, CGI, etc)
    > that they are all just layers over the underlying domain objects.
    > It sounds like that is not the case if struts and other technologies
    > are tightly bound into domain objects.
    >
    > Is this a problem with struts or developers?

    I so agree. Asking someone about the specific architecture of an application and having them reply - "We are using Struts" - is pathetic. Struts doesnt provide your application with a sound architecture - nore does any other framework. Designing and implementing a proper architecture for an application is the responsiblity of the architects, designers and developers of that application.
  24. Semantics[ Go to top ]

    I agree that the argument over "controller" as it applies to MVC - modern or historical meaning - is one of semantics. Which is fine, so long as we understand each other's perspective and meaning. But I still can't accept how arguing that - the modern definition of a controller not mirroring its historic definition - is reason enough to abandon the idea. It's easy to say "I don't believe in MVC in web apps because MVC is being used incorrectly". Sure, that's great. But so what? it's being used in a certain way and it is working. To rule out a pattern because of a dislike for its name is myopic.

    What matters is that the pattern is commonly understood and applied. What was once considerd a "controller" in Smalltalk MVC, is now commonly referred to as a "control" in GUI design. MVC has evolved, mutated, grown up, but the modern definiiton has stuck.
  25. I think I can say with others that I'm already quite familiar with the WARS style you describe. But I don't quite understand why you would have to create new frameworks round this concept.

    IMHO, WARS is already present in the completely classic way of using Session Beans as Façade to domain objects using Value Objects.

    The latter are the Representation, the session beans are the Actions and the Entity Beans are the State. (Well sure, you could replace the Entity Beans with hibernate objects)

    I also completely agree with the fact the the R in WARS becomes the M in the classic MVC triad when building the GUI.

    For this part, I'm personally completely satisfied with Cocoon, which has a flow language supporting continuations. With that I have everything I need to know about the application concentrated in one place. Really, this is a revolution and I don't understand why this mechanism isn't already much more widespread.

    Moreover, I think the representations should be driven by the flow developer. I'm currently developing something similar to what is described in the following document:
    http://www.bs-factory.org/components/svo.shtml

    All this leads to an architecture which is more and more likely to get tooled. For the state, visual tooling from the MDA folks works great.

    For the GUI, all you need to do is map widgets with representation objects (again think CocoonForms, aka woody). This is very simple to wrap in a GUI.

    Create the representations on demand with (Dynamic) Smart Value Objects.

    And for the glue (workflow), use continuations.

    Now, please, I must be missing something here. I've completely missed the point with IoC or dependency injection or whatever that everyone's talking about at the moment. Could somebody be so kind to explain what I would gain using it in the architecture I just described ?

    Now comes my question:

    Like I said, I believe that all these best practices will one day or another boil down to some kind of graphical methodology. But for that we need both solid technologies and sound conceptual foundations. Is that what Shocks AND/OR IoC are about ? Making everyone agree on some common technological ground to let a new concurrential marketplace emerge ? If this is the case, I'm ready to plunge right away into it.