Discussions

J2EE patterns: Active XML Components

  1. Active XML Components (3 messages)

    I have been working on a framework that would be able to automatically doscover and integrate other framework and APIs via provided metadata and provide access to such via a common XML-based language. I have ventured as far a being able to integrate core Java, XSL, JDBC, JavaMail and Struts at this point and have come up with a more or less automated fashion (API based at the moment) to streamline integration of other useful frameworks and their metadata like Hibernate, Spring, Webworx, Taglibs and etc.

    A simple example of the language (accessed over the web via Struts) - deployed on the application server's classpath where the ActiveXML framework is deployed (/apps/appserver/appinstance/resources/sample/transform.rule):


    <html>
      <body>
      
    <!--transform xml via xsl-->
    <xtransform>
    <!--Let's say Clob returns xml in a form of
    <data><hello><world>I am a clob:</world></hello></data>
    -->

    <clob lob=".LOB_READ">

    <!--jdbc prepared statement to get the clob-->

    <jdbc-statement datasource-id="someDB">
    select someClobwithXml
    from someTable
    where someClobwithXml_id = ?

    <!--parameter out of request object with value, let's say 123456789-->
    <request-parameter name="someClobwithXmlId"
    bind-index="1"/>
    </jdbc-statement>
    </clob>

    <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

    <xsl:output method="html" encoding="UTF-8"/>

    <xsl:template match="/">
    <xsl:value-of select="/data/hello/world"/>\s<request-parameter name="someClobwithXmlId"/>
    </xsl:template>

    </xsl:stylesheet>

    </xtransform>

      </body>
    </html>

    End result of going against your application server where the framework is deployed with url
    http://someserver/someservlet/activexml/sample/transform.rule

    will be

    <html>
    <body>

    I am clob: 123456789

    </body>
    </html>

    Here you can see a healthy blend of HTML, XML, JDBC, Servlet API (accessing request object) and XSL.

    I am thinking it would be nice to provide even broader set of APIs, technologies and frameworks, abstracting compleixities and providing common implementation access over the ActiveXML framework's language - XSSL (eXtensible Server Side Language).

    To learn more about the project, submit your ideas and give feedback, please use this forum or go to http://activexml.dev.java.net for code repositories and to http://www.jroller.com/page/vivemoire for documentation BLOGS.
  2. I think that the intention of the framework heads in the right direction but that you should be looking at RDF and OWL for creating a comprehensive implementation meta language. If a larger more structured vocabulary isn't adopted then you'll be bolting on new fragments of XML configuration without any unifying syntax to provide a coherent means to extend the framework. This also means that all the intricacies of each and every technology's descriptors or tagging system has to be understood by a developer. How about abstracting away some of the need for this with a higher-level syntax.
  3. I think you are judging this incorrectly and this is solely my fault, as I have not given you or anybody in this matter more information and examples along with business cases to show the real flexibility of the framework.
    One thing you say it does not have, it has indeed and that thing is the complete abstraction from intricacies of any API, framework or system, where it as easy as to do <imap-attachments:message location="..."/> to retrieve all of the attachments from a complex multi-part mime message. In example here there absolutely no knowledge required about intricacies of the JavaMail API.
    ActiveXML allows for integration with any type of metadata be it Hibernate or Ant or XSL or any other kind of scripting language and the configuration for itself is defined on a per need basis, where it is dependent upon requirement and classification of a given task what you want to gain from the ActiveXML framework.
    The framework strives on abstraction and allows for abstraction the rule that one already defined via the framework. So if you have written any code via ActiveXML that itself can be bound to a XML-name and become a reusable component. , IO
    Given complete type abstraction, ActiveXML integrates and fully uses the power of reflection to provide seamless integration with detached systems and offers intelligent configurable auto discovery mechanism on integrating such framework in the common environment.
    Collaboration of components is also done on the abstracted level, type or even specific framework functionality does not matter across the board when using with other otherwise seemingly tough to integrate components.
    The framework is evolving and I have a large list of systems, APIs and frameworks to be incorporated and "activate" via ActiveXML.

    At this moment it has:

    Threading, Reflection, Flow, Conditions, Comparisons, JDBC, JavaMail, NET, IO, XML, XSL, Hibernate, Struts, Servlets, Console, Collections...

    I am working on an extensive documentation that covers components in details, as well as syntax, API and all the works.

    If I can get a business problem from you, I can show you the benefits of ActiveXML solving such.

    Also feel free to get involved in the project at http://activexml.dev.java.net

    I apologize for the typos, please point out anything that is unclear.

    Cheers,

    Art Yegorov
  4. RDF/OWL[ Go to top ]

    I think that the suggestion for RDF/OWL was for the syntax of your markup. The way the XML tags are defined and authored.

    For example:

    <jdbc-statement datasource-id="someDB">

    would be

    <jdbc-statement rdf:ID="someDB">

    OWL puts an ontology layer on top of rdf. Thus, jdbc-statement is a type that you have defined somewhere. As with java objects an OWL type has attributes and an inheritance hierarchy. (there are some cool type tricks that OWL lets you define such as equivalency classes, union classes, etc... there are also similiar things for the attributes themselves)

    It gets really interesting when other models begin extending your existing models. It might add an extra dimension of flexibility to your definitions.

    If you've already spent some time with RDF/OWL, my apologies. If you haven't you might want to. Maybe I need to get involved :) I have a project (not released to the public yet) that shares some aspects w/ yours.


    Regards,
    Tony Sintes