The dna user interface

[romney]

I find this project very interesting.

I would very much like to get some more details about the dna views and the future user interface. Are there any developers currently working in this area? This is a very important part of the project from my point of view that is why I am asking.

[rhauch]

Unfortunately nobody is working on those areas at the moment, although there's been some interest. The initial release (planned for next month) is focusing on the sequencer system, and we need to choose whether to then focus on the federation system or the views/UI. Gonna be a tough decision.

Care to elaborate on your needs?

[romney]

Most of all I am interested in getting a feeling of how to use jboss dna and where you are heading. Having a vertical implementation of the system would help providing beneficial knowledge of the entire concept. It would give a better idea of what you are trying to accomplice and this way help me to get a better understanding. Providing a user interface would also make is easier for me to test and play with the system.

What I am hoping for is a system that can understand the nature of my different artifacts (rules, services, processes... all the ingredients of SOA) and help me handle some of all the relations and dependencies between my artifacts. Of course, I will most likely have to define most of the relations and dependencies manually but all help is appreciated. This also means that being able to add metadata manually and define relations and dependencies between artifacts is very important. This kind of work will require a very productive and user friendly user interface that should be usable by technical as non-technical people.

Anyway, I hope you will consider focusing on the user interface and leave the federation part for later. Of course, this part is very important but I believe that it is easier to understand from a conceptual point of view.

Additionally, having a slim vertical implementation would make it easier for newcomers to join and help out in area of interest.

[moj0002]

I agree that a UI would be convenient but on the other hand the JCR API should allow us to fairly quickly create some sort of user interface that we could use meanwhile. Being able to POC an federation solution would be a great driver for us. We have metadata located in many repositories/applications and being able to show the benefits of federation and how you can expand and expose metadata knowledge in a controlled way by adding repositories one at a time as they are getting JSR-170 compliant seems very appealing. Having a roadmap for an end state allows us to concentrate on one metadata community at a time with the confidence that we are building an information knowledge base one brick at a time.

[rhauch]

These are both excellent feedback, and the differing views are indicative of what we've seen from others.

I do agree with romney, tho, about the advantages of having an implementation that covers more of the architecture but perhaps with fewer features in each area. So even if we do the views and UI first, we'll get that working and move on. Or, if we do federation first, we'll get that working to some degree and move on. Then, we'll circle back over time and make everything richer. Of course, the challenge with this approach is the risk of doing too little in any area, so we'll try to keep our balance.

Feel free to offer suggestions on the needs, requirements, use cases, or even design ideas for each piece.

@moj0002, can you list some of the repositories/applications (or describe them if they're proprietary) that you'd be interested in federating? Are they read only, or do they require updates? Are they transactional? XA-compliant?

[moj0002]

We have 3 types of sources I can imagine would be great to integrate.

Type 1: Existing applications that are not aware of JSR and I would have to build a JCR bridge for. Examples I can imagine are COTS applications for ETL, Reporting and analysis, Messaging, EII, EAI, SOA and Versioning. If you are interested in the vendors let me know and I can send them to you.

Type 2: resources you probably will provide adapters for: registries like UDDI, databases and JSR-170 compliant repositories.

Type 3: New repositories I will create and populate using jackrabbit: this would include business metadata, technical specs, database population specs, MS Visio diagrams, MS Excel files. ErWin models SLAs, Historical KPI, random thoughts.

We also have models and common file types I imagine you would be able to support but I am not sure if the DNA system repository is supposed to store these artifacts or only hold metadata about the sources being integrated and their relationships. These types would be: WSDL, XSD, UML but maybe they have to be in their own repository, not sure.

I do not know if you would provide access to the MetaMatrix repository as a source or you would takes the models and shred them directly into the DNA repository. Either way, we would like to be able to expose the models.

I imagine all of the sources to be read-only. We would not be the SMEs and our role would just be to expose metadata in a consistent fashion.

Type 3 probably has update capabilities, I can imagine adding new information to existing data but it could be done outside DNA maybe a custom JCR app only available to certain administrators and only targeting one repository at a time. In the future it might be great to be able to use DNA to push information into specific repositories but for now I would not worry about it.

I cannot imagine us having any XA needs in the foreseeable future.

The most important early source integration for us would be:
MetaMatrix models, JSR compliant repositories and relational databases
File types shredded into a repository would be XSDs.

Having the UI would absolutely be great too; somehow people do not get too excited looking at a bunch of java code and xpath expressions.

[rhauch]

That's excellent information - that's for sharing. I would be interested in hearing about the specific vendors (email is my username at jboss org).

I'm not sure whether it's better to provide access to the MetaMatrix repository (via a DNA connector) or to put the models directly into a JCR repository. Either would work well, but it depends on where the MetaMatrix team wants to take the product.

DNA does uses one JCR workspace where it stores metadata about itself under the "/dna:system" branch. I don't think we'd want any generated content going there. But either way, we're working to get the sequencer configs to specify where to write the output, whether to the same place as the content being sequenced (if allowed by the node types), or to a parallel workspace, or to an altogether different location. Not sure what the best default should be.

That's again for the great input!

[moj0002]

I have looked around to get a feel for where the future is going as far as accessing contents. It seems like many vendors are leaning towards REST / RDF and ATOM type communications. REST seems very appealing. I am not sure what JCR 2.0 will bring and there seem to be some discussions within that working group too. What are the thoughts around access protocols and access APIs for DNA?

[rhauch]

I agree that REST is very promising and that it would add great capability for using a repository. And it should be sufficient for remotely accessing DNA (see the Publishing Server on our architecture).

I also like AtomPub a lot (which is RESTful), but my only issue with AtomPub is that it doesn't really have any concept of hierarchy - everything is very flat. That would work well in repositories that were intentionally constrained, but that poses a problem in a JCR world where some repositories will make use of the hierarchy.

[rhauch]

I just added DNA-55: REST-based API for remote access and usage. Feel free to comment on it.

[romney]

I looked at DNA-55 and I am considering, if the time and skills allow me, helping out with the user interface related layers. What would be the 'right' starting point? I am thinking in terms of specific DNA views, DNA analyzer components and others to ensure mapping of the current implemented features. Furthermore, it would be great if someone could elaborate a bit more on the desired choice of technologies and architectural consideration. What would be the right choice of technologies to generate the user interface for the JBoss DNA? It would also be great if someone could describe the architecture of the DNA web application and supporting components in more details.

[rhauch]

Just to be clear, DNA-55 deals more with the REST-ful server. I'd say the first part would be to figure out what the API actually looks like. Do we use Atom Pub Protocol? Or GData? Are there alternatives? The REST-ful server basically exposes an HTTP-based service, using the views.

The view system should probably separate the definition for selecting the graph needed to build a view, starting with the node that the user wants to see (e.g., web service, Java class, database table, etc.), from the definition of the form/template for how that graph is to be presented (e.g., build a HTML fragment, XML fragment, FLEX fragment, JSF fragment, etc.). This would allow a client to request different forms for the same object.

As far as the web app, we should probably build on Seam and could consider a UI later based on either JSF or FLEX. Like the REST-ful server, it would make use of the view system.

I'm working on the Getting Started document for the 0.1 release, which goes into a little more detail about the views, REST-ful server, and web app components.

[romney]

I believe that FLEX would be the preferred choice because it would support a dynamic user interface which will support a very expressive type of user interface. I believe html/Ajax have some limitation in this area especially when dealing with large amount of data/information.

Unfortunately FLEX does not support REST out of the box which is a problem in regards to Atom Pub Protocol/GData. An alternative way is SOAP. Not sure about your preferred choice of technologies.

The bottom line is that I believe that the project have to decide between front-end technology and communication protocol.

[jpav]

I believe that FLEX would be the preferred choice because it would support a dynamic user interface which will support a very expressive type of user interface.

I agree. All of the other technologies I've been looking into seem to require some sort of compilation (usually due to the server-side logic), which would complicate providing domain-specific views.

Unfortunately FLEX does not support REST out of the box which is a problem in regards to Atom Pub Protocol/GData. An alternative way is SOAP. Not sure about your preferred choice of technologies.

The bottom line is that I believe that the project have to decide between front-end technology and communication protocol.

My understanding of what constitutes a RESTful application may be incorrect, but I understand this to be more of an approach to how the interface is designed between the client and server, regardless of the underlying web technology. I'm not sure whether I understand why FLEX doesn't support REST (or why it's a problem in particular with Atom pub). Could you expound?

[romney]

My understanding of what constitutes a RESTful application may be incorrect, but I understand this to be more of an approach to how the interface is designed between the client and server, regardless of the underlying web technology.

I believe that you are right in this definition.

I'm not sure whether I understand why FLEX doesn't support REST (or why it's a problem in particular with Atom pub). Could you expound?

From my understanding Flex does not support all the required http methods, especially put and delete, which is required by Rest/Atom Pub based solutions. Another issue is that it is not possible to extract HTTP status code from a response if anything goes wrong. However, I believe that there exist projects which have implemented alternative http supporting client which might solve the indicated issues.

Anyway, I should probably have stated in my previously response that if we go with the Flex solution we will have to investigate various solutions to implement e.g. the Atom Pub.