Recently the mainstream of application frameworks has shifted from the component-oriented one that pursues the flexibility (like Spring Framework) to the one that compels a certain programming model and aims to improve the ease of development and the agility (like JBoss Seam or Ruby on Rails). I think that there is a problem respectively of them. The former, component-oriented application framework becomes complex easily. It is difficult to maintain a consistent programming model, and the number of components increases, management becomes very troublesome. The latter, programming model-oriented application framework doesn't often have flexibility. The division of application tiers compelled by these frameworks is rough. The application, like enterprise mainstay application, consists of tens of thousands of components, tens of other party of communication and protocol and several kinds of presentation really requires the flexibility in functional change. Jazzmaster, SOA for Java Application, is the answer to both problems. Now, Jazzmaster 1.0.1 has been released. Tutorials, example applications, documents and source code are available at the project website: http://code.google.com/p/jazzmaster/ I'm looking forward to feedback from you!
- Posted by: Eiichiro Uchiumi
- Posted on: April 23 2009 09:58 EDT
- Re: A new app framework: Jazzmaster, SOA for Java Application by Casual Visitor on April 24 2009 15:18 EDT
- Re: A new app framework: Jazzmaster, SOA for Java Application by Eiichiro Uchiumi on April 25 2009 11:02 EDT
- Re: A new app framework: Jazzmaster, SOA for Java Application by Dan Evans on April 29 2009 17:49 EDT
You need to provide at least a short description of and introduction to your framework. What are the core features that distinguish it from other frameworks? What does the code look like? ...
Hi, The following documents might help you understand Jazzmaster. Motivation http://code.google.com/p/jazzmaster/wiki/Motivation Jazzmaster 30 Minute Cooking (In particular, the last section) http://docs.google.com/Doc?id=dctjgx8b_2cccntsf2 If you need a little bit detailed document, for example, architecture description or reference guide, I'll write it in a few weeks. Could you report the concrete information that you want as a issue? http://code.google.com/p/jazzmaster/issues/list Regards. Eiichiro
You may want to look at the Jt Pattenr Oriented framework. It addresses some of the issues that you bring up: http://freedom.lunarpages.com/Jt/ The framework addresses the following goals and requirements: A) The pattern oriented framework implements and facilitates the implementation of well-known design patterns like GoF design patterns and J2EE Design patterns. The framework itself is conceived and implemented based on design patterns (from the ground up). The framework facilitates and accelerates the implementation of applications based on design patterns. B) The framework architecture is based on a messaging design pattern: framework objects are able to interchange information and perform computations by sending, receiving and processing messages. A messaging API provides strong encapsulation and loose coupling; framework components can be easily plugged into complex framework applications using a “lego/messaging” architecture. The framework takes full advantage of the power and simplicity of the messaging design pattern. C) The framework lego/messaging architecture provides transparent access to remote components: remote framework objects is treated as local objects. Design patterns implemented by the framework (adapters, remote proxies and facades) make this posible by hiding the complexities associated with remote APIs. D) The framework provides transparent integration with other technologies via framework adapters, proxies and the implementation of related design patterns. These technologies include BPM, DAO implementations, MVC implementations, EJBs, JMS, XML and Web Services. E) The framework is designed to be lightweight and fast in terms of performance (low overhead). F) The framework messaging/lego architecture should improve and simplify design/development efforts. There should be a tight correspondence between UML design diagrams and the framework messaging based applications and components needed for the implementation. Ideally, the framework provides wizards and automated capabilities for generating framework applications. Framework components should be easily added to BPM process diagrams. In future versions of the framework, it should be possible for applications to be generated directly from the UML design diagrams. G) The framework messaging architecture facilitates testing and debugging efforts. The framework provides capabilities for testing components independently (each component as a unit) by sending messages and verifying the reply (output) messages. H) In order to provide additional productivity benefits, the framework is integrated with open source IDEs.