Discussions

News: HyperQbs - a component-oriented framework for presentation logic

  1. You can find all the relevant information regarding the HyperQbs component-oriented framework for presentation logic including its downloadable distribution package at http://www.hyperqbs.org

    The getting started document is available in zipped PDF form at GettingStarted.pdf.zip.

    HyperQbs Technology
    (Components with a dynamic face)

    HyperQbs mission is to simplify and speed the life-cycle process of developing, extending and integrating internet applications for professionals and users - via a Lego-like approach. HyperQbs middle-ware technology defines 'components with a dynamic face' based on open J2EE and XML standards.

    Current way for using EJB components containing reusable business logic, is to 'glue' them together via JSP/Servlet
    technologies. This 'glue' is however a contrary to EJB's benefits. While EJBs are reusable and easy to follow in application life-cycle processes (modeling, prototyping, deployment and maintenance), JSP/Servlet 'glue' is usually hardwired and proprietary implementation. This 'glue' decides on where the next page should go, how to react to user events, handle error states etc. When an alternative user interface device (such as WAP, refrigerator etc.) is to be supported by an application, a new servlet 'glue' must be written. The more interface devices, the more 'glue' for one application.

    Such a JSP/Servlet "glue" actually provides the EJB business logic with application/presentation logic. Out of real world experience JSP/Servlets are good for small projects while the rule goes: the bigger project, the bigger the "glue" gets causing more trouble down the road.

    HyperQbs bridges the technology gap and eliminates the need for a 'glue' making it a part of fully reusable EJB component (so called Qb [read as Cube]). On top of that, HyperQbs define CAF (Configurable Application Flow) mechanism, which allows changes in component behavior without ever touching the source code. In fact this is done in a similar fashion as how integrated circuits and microchips function.

    HyperQbs benefits:
                                                                - Fast prototyping of Internet applications
    - Incremental development and team work
    - Pure reusability of plug-in components
    - Application logic may be configured - no need to change source code (AAF)
    - Development accelerator
    - Small learning curve
    - Control, flexibility and security over a running application
    - High scalability and extendibility

    More techy info ...

    HyperQbs is actually an open component oriented presentation middle-ware based on J2EE and XML standards defining a robust 4-tier architecture in Internet application development. HyperQbs technology allows for complete separation of presentation logic from application's code into system level services. This is provided by the HyperQbs Engine (the run-time environment) in a similar fashion to what MS Windows provides to PC application developers. This also means that such an approach effectively splits the work between programmers and web designers, enables teamwork and pure reusability of plug-in components.

    HyperQbs technology is an implementation of the M-V-C (Model-View-Controller) paradigm into the world of Internet application component development. Where the HyperQbs layer (Engine + Qbs) plays the role of Controller. Various user interfaces, such as HTML, WML and alike browsers including systems such as SMS, SMTP, PDF or even a microwave oven represent the View and your EJB, JavaBean etc. business logic stands for Model.

    The components used in HyperQbs technology are called Qbs [read: Cubes]. Qbs components encapsulate your EJB, JavaBeans or just pure Java into a compact package containing Java code, templates and its configuration. Individual Qbs each having a specific functionality are developed by third-parties and then assembled into a final application in a Lego like fashion.

    Each Qb has a certain purpose and can be replaced or reconfigured if necessary without touching the source-code thanks to the Adaptive Application Flow mechanism (AAF). You can imagine a Qb and AAF as an integrated circuit having its pins on the motherboard and a separate configuration program defining its behavior.

    A Qb usually manages only one well-defined specific function, while Qbs could be grouped into clusters (bigger Qbs) for more complex functions and ungrouped as necessary for reuse.

    Qbs have common means for interaction with their environment (other Qbs, data ) and they usually represent a visual component (e.g. a dialog box, menu, list box, banner etc.) in a portion of the page or even a whole page itself.

    In the event-driven server-side model each Qb manages only the event that belongs to it this results in a clear responsibility of the various parts of an application which ultimately simplifies the application structure.

    The future is to have Qbs independent from programming languages while keeping the unified generic structure of M-V-C and the plug-in reusability of Qbs intact. Additionally, visual drag & drop Rapid Application Development tools to easily deploy an internet application from existing components (the Qbs) are under development and will be available soon for alpha testing.

    Features:
    - Event-driven
    - Server-side
    - Presentation logic
    - Adaptive Application Flow (AAF)
    - Plug-in components
    - IMA and ASP ready
    - Based on Java and XML standards

    Threaded Messages (38)

  2. This sounds like an commercial implementation of the current PetStore Demo's MVC architecture.

    Are there parallels between the two?
  3. This is not a PetStore clone in anyway, you could rather build the web tier of the pet store with HyperQbs(It would be a cool idea for the HyperQbs team, it would also make it easier to understand what they are talking about). It's an interesting new technology which let you create the web tier(View-Controller) in an object oriented way. If you have worked with JSP and Servlets you know the evils of it. Basically, this architecture is a step further to the template engines. You create your companonents(Web) in Java and then assemble them with XML descriptors. It also seems to have good XML support e.g. XPath, XCatalog etc. In my openion if you don't want to imitate the good old CGI stuff in Java(i.e. Servlets) and ASP, JSP, PHP etc. HyperQbs is your way to component based development(J2EE gives you the same at EJB Tier and the Enterprise Information Systems tier). I think it's worth a try though it's still in Beta.
  4. HyperQbs is not an application. HyperQbs is a technology that ensures services for presentation logic layer (controler in the MVC architecture) of Internet applications. The presentation part of mentioned application
    PetStore can be assembled from prebuilded HyperQbs components (Qbs). Qbs can be connected to EJB components and it allows full component implementation of MVC architecture.
    HyperQbs technology is free and we are thinking about OpenSource development model in the near future.
  5. I think, it would be great to have PetStore demo working on HyperQbs + Tomcat + AppServer or even better HyperQbs + Sun's J2EE Reference Implementation. It would help it position itself, Just reading the documentation and the description might be misleading but when you see it working with all the tiers of an applications it would be more clear, just my opinion.
     BTW, the idea of event driven model is quite revolutionary. Does anyone know if it's done before in web applications?! or any parallel projects?!
     Kudos to the development team!
  6. It is good idea. We will think about implementation PetStore for some of next releases.

    I don't know if exist any othet internet technologies based on event driven model. But HyperQbs is conjuction of more ideas.
    - components
    - event driven model
    - plugable template engines
    - connectors for cooperation with different client's end devices (WWW browsers, WAP browsers, email clients, ...)
    - configurable application flow (CAF) - bindings between pages are not hardcoded in the source code or in the HTML (WML, ...) files
  7. Hi, what do you mean by CAF and "not hardcoded binding between pages"? Does it mean that I've got some sort of redirections for referencing to other pages within my application? What's the big deal about it?
  8. Well, actually after reading the gettingstarted doc, which I downloaded a couple of days ago from their site, I think that CAF is something completely different (they also refer to it as AAF standing for adaptive application flow, but I think that CAF is more descriptive for what it does).

    They describe something called a 4-way request-response cycle in a life-cycle of a running application. This request-response cycle lets you to handle the run of your application in a quite interesting way. Handle events, error states and modify the run of your application based on many different things.

    They also describe the HyperQbs component as an integrated circuit with "pins", which let you to link individual components in an application together. Each Qb component has an XML configuration file as mentioned somewhere in this thread and well described in the gettingstarted. This configuration file, the request-response cycle and "pins" let you to model and change the application behavior on the run without touching the component source code.

    If I understand it well, than this means that I can take existing Qb and EJB components and put them together into an application. If for some reasons I want to change its behavior/functionality e.g. only for users of Nokia Wap user interface device - I don't have to program a new servlet or JSP or touch the components source - I just configure it.

    Although I didn't have a chance to elaborate with it, to me it sounds appealing. Has anyone tried it?
  9. Dario, you described it better than me :-).
  10. According to this thread I've downloaded your HyperQbs.
    It seem good, but I have two remarks.

    - how can I use JSPs as template engine? I have some applications written in JSP and I'd like to convert them to the HyperQbs for comparision the two technologies.

    - how can I incorporate standard Java components to HyperQbs application? Mainly EJB, JavaBeans and Applets.

    Thanks,

    PS
  11. I've last tried some previous release but I missed there some example working with database in some way, JDBC or EJB. The other examples are good but I need to see how to connect HyperQbs to the database - my applications are about databases - and I have no time to use the Try and Error methodology.

    But the principle sounds good - keep working, guys! :)
  12. I know, that there are some missing examples and documentation. So use the article as answer from our FAQ, which is rapidly developed now.

    HyperQbs defined two main kinds of components
    - Qb - it is a core code of the application. It could be divided into presentation part - Fundament and business logic part - Qbone

    - Dwarf - the data encapsulation.

    Fundament, Qbone and Dwarf could be configured during application startup. Fundament and Qbone have only one instance of the object per one Qb definition, but Dwarf, which was created and configured during startup, is cloned for each receiving it from DwarfArea - storage of configured Dwarfs.

    So if you would like to share database connections, create your own dwarf, prepare configuration for the database pool (such as DbConnectionBroker) and create the pool in configure() method of the Dwarf .

    If you are finding the best place for SQL query specification, the place is configuration of the Dwarf. Create your own Dwarf - the structure od the DB table could be emulated by hqListDwarf of hqMapDwarfs - add the methods load and store to the dwarf and call the methods from your Qbone, the component prepared for business logic.
  13. Do you mean you need to write your own data objects? if it is, it sucks... Too much of a hassle for such a small thing? you mean a developer need to manage transactions programmatically??
     Well, I would suggest come out of it guys. There are 10 different O/R tools out there. and if you still want to use *YOUR* components atleast make them compatible with JDO or Entity Beans.
  14. Oto, thanks for your answer - the principle sounds good to me.
    But, just from the point of view of "common" appliacation programmer - if I have to start to work with HyperQbs, there must be some fast way to do it. I have no time to try how to do it from the scratch. I need to see some way how to do it and to use that way ASAP, and just afther gaining some experience find out how to improve it.
    So I think such example will be _VERY_ helpful in the next release(s). Remember, the speed is crucial in real life and anything that can cut the learning curve of your technology can help it to survive - and may be win the race. :)
  15. Support plugable parser's modules will be available in the version 2.1. Then it will be theoreticaly possible to use any Java based parser (JSP, Fop - PDF, ...).

    Because HyperQbs components (Qbs) consist from regular Java classes it is possible to use any other Java technology. You can call home and remote interface of EJB components, to use JNDI, etc.

  16. This one is in response to rene michalek's 2001-01-30 11:51:48.0 post.
     When you say you can call bean methods, do you mean the HyperQbs framework provides you with some facilities or it's just a plain EJB Client??
     Also, I am interested in knowing about the performance. How are Qbs reused within an app-server/servlet engine, do you cache them or something? How about concurrent access and security?
     Is it possible to locate the qbs within an application server? I mean some namespaces where you could just use JNDI to lookup and call the qbs or is it just in xml descriptors?
  17. HyperQbs engine doesn't provide any services for data access, transactions, ... Qbs work as plain EJB client. One exception will be EJBQbone (a part of Qb) which allows configurable access to different EJB components.

    Qbs are possible to store anywhere (not only on a file system). During tests with SilverStream we had got Qbs located in SilverStream's database and access to them was realised via "ag" protocol.

    <qb instancename="MyQb" sourceuri="ag://MyDatabase/PlainQb.jar">
    ...
    </qb>
  18. In that case EJBQbone would be like session beans? or you mean that you will be adding a yet another layer between presentation and model i.e.
    fundament--->EJBQbone--->Session Bean--->Entity Bean -->DB.
     So, it's going to be like, you will be having xml descriptors for the beans containing binding of normal java namespaces to HyperQbs namespaces and depending on some convensions you would be using reflection for remote mathod invocation of the bean methods. Don't you think it would add another overhead to the application?
     
     Also, I can't understand this idea of dwarfs. Why do we need them when we have Collection API, JDO, O/R and Entity Beans??
  19. In that case EJBQbone would be like session beans? or you mean that you will be adding a yet another layer between presentation and model i.e.
    fundament--->EJBQbone--->Session Bean--->Entity Bean -->DB.
     So, it's going to be like, you will be having xml descriptors for the beans containing binding of normal java namespaces to HyperQbs namespaces and depending on some convensions you would be using reflection for remote mathod invocation of the bean methods. Don't you think it would add another overhead to the application?
     
     Also, I can't understand this idea of dwarfs. Why do we need them when we have Collection API, JDO, O/R and Entity Beans??
  20. I am developing application that should be used on both WAP and HTTP without major changes.

    I read a part of Hyperqbs documentation and it seems there is not REAL support of an internet protocol another than HTTP. You said about connectors but there is no close description about them and Hyperqbs outer interface. I am not able to write own protocol connector without knowledge about it. Yes, it looks good when some web server are supported but there are plenty of them and it is impossible to support all possibilities.

    I can also say after several experiments that it is not
    easy to learn how to write applications in Hyperqbs. The technology has many features simplifying the life of programmer but also other ones complicating it. By my opinion Hyperqbs can serve the development of big applications well but for small application it is the waste of time.

    I hope the development team will reduce complexity and do creation of application more easy and automatic. More open code can also help.
  21. HyperQbs engine is a servlet based technology today. It means for operation of HyperQbs you need some servlet container. Currently available servlet containers mainly works in cooperation with HTTP server.

    HyperQbs engine uses servlet as "connector" that transforms protocol specific request to internal unified form. When servlet containers for another type of servers (SMTP, LDAP, ...) will be available, appropriate application can communicate with another type of client.

    It is not necessary to write a plenty of connectors for the servers of the same type. For example, when some servlet engines support specification Servlet2.0 it is possible to use connector httpServlet2.0.jar for all of them. Specific connector is also useful when some servlet engine doesn't correctly implement some features of specification.
  22. It is very hard to write good component of any type (EJB, JavaBeans, Qbs). It means to spent a lot of time for analyse and specification of behaviour. Then coding and testing.

    But assembling application from existing Qbs is rather simple process. It means only definition bindings between Qbs.

    I think it is harder to write (assemble) simple application without suitable Qbs then a big application when all Qbs are available.

    With regard to documentation it is current weakness of HyperQbs. A lot of features should be documented better. But "Programmer's guide" is preparing now and I hope it will be available soon.
  23. It will be useful when distribution will contain more examples.

    Application "featuresdemo" which is a part of HyperQbs distribution is good for description of specific features but it will be better to see a complex application - like PetStore.
  24. Yes, I agree. The examples are good for demonstrating the individual features but a comprehenisive suite would be great. But the technology looks promising. What would also make sense is to see how well does it work with other technologies? E.g. There is a way to deploy components(qbs) etc., but what about if you want to deploy your applications as .war or .ear. Are there some plugins or extensions to some servlet engines or application servers for such a thing. It would be great if these components can be packages in a war and ear and you just need to deploy it, rather than deploying every qb(it can be a real development pain for a larger application). Since, J2EE spec tells about deploying applications as war and ear and most of the applications servers already support it e.g. Weblogic 6, Tomcat+JBoss, Orion etc. it would be good to have.

    And what about application management? is there something done already(may be JMX)?
  25. A first step towards deploying HyperQbs application as .war archive was realised in current Beta 1.0 release. It contains servlet engine Tomcat and configuration of all bundled HyperQbs application is realised via web.xml.

    I assume delivering HyperQbs applications as .war file will not be a problem. Information how to configure different servlet engines and application servers will be soon available on the site http://www.hyperqbs.org. In the first phase configuration of JServ, Tomcat, Jetty and SilverStream will be published.

    Remote management is very important issue for services which HyperQbs ensures. We are planing support of this feature.
  26. That's perfect. It looks like we would soon be having one of the important part of J2EE, i.e. a component based web tier.
    Sounds cool. All the very best to the developers of HyperQbs, keep up the good work.
  27. Hi, has anyone tried to use the HyperQbs middle-ware with IBM WebSphere? I've searched http://www.hyperqbs.org and noticed that there is a new section of supported application servers, but I didn't find WebSphere there. So far, they have only JServ, Tomcat and SilverStream listed there.

    I'm working on a voiceXML project and it seems that I could find use for presentation layer defined by HyperQbs since the application will have multiple user interfaces (HTML, WAP and voice). What do you think, should I try it or is it a vase of my time? of course I need it under webspeher :-|
  28. I think a standard version of WebSphere app. server uses Apache and JServ as www server and servlet engine. We will provide on the page http://www.hyperqbs.org/appservers/ a configuration for Advanced and Enterprise versions soon. When the document will be in "beta" quality I can send you description of configuration for testing (send us your email to info at hyperqbs dot org).

    It is possible to produce any XML (and non XML) output from HyperQbs application. Our partner (which is specialised on wireless and voice applications) tries to use HyperQbs for voiceXML project. An outcome will be probably available as a case study on http://www.hyperqbs.org/.
  29. BTW, which application server or servlet engine does the hyperqbs.org run?
  30. For serving dynamic pages we use Apache+JServ+HyperQbs 1.0. But http://www.hyperqbs.org contains a few dynamic pages now.

    We want to replace all current static pages by our "publishing" system which will be based on HyperQbs 2.0 and some J2EE app. server (probably JBoss?). Then all text information will be stored in a database in SGML (DocBook) form.
  31. I'm generally interested in rapid development and technologies allowing developers to create their applications more quickly and with less overall effort. So I'd welcome a closer explanation of how HyperQbs supports rapid development, I can't understand this fact well and couldn't find anything mentioning this in HyperQbs documentation. (Frankly, I'm quite suspicious to anything where "Java" and "rapid development" are near each to other. But you needn't mess with Java in HyperQbs once your Qbs are written, which looks promising.:-)

    As for the learning curve, I doubt it's small for HyperQbs. Not because understanding how to write the application description file was too difficult but because thinking in Qbs is quite different from the traditional approach applied to Web applications (PHP, JSP, ...). It requires some training and developer sophistication, I'd compare it with OO (everyone can write programs in an OO language, but not so many developers actually understand the basic OO concepts). IMHO entering the concept and learning to think in Qbs is no easy thing. It's worth the effort, but it's not quick and easy.
  32. Well, everyone is interested in Rapid development. If you see the idea behind HyperQbs they always talk about component-orientation. So, once you have a large number of components available to you (which is not a case now), you would really be able to experiance RAD. Second thing, if you talk about some RAD tools, I would suggest that they should try to create some plugins for JBuilder, Forte etc. so that you could build these *Qbs* effortlessly. Also, if you could have something like code generation within TogetherJ or something?!
      I can't understand you suspecion about Java and RAD, If you have been doing internet/e-commerce/m-commerce(whatever the fancy name may be) programming in other language you would know how easy and fast it is to build a real large and scalable applications with Java and specially J2EE(unless you don't live in 1996).
      I agree about *thinking in qbs*, it's going to be the hardest part I guess.
      I doubt how much of Object Orientation you have in HyperQbs itself.
  33. Hmm, I don't understand exactly what you mean as "thinking in Qbs". I know only principles of good design in Java Beans and I think in Hyperqbs it can be the same.

    When designer creates drawt of a new bean, he should very carefully judge if the draft solve several requirements:
    - the bean should perform only one (simple) functionality and no more
    - the functionality can be complicated but it should be simply describable (it is easier to think about simple things later)
    - bean should be richly configurable (properties) and cover a lot of different modifications of the same functionality

    If you keep these things in mind, your components have a chance to be reuseable.

    I don't think that it is very different in Qbs. Special things (request-response cycle) looks like another mechanism of calling without any real impact on "thinking". Thanks this any programmer, knowing concept of Beans well, is ready to learn Hyperqbs technology without serious problems. Maybe I am wrong, but it is my opinion.

    There is another real problem in Hyperqbs. When Sun come with Java Beans it has some reference implementation with some (stupid I know) BeanBox that shows power of the concept to enable RAD. I am afraid that there isn't a tool in Hyperqbs able to solve this. Hyperqbs looks very complicated and good tool is the best way how to avoid the complexity.

  34. How is this different from Turbine, Struts and other
    frameworks?
  35. We studied Turbine some time ago and we found out that it uses some concepts which we have rejected. For example

    - Turbine contains some means for cooperation with databases. This concept was left in HyperQbs 3/4 year ago because HyperQbs is focused only on presentation logic services. Connectivity to database (and other services transcation, messaging, ...) will solve true application servers. It is not good design concept to define a new way for communication with database.

    - Turbine is object oriented - class reusability. HyperQbs is component oriented - component reusablitity. Component is designed to be reused and customized without access or modification of the component&#8217;s source code, unlike objects, which often come in the form of a class library or framework and which are meant to be customized by subclassing the source code.

    - For Building Turbine application it is necessary to collect WWW page form 5 different parts -Action, Page, Layout, Navigation, Screen. Developing HyperQb application requires only one type of component - Qb. HyperQbs is more general concept because it is possible to compose output page from Qbs via a lot of ways.
  36. EJBQbone is designed as configurable SessionBean runner. The main purpose of the EJBQbone is "To make working with SessionBeans as easy as possible".
    Proxy creation during startup, remote calls via java.lang.reflect.Method object instantiated during configuration, cross-call of EJB using similar interfaces, caching, reconnecting to the EJB server and so on.

    The main question is:
    "What is better - changing the code for each usage of bean or make the Bean calls configurable?"
    We think that the second way is better.
  37. this one is in response to Oto Buchta 2001-01-31 06:51:50.0.
    Well, I am not sure if it's really *good* to have everything configurable. Also, this approach is not very performance friendly. As you said earlier that Qbs are plain EJB clients and if you are using remote calls for small operations I doubt it's any useful or if you do business logic in Qbs that's not good as well coz your presentation tier become fat. The best thing would be if you can run HyperQbs in the same JVM as the application server and the calls are no RMI but simple java calls.
     "To make working with SessionBeans as easy as possible" could you elaborate on that?! What you have suggested is not an easy way but just an another way of doing it.
     And the answer to your *main question* is "IT DEPENDS". If you go second way you might end up with over configuration.
  38. I must agree with Abhishek. Java is good language and there's no need to have _everything_ done outside of Java. I've noticed Milan Zamazal does not like
    Java very much and seems to hope that HyperQbs can be made so that no more Java coding will be necessary. Well, I wonder how he'll like programming in XML, though supported by some GUI or IDE...
    Well, guys, if you _really_ want to reach this stage, you should have chosen
    not an XML as your configuration platform, but maybe use Java code generation, compiled on-the-fly by HyperQbs engine. I believe it'd be quicker than
    inventing, viewing, understanding, editing and parsing complicated XML.
    Hunting for configuration power may result in not saving programmers from
    work, just passing all complexity from one environment to another. Beside this
    you'll surely agree that what's easy in one language (e.g. Java), may not
    necessarilly be easy nor easier in another language (e.g. XML). This is due to
    different purposes of languages. Finally you can reach the stage when you make things more complicated than they were.
    I like XML (when used as appropriate). I like HyperQbs concept and ideas (and hope
    it will go the right way). But beware: too many pretty good ideas seem to be
    useful from the point of view of academic developers, but they're useless and
    annoying in application programmer's everyday reality.
    Note about HyperQbs and EJB:
    It is already possible to run HyperQbs in jBoss/EmbeddedTomcat with integrated
    stack (means Tomcat and jBoss run in the same JVM and RMI calls might be
    handled locally, without serialization) This technology is still in beta, but
    promissing.
    However, HyperQbs still acts as EJB client, though hoping for speed
    improvements when run with embedded servlet container.
    I think great effort should be put forth to make HyperQbs valid part of EJB
    container.
    Another important gain for component-ware technology is on-the-fly
    configuration, components replacement and deployment. This must be one of the
    very first steps in the near future of HyperQbs development.
    I believe HyperQbs is (r)evolutional technology. However, there are still many
    things that _must_ be done, some technology trends were missed due to limited
    "man months" available. And many things can go wrong on this hunt for
    perfection.
    I hope HyperQsb development team will be lucky when making decisions.
    HyperQbs MUST be successful.
  39. Patrik, your idea about code generation seems to be very interesting idea, but there are some problems.

    The next stage of HyperQbs will contain very sophisticated management tool. It will support easy component reinitialization on the fly, adding and removing Qbs on the fly, change bindings on the fly and ather on-fly killer features.

    It is clear that on-fly changed binding can't be hardcoded in Java. They must be configured. And the best text-based configuration is XML.

    Other problem is in preparing configuration. Our approach is to make HyperQbs configurable as easy as possible. And IMHO everybod can edit XML file using plain text editor, such as vi or notepad. We have started works on GUI for preparing application configuration file and one of the main requirements is to change the configuration file by hand. And I don't believe in reverse engineering of changes in generated Java class file.

    So, is it clear why HyperQbs idea is "Everything in XML"?

    tapik