|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 57
Messages: 57
Messages: 57
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Jt - Java Pattern Oriented Framework (Jt 4.5)
Jt4.5 has been released. Jt is a pattern oriented framework for the rapid implementation of Java applications. Jt has been utilized in several large mission critical systems. Jt implements many well-known patterns including Data Access Objects (DAO), GoF design patterns and J2EE patterns.
Jt4.5 features several enhancements to the Jt components and a version of the Jt Portal (JtPortal). The Jt Portal is a reference web application implemented using the Jt framework.
Jt4.5 also features portal components and capabilities:
- Chat module/application
- Forum module/application
- Security/Role capabilities
- Enhanced documentation http://freedom.lunarpages.com/Jt/Jt.htm
- JtPortal 1.5. This is a portal application built on top of the Jt Pattern Oriented framework.
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.
An older version of the framework has been rated jar top 25.
For additional information please refer to
http://freedom.lunarpages.com/Jt
http://freedom.lunarpages.com/JtPortal/
Post your questions there.
|
|
|
Message #329005
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Does anybody take this seriously?
How many times do these people keep posting on TSS?
Have you seen the code? Are you ever going to use it?
BTW - I believe this "framework" was put together by some consultancy. I think they want to be the next Spring but just don't have the talent.
|
|
|
Message #329006
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does anybody take this seriously?
I agree. I do not see the point of this. Similar solutions already exist. Enough with the science projects already. If it works in your shop, it doesn't mean that it is ready for wide spread adoption.
|
|
|
Message #329011
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Jt - Java Pattern Oriented Framework (Jt 4.5)
In future versions of the framework, it should be possible for applications to be generated directly from the UML design diagrams.
genius! can't wait...
|
|
|
Message #329013
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does anybody take this seriously?
Totally agree. The worst thing is that a younger programmer might see post this and end up thinking it's a good framework.
|
|
|
Message #329018
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does anybody take this seriously?
Totally agree. The worst thing is that a younger programmer might see post this and end up thinking it's a good framework.
BTW it is none of my business, but who the hell are you (Turing nominee?) to judge some one else code or framework.
Every body has the equal right to market their share of intellectuality, and so does the JT folks.
|
|
|
Message #329021
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does anybody take this seriously?
Maybe, but the following excerpt doesn't exactly make me want to rush out and hash stuff...
5.4. JtHashTable
This class implements a hashtable and associated messages (JtPUT, JtGET, JtCLEAR, JtGET_KEYS, etc.). The JtGET_KEYs message returns a JtIterator that can be used to traverse the collection.
public static void main(String[] args) {
JtFactory factory = new JtFactory ();
JtMessage msg1;
Integer count;
// Create an instance of JtHashTable
factory.createObject (JtHashTable.JtCLASS_NAME, "hashtable");
factory.createObject (JtMessage.JtCLASS_NAME, "message");
factory.setValue ("message", "msgId", JtHashTable.JtPUT);
factory.setValue ("message", "msgContent", new Integer (1));
factory.setValue ("message", "msgData", "one");
// Add an object to the hashtable
factory.sendMessage ("hashtable", "message");
factory.setValue ("message", "msgId", JtHashTable.JtGET);
factory.setValue ("message", "msgData", "one");
System.err.println ("JtHashTable(JtGET):" +
factory.sendMessage ("hashtable", "message"));
factory.setValue ("message", "msgId", JtHashTable.JtPUT);
factory.setValue ("message", "msgContent", new Integer (2));
factory.setValue ("message", "msgData", "two");
factory.sendMessage ("hashtable", "message");
factory.sendMessage ("hashtable", new JtMessage (JtObject.JtPRINT));
count = (Integer) factory.getValue ("hashtable", "size");
System.out.println ("count:" + count);
factory.setValue ("message", "msgId", JtHashTable.JtREMOVE_OBJECT);
factory.setValue ("message", "msgData", "two");
factory.sendMessage ("hashtable", "message");
count = (Integer) factory.getValue ("hashtable", "size");
if (count.intValue () == 1)
System.err.println ("JtHashTable(JtPUT):GO");
else
System.err.println ("JtHashTable:FAILED");
factory.sendMessage ("hashtable", "message");
factory.removeObject ("hashtable");
}
|
|
|
Message #329038
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does anybody take this seriously?
Totally agree. The worst thing is that a younger programmer might see post this and end up thinking it's a good framework.
BTW it is none of my business, but who the hell are you (Turing nominee?) to judge some one else code or framework.
Every body has the equal right to market their share of intellectuality, and so does the JT folks.
Looks like you offended the only user of the framework
|
|
|
Message #329054
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Jt - Java Pattern Oriented Framework (Jt 4.5)
Gentlemen,
I would recommend having a civil discussion based on technical
facts/merit. I agree with the comments regarding equal access and freedom of expression.
The earth doesn't become flat/round to suit someone's opinion.
Gentlemen gather your facts and bring them to the discussion.
Just a couple of comments, to start:
The Jt framework is been utilized for many companies including IBM, Hasbro,
Power generation companies, etc. This includes several mission critical
systems (internet, power plan systems, etc).
A better example to illustrate the use of Jt would be the one that follows. It demonstrates some
of the Jt pattern oriented framework capabilities (4.7):
- Rest service invocation. The framework lego/messaging architecture provides transparent access
to remote components: remote framework objects are treated as local objects
- Automatic conversion of XML messages into Java components
- Automatic propagation of remote exceptions.
- Built-in access manager responsible for blocking/enabling access to remote components
- All framework components can be exposed/plugged as REST services/resource provided
that access has been granted.
This REST integration is so simple thanks to the Jt messaging design pattern:
public interface JtInterface { Object processMessage (Object message);}
This design pattern is the basis for the lego achitecture that provides
transparent access to remote components which can be plugged into the application.
It reduces complexity by maximizing encapsulation and minimizing coupling (one single method).
/**
* Demonstrates the messages processed by JtRestService
*/
public static void main(String[] args) {
JtFactory factory = new JtFactory ();
JtMessage msg = new JtMessage (JtObject.JtACTIVATE);
Object reply;
JtRestService service;
Date date;
// Create an instance of JtRestService
service = (JtRestService) factory.createObject (JtRestService.JtCLASS_NAME);
// Assign the URL for the REST service/resource
service.setUrl("http://localhost:8080/JtPortal/JtRestService?className=Jt.examples.HelloWorld&msgId=JtHELLO");
// Invoke the remote service (Make the REST request to access the remote resource/service).
reply = factory.sendMessage (service, msg);
// Check for exceptions. Remote exceptions are automatically
// propagated by the framework.
if (service.getObjException() == null)
System.out.println ("Reply:" + reply);
service.setUrl("http://localhost:8080/JtPortal/JtRestService?className=Jt.examples.DateService&msgId=GET_DATE");
// The reply message is automatically converted to
// the appropriate Java type by the framework (XML/object conversion capabilities)
date = (Date) factory.sendMessage (service, msg);
if (service.getObjException() == null)
System.out.println ("Reply date:" + date);
// The framework access manager is responsible
// for granting/blocking access to remote components.
service.setUrl("http://localhost:8080/JtPortal/JtRestService?className=Jt.portal.service.Logging");
reply = factory.sendMessage (service, msg);
}
}
The configuration is very simple as well:
web.xml
<servlet>
<servlet-name>JtServlet</servlet-name>
<servlet-class>Jt.servlet.JtServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>JtServlet</servlet-name>
<url-pattern>/JtRestService</url-pattern>
</servlet-mapping>
Jt.properties:
Jt.security.JtAccessManager.classAccessList:Jt.examples.HelloWorld,Jt.portal.service.*
In summary the invocation requires a couple of line of code and very
few extra lines in the configuration files:
service = (JtRestService) factory.createObject (JtRestService.JtCLASS_NAME);
service.setUrl("http://localhost:8080/JtPortal/JtRestService?className=Jt.examples.HelloWorld&msgId=JtHELLO");
reply = factory.sendMessage (service, msg);
BTW, the client application (Java) requires one jar (Jt.jar ~ 300k)
In return you get the following benefits:
- Rest service invocation. The framework lego/messaging architecture provides transparent access
to remote components: remote framework objects are treated as local objects
- Automatic conversion of XML messages into Java components
- Automatic propagation of remote exceptions.
- Built-in access manager responsible for blocking/enabling access to remote components
- All framework components can be exposed/plugged as REST services/resources provided
that access has been granted.
This REST integration is still preliminary (4.7). Other remote APIs (AXIS/EJBs/Ajax) can be used in a similar fashion.
Feel free to send technical questions and feedback to the Jt project team:
http://freedom.lunarpages.com/Jt/
|
|
|
Message #329069
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Jt - Java Pattern Oriented Framework (Jt 4.5)
// Assign the URL for the REST service/resource
service.setUrl("http://localhost:8080/JtPortal/JtRestService?className=Jt.examples.HelloWorld&msgId=JtHELLO");
with all respect, this is not REST
Just using http for remoting does not make it REST.
|
|
|
Message #329070
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Design and testability questions
1. Why are you using casting from one "kitchen sink" method all the time? I suppose we have generics in Java since 2004.
2. I browsed through your code and I haven't seen a single JUnit test there. Is this done on purpose? I hardly can imagine a system employed in a mission critical environment without unit tests.
3. Homegrown logging also seems to be a good option - especially when we have widely accepted standard solutions. Why was this done?
|
|
|
Message #329086
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Jt - Java Pattern Oriented Framework (Jt 4.5)
We appreciate all the good questions and comments. Please keep them coming.
The REST integration is still preliminary work (4.7 version).
Once the REST integration is released things may become more clear.
I'll also check with folks more expertise in this area.
I'll like to know what we are missing.
I think we have all the REST ingredients:
Resources: Remote component can be accessed
State: The client changes state with each invocation (see example)
In terms of REST Web Services:
"REST Web Services Characteristics"
* Client-Server: yes
* Stateless: yes
* "Uniform interface: all resources are accessed with a generic interface." In our case we use the Jt messaging interface.
* "Named resources - the system is comprised of resources which are named using a URL. In our case the component class or name may be used
* Interconnected resource representations - the representations of the resources are interconnected using URLs,
thereby enabling a client to progress from one state to another.
The client changes state with each invocation.
http://localhost:8080/JtPortal/JtRestService/className=Jt.examples.Parts
and later (after receiving the XML reply)
http://localhost:8080/JtPortal/JtRestService/className=Jt.examples.Parts?msgContent=00453
Also keep in mind that as someone mentioned the web is a REST system.
We may need to refine/tune the terminology.In any case the framework implements
web services. It is able to access remote resources and retrieve/change
their representation. BTW Jt also integrates with AXIS web services.
It offers several options in terms of web services.
service.setUrl("http://localhost:8080/JtPortal/JtRestService?className=Jt.examples.HelloWorld&msgId=JtHELLO");
// Invoke the remote service (Make the REST request to access the remote resource/service).
reply = factory.sendMessage (service, msg);
|
|
|
Message #329087
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Does anybody take this seriously?
I've watched release message after release message appear here on TSS. I've always thought the approach of this framework was very weird, but now I've taken the time to look at it a bit closer, inspired by the JtHashTable example.
I've got to say, I cannot fathom how anyone can use this without hitting themselves over the head with a hammer.
Using this framework, you have to give up all advantages of java (static typing, self documenting code, ...) and only "gain" the disadvantages of string based programming. The hastable example really shows this very well. I mean, how much more complicated can you make adding something to a hashmap than this? Not even in the worst EJB 2.1 days was anything as verbose and ugly as this.
I guess the only advantage I can see in the Jt framework is that you only have to learn about a few methods (factory.setValue, sendMessage, processMessage, ...), but of course, you'll have to learn all the string based arguments instead. Guess which ones your IDE can't autocomplete for you.
I'm sorry to have to be so direct, but I guess I just fear the day when some idiot in our organisation would want to use this :)
|
|
|
Message #329088
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Design and testability questions
Folks,
Thanks again for the good questions and insight!
Once the Messaging design pattern is understood everything falls
into place (or I should say the pieces fit into place like a
Lego set):
Public Jt Interface {Object processMessage (Object Message);}
Process a message and return a reply object. A single interface
that makes individual framework components fit together.
There are many ramifications to this messaging design pattern.
I've added sections of the documentation to illustrate my points.
Testing (input/output messaging):
"The framework provides capabilities for testing components as independent units
by sending messages to the component and verifying the expected reply messages."
You are right. These systems need unit testing. Because of messaging interface
"most" of the unit testing was done as black box testing. This done is with a testing
harness as follows:
For example:
replyA = sendMessage (componentA, messageA1)
// Check reply A
replyA1 = sendMessage (componentA, MessageA1)
// Check reply A1
.....
replyN = sendMessage (componentN, messageN)
// Check reply N
replyN1 = sendMessage (componentN, MessageN1)
// Check reply N1
This is just an example to illustrate my point.
Complex components can be divided appropriately and each component tested.
Notice this is black box kind of testing (inputs and outputs). Notice
that changes in the component should not break the testing harness.
Even when new messages (new message Ids) are implemented.
Obviously the hardness is part of the specific application. On the other
hand, I can see your point regarding the testing of the Jt framework itself.
In terms of the Jt core itself I agree with you: We should include an Unit Testing
hardness based on JUnit with each release. It will use the approach described above (or similar).
with each release.
We plan to get it done as soon as possible. The core Jt is very stable
so we tend to take it for granted. It has been around for many
year. We have meant to do create a JUnit testing harness for the core itself but never got around to do it.
On the other hand, the core Jt framework (~300K) has no dependencies (besides Java itself).
This has been done on purpose to keep it light and simple. The core functionality requires
One Jar (Jt.jar). This is also one of the reasons why JUnit is not inside the core Jt itself.
Jt Logging:
The core Jt provides very complete logging capabilities:
"The framework provides built-in logging/debugging capabilities.
Messages between framework objects via the messaging API are automatically logged.
This simplifies the debugging and testing tasks."
I agree with you that it was a good decision (because of the size and the dependencies
and the fact that Jt has a complete set of logging features custom made for a messaging
framework).
One Jar is all that it takes. Also, Our logging capabilities are very complete
Because of the Jt messaging design pattern, the user can know exactly what messages
are being exchange between components without doing basically anything. The framework
automatically logs the messages being exchanged. No need to add a lot of print statements
to your code.
As I mentioned earlier, we didn't want many dependencies to keep it simple and light.
Also, the framework can be configured from a single resource file (Jt.properties).
On the other hand, other logging technologies can be easily plugged-in via
adapters and/or helpers.
In regards to Casting an Generics. It would be ideal.
Some of the code has been around for quite sometime. I'm afraid I'm not sure,
we'll have the bandwidth to make these changes. I'm sure that you will agree
that the functionality remains the same. Our main focus now is new apps, wizards,
automated capabilities for generating framework applications, BPM, Web Services/REST.
In summary once the messaging design pattern is understood:
Public Jt Interface {Object processMessage (Object Message);}
The pieces fit into places.
I hope that I was able to answers some of them.
Feel free to follow up with new questions.
Best Regards,
|
|
|
Message #329093
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Jt - Java Pattern Oriented Framework (Jt 4.5)
I don't mind people who are direct. I'm all for direct.
You are bringing your reasons and comments without
forgetting the good old golden rule. We appreciate
you comments. By all means keep constructive criticism coming so that the facts can come to bear.
I'm glad that you like the simplicity of the framework API:
-createObject
-setValue
-getValue
-sendMessage (Object, Message)
-removeObject
Keep in mind that this can be used for both local and remote
components. Remote components are treated as local object (via Proxys, Adapter, etc)
This is all possible due to the JtMessaging design pattern:
Public Jt Interface {Object processMessage (Object Message);}
This is the best part. Trust me. Once this is understood
all the pieces fit into place.
Notice that the input message and the reply message can be anything (Object).
It is no limited to Strings. Therefore I hope you realize
that the name String programming is not accurate.
It can be any type of Object: String, List, Collection, etc. You name it.
The framework doesn't place any limitation on this. In other words.
they don't have to be Strings. If you check the code you will see this.
It is true that the ID of the message is often String:
JtMessage msg = new JtMessage (JtObject.JtACTIVATE);
It doesn't have to be. It can be anything (Object type).
It is usually String because of the BPM integration.
Integers are more natural as message Ids but it
would complicate the BPM pieces. We have struggled a bit
with this issue.
In terms of static typing I have to agree with you. The message
object needs to be generic enough to fit any type of message.
This allows all component to fit together. In the real world
messages can be anything
You could limit the interface a bit by doing something like
the following:
Public Jt Interface {JtMessage processMessage (JtMessage Message);}
or
Public Jt Interface {MyMessageType processMessage (MyMessageType Message);}
This would limit the type of component that you could plug in.
There is trade-off. I can see your point.
In case of the HashTable example. I agree with you. It is not a very good example/demo
This is a very old version.
It doesn't really show the capabilities of the framework.
We need to fix it.
On the other hand, I added better examples (Web Services/REST
integration). I've included here an additional example dealing with Web Services
/Axis integration. These are better examples of what the framework is able to do.
It is a better illustration of the use of some of Jt design pattern: Adapter and Proxys.
package Jt.examples;
/**
* Demonstrates the use of the Jt Web Service Adapter (JtWebServicesAdapter/Axis).
*/
public class WebServicesExample {
private static final long serialVersionUID = 1L;
public static final String GET_DATE = "GET_DATE";
public static final String GET_DATE_TIME = "GET_DATE_TIME";
public WebServicesExample () {
}
public static void main(String[] args) {
JtObject factory = new JtObject ();
JtWebServicesAdapter adapter;
Date reply = null;
Exception ex;
JtMessage msg;
JtList col;
JtIterator iterator = null;
Long time;
JtProxy proxy;
// Create the Jt Web service Adapter
adapter = (JtWebServicesAdapter) factory.createObject (JtWebServicesAdapter.JtCLASS_NAME,
"service");
// Set the service url property (if it is not present in the resource file)
if (adapter.getUrl() == null)
adapter.setUrl("http://localhost:8080/axis/services/JtAxisService");
// Create a remote instance of the DateService class. The Jt Web service adapter
// can be used to create remote objects. A local proxy is returned.
msg = new JtMessage (JtWebServicesAdapter.JtCREATE_PROXY);
msg.setMsgContent("Jt.examples.DateService");
proxy = (JtProxy) factory.sendMessage (adapter, msg);
// Send a message to the remote DateService object
reply = (Date) factory.sendMessage (proxy, new JtMessage (WebServicesExample.GET_DATE));
ex = (Exception) proxy.getObjException();
// Display the reply unless an exception is detected
if (ex == null)
System.out.println ("Date:" + reply);
// Remove the remote object and the adapter instance
adapter.removeObject (proxy);
factory.removeObject(adapter);
}
}
The Axis deployment descriptor is the following:
deployment xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<service name="JtAxisService" provider="java:RPC">
<parameter name="className" value="Jt.axis.JtAxisService"/>
<parameter name="allowedMethods" value="processMessage"/>
<parameter name="scope" value="session"/>
</service>
</deployment>
I hope this makes sense. I look forward to any follow-up comments/questions
that you may have. If someone comes around asking to use messaging/messaging design patterns
you may want to consider it. If you have good reasons not to, we'll
love to hear them.
|
|
|
Message #329099
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Jt - Java Pattern Oriented Framework (Jt 4.5)
If someone comes around asking to use messaging/messaging design patterns
you may want to consider it. If you have good reasons not to, we'll
love to hear them.
For messaging, JMS is considered to be quite useful :-)
If I need more integration capabilities, then I'd use something like Apache Camel.
|
|
|
Message #329104
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Didn't catch the irony?
"The core Jt is very stable
so we tend to take it for granted."
Yeah, sure, how can it be stable if it hasn't got unit tests?
"I agree with you that it was a good decision (because of the size and the dependencies
and the fact that Jt has a complete set of logging features custom made for a messaging
framework)."
Didn't catch the irony? How, I ask again, how do you imagine integration of your so-called framework with e.g. some AppServer environment logging? And logging is just the tip of the iceberg.
"On the other hand, other logging technologies can be easily plugged-in via
adapters and/or helpers."
Uh huh, so I have to add a plugin to use log4j? Man, you are not alone in the universe.
"I'm afraid I'm not sure,
we'll have the bandwidth to make these changes."
So keep using Strings and casting. Good luck.
P.S. To TSS editors: please stop allowing people to put such kind of "frameworks" on the main site. Or, at least, tag them as "Don't try this at home".
|
|
|
Message #329105
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
One more thing
reply = (Date) factory.sendMessage (proxy, new JtMessage (WebServicesExample.GET_DATE));
ex = (Exception) proxy.getObjException();
This exception handling is World Class - you even offer exceptions as Objects. Congratulations!
|
|
|
Message #329106
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Commentary
Dan,
Your frameworks as has been previously mentioned by others goes completely against the core features, strengths and natural way to use and build with java. Something such as creating a map and putting a value that would or should take around 2 lines becomes a screenful of text. Why ?
Why have you killed exceptions and replaced them with status codes. Returning an exception is not using exceptions to denote problems but rather you are using status codes. That is not java or OO but rather c, where one had no other choice.
Your framework has also killed the entire need for classes and types in java. In your examples one never sees a type with the actual meaningful available operations but rather one gets a nasty proxy ? Why ???
Why are there so many String constants all over the place ? Your example has more magic string constants than the entire JDK!
|
|
|
Message #329108
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Jt - Java Pattern Oriented Framework (Jt 4.5)
Dan,
I won't be quite as venomous as some of the other responders, but I can say that this not a framework I would use for my projects. You have designed a 'generic do stuff machine', I am willing to bet that at least 50% of the people attacking you have at one point done the same, I know I have. One crazy moment where your mind goes... "Hey, I can probably define this entire system in XML", and 6 months later, you are describing the 100th 'approved workaround' to some confused looking contractor.... been there.
These hyper-generic frameworks, are effectively just poor-mans programming languages, usually they expose enough of the underlying language to be Turing complete, and then the author comes some place like this and shouts... "Check out my framework... you can do *anything* with it!". Sure, can do anything in pure Java too, and I am comfortable with it. Can do anything in brainfuck or whitespace also, but I am not so comfortable with those, or your framework.
Honestly, having methods like public Object processMessage(Object object), just screams '99 to me. A method I can send anything to and get anything back, but my client is closely coupled to the implementation anyway because I have to hard code the cast of the return object before I can do anything useful with it.
Doesn't solve any of my problems, sorry.
|
|
|
Message #329127
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Jt - Java Pattern Oriented Framework (Jt 4.5)
I checked your link. I like the messaging being done
among some of the main architecture components.
In terms of EJBs, you might want to take a look at the J2EE design patterns
implemented by Jt. I have to agree with some of the comments made by other folks regarding
EJBs. The EJB/Jt integration and Jt/J2EE design patterns deal with some
of these issues. I'm not sure. You may be already doing this (j2EE design patterns).
You can use POJOs with the framework. I added an example to this message.
It true that most of the Core component implement
a single Interface:
Public Jt Interface {Object processMessage (Object Message);}
In the strict sence of the word the Jt core components are not POJOs.
This is quite alright. POJOs are supported.
import java.util.LinkedList;
import Jt.JtFactory;
import Jt.JtMessage;
import Jt.xml.JtXMLHelper;
// Convert an Object into its XML representation (simple demo of POJOs)
public class Pojo {
JtFactory factory = new JtFactory ();
public Object processMessage(Object message) {
JtMessage msg = new JtMessage (JtXMLHelper.JtXML_ENCODE);
JtXMLHelper helper = new JtXMLHelper ();
msg.setMsgContent(message);
return (factory.sendMessage(helper, msg));
}
public static void main(String[] args) {
Pojo pojo = new Pojo ();
LinkedList list = new LinkedList ();
list.add("one");
list.add("two");
System.out.println (pojo.processMessage(list));
//main.removeObject ("message");
}
}
This POJO takes advantage of the Messaging design pattern.
This example also illustrates the point that the framework
is not limited in any ways to dealing with Strings.
The following class illustrates the use of the Jt/J2EE Business Delegate.
The source code can be found at
src/ejb/Jt/ejb/examples/BusinessDelegateExample.java.
public static void main(String[] args) {
JtFactory factory = new JtFactory (); // Jt Factory
String reply;
JtBusinessDelegate delegate;
JtMessage msg;
JtProxy proxy;
String tmp;
Exception ex;
// Create an instance of JtBusinessDelegate (Jt implementation of
// the J2EE business delegate pattern)
delegate =
(JtBusinessDelegate) factory.createObject (JtBusinessDelegate.JtCLASS_NAME,
"businessDelegate");
msg = new JtMessage (JtWebServicesAdapter.JtCREATE_PROXY);
msg.setMsgContent(HelloWorld.JtCLASS_NAME);
// Create a remote instance of the HelloWorld class. JtBusinessDelegate
// can be used to create remote objects. A local proxy is returned.
proxy = (JtProxy) factory.sendMessage (delegate, msg);
//factory.setValue (proxy, "logLevel", "0");
//factory.setValue (proxy, "logging", "true");
factory.setValue (proxy, "greetingMessage", "Hello there...");
tmp = (String) factory.getValue (proxy, "greetingMessage");
System.out.println ("greetingMessage:" + tmp);
msg = new JtMessage (HelloWorld.JtHELLO);
// Send JtHello to the remote helloWorld object
reply = (String) factory.sendMessage (proxy, msg);
ex = (Exception) proxy.getObjException();
// Display the reply unless an exception is detected
if (ex == null)
System.out.println (reply);
// Remove the instance of JtBusinessDelegate and the proxy
factory.removeObject (proxy);
factory.removeObject (delegate);
}
I hope this answers some of you comments. Feel free to send
any additional comments.
|
|
|
Message #329129
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Jt - Java Pattern Oriented Framework (Jt 4.5)
I agree. Actually the framework has JMS adapters: messages can be interchanged via JMS queues in a transparent way. I also hope we agree that Jt is not limited to Strings in any way.
The Jt messaging interface is able to work at the component level:
Public Jt Interface {Object processMessage (Object Message);}
On the other hand, JMS is "mainly" suited for communication
between applications and large modules. You wouldn't use JMS
to glue components like Jt does. The overhead would be too high.
You bring a good point in terms of messaging.
You can use JMS messaging to glue applications and large modules
together. You can do the same with Jt (at the
component level where JMS wouldn't be practical).
On the other hand, Jt brings some of the same benefits that
JMS does. They use similar concepts (interchange of messages).
Jt is not limited to the application level.
Jt is not limited to JMS messaging either.
The main purpose of Jt is the rapid implementation of Java applications
The framework is able to integrate with many technologies (JMS, EJBs,
Web Services, DAOs, Struts, etc) using
the Jt lego/Messaging architecture.
I hope this makes sense.
|
|
|
Message #329133
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Jt - Java Pattern Oriented Framework (Jt 4.5)
Perhaps I need to explain myself a bit better.
Once the following messaging design pattern/interface is understood
all the pieces should fit into place:
Public Jt Interface {Object processMessage (Object Message);}
Notice that you have all the freedom that you need.
No restrictions at all. You just need to implement the interface above.
Not even that, if you need/want to use POJOs (as demonstrated earlier) .
Complete freedom.
Your components can use your favorite interfaces. The same thing that you
are doing today. Jt components interface with many technologies
(Struts, EJBs, JMS, Web Services, DOAs, Paypal APIs, DAO implementations, etc).
In terms of logging, there are several alternatives available.
Your components can use whichever one you happen to like best.
log4j for instance. As you can see, you don't need to add a plugin.
We happen to have our own complete logging capabilities
customized for a messaging framework. You can also
use Jt logging capabilities (standalone - logging system).
"The Jt Framework supports built-in logging and debugging capabilities.
Jt can be instructed to automatically log all the operations performed on
framework remote and local objects. This includes creating objects, setting attributes,
sending messages, loading attribute values from resource files, etc. This feature allows
the user to identify problems quickly and easily"
I hope you can see the reasons why we prefer to have our
own logging capabilities:
1) one Jar file for the core components (Jt.jar ~300k). No dependencies
2) one properties files (Jt.properties). All component can be managed from
this properties file (including logging capabilities).
3) It is customized to fit the needs of messaging framework
In terms of testing; of course the Jt core components has been tested. Of course there was code to do the automated testing of the core (here and there or perhaps lost somewhere after many years)
You raise a good point though. The Jt testing harness needs to be included
in the distribution. This should prove that the software is very reliable.
Several production quality apps run on top of the framework.
There are ramifications once the messaging design pattern is understood.
I hope you can see why junit is not really required inside the Jt core.
The testing of the individual components can be done as I
demonstrated earlier (messsaging/black box). Also reason 1 (above)
reply = sendMessage (componentA, messageA);
// check the reply message here
reply = sendMessage (componentA, messageB);
casting: If someone finds a better way to implement the messaging
we'll be thrilled to hear it:
Public Jt Interface {Object processMessage (Object Message);}
I'm afraid that in the real world messages can be anything.
The interface above reflects this fact.
By the way you can limit the interface and still use the messaging design pattern:
Public Jt Interface {MyMessageType processMessage (MyMessageType message);}
This avoid some of the casting. On the other hand, it limit the interface.
String: this is a misconception. No accurate according to the facts. There is no String limitation
In terms of irony. I'm not sure it helps the discussion.
We should concentrate on getting to the facts. Let's be
direct as someone else put it. Therefore ....
In terms of restricting freedom of expression. Not a wise
idea, I'm afraid. It never worked.
Also, nobody has the monopoly on intellectuality
as someone else mentioned.
In summary we should not deviate from our old good golden rule.
Let ideas succeed/fail on their on merit.
|
|
|
Message #329137
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Jt - Java Pattern Oriented Framework (Jt 4.5)
Good point! It looks like the cast is not really needed:
ex = proxy.getObjException();
This looks better. The attribute Exception used to
be Exception or Throwable as far as I can remember.
I'm not sure why/when it was changed. I may add a issue/enhancement
on this. There might be a good reason for the cast. I'm not able to see it right now.
At least I should be able to get an explanation
for the extra cast.
I'll go over the exception handling mechanism in detail
since it has been mentioned a couple of times.
I hope I was able to answer some of you concerns around
logging and unit testing. There are reasons behind the technical decisions that were made.
Again, the mesaging design pattern needs to be understood
in order for the other pieces to fit (including the exception handling):
Public Jt Interface {Object processMessage (Object Message);}
By the way, there are folks with extensive industry experience behind
the technical ideas. The usual backgrounds Computer scientists, engineering, architectute, University
professors. Thanks for the comments.
Also, I believe we should say what we mean and..........
|
|
|
Message #329143
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Pattern oriented framework?
Pattern oriented framework?
"The pattern oriented framework implements and/or facilitates the implementation of well-known design patterns like Gang Of Four design patterns (GoF) and J2EE Design patterns"
What is there to facilitate in the space of well defined OOP design patterns? I don't understand.
And this is a new release and as far as I can tell from the docs, this is based on prior java5?
|
|
|
Message #329144
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Commentary
Miroslav,
You raise very good points regarding exception handling, proxy design pattern, etc!
I have to agree with you. This new messaging approach challenges conventional wisdom.
You bet it does. The pieces should start to fit once the messaging pattern/interface piece is understood:
Public Jt Interface {Object processMessage (Object Message);}
Folks will start thinking in terms of messaging. An unconventional approach and yet a more natural one.
For instance, it should help explain "why" and the other related questions:
1) Does it work ?
2) Why/how does it work ? (this is related to some of specific comments)
3) How does it compare with the other available solutions ?
- In regards to the first question. The answer is yes. There are several production
quality systems running on this messaging technology. There are also several reference applications included with the distribution.
- Real World messaging. As to why, the real world follows a messaging paradigm. When you watch TV, when you talk to a friend. Right now, I'm sending you a MESSAGE. Since computer applications seek to model the real world, it should easy to see why applications should be written using a messaging approach.
It is only NATURAL. It seems to be a better representation of the real world. Once people get this and start thinking in terms of messaging, everything starts to make more sense. Everything starts to fit into place.There are ramifications. It challenges conventional wisdom. Yes It does.
- Encapsulation and coupling. Hopefully we've been able to illustrate some of the advantages
of the messaging approach (number 3 above) and why it is natural.
The messaging approach also provides simplicity, stronger encapsulation and looser coupling.
it seems to maximize encapsulation. It also minimizes coupling. There is one
connection between the components (one method) .It seems to be an optimal solution in terms
of encapsulation and coupling (one interface).
This also helps explain number 2 above (why).
- Exception Handling (within the Jt Messaging framework)
"The Jt framework propagates exceptions among its components. This is very useful.
For instance, an exception caused during a remote component invocation may need to
be propagated all the way to the client graphical user interface. Jt is able to handle this
automatically."
Exception handling should make more sense once the messaging approach is understood:
Public Jt Interface {Object processMessage (Object Message);}
Messages can be sent and processed via the interface above.
The next natural question here is: how do I handled exceptions within the messaging approach/interface ?
There are several approaches that can be taken. I'll describe one that is used widely.
The approach is fairly straightforward. The Java exception is stored in the object that receives/processes the message. Standard Java Exceptions are used. This not a status code. For instance:
If there is an exception while processing messageA, objectA is responsible for
storing it (objException attribute).
reply = sendMessage (objectA, messageA);
if (objectA.getObjException () != null) {
// An exception was detected while
// processing messageA (objectA)
// Do something with the exception. Propagate it
// if needed.
}
The following would be a typical scenario: An application updates a database via a JSP/Struts gui.
JSP/GUI ------->JtStrutsAction --- message -> Business Object --- message -> JtDAO --- message -> JtJDBCAdapter
<-exception- <-exception-- <-exception--
Messages go from the JSP/GUI all the way to the JDBC adapter using the messaging approach.
If everything goes well, the database is accessed/updated via this approach.
If an exception occurs (database layer for instance).,the exception can be propagated
to all the messaging layers above. This is the general idea:
- The JDBCAdapter stores the exception
- The DAO checks for an exception after sending a message.
Updates its own exception attribute (propagates the exception).
- The Business Object checks the exception after sending the
message to the DAO layer. It decides what to do with the exception.
If needed, an exception can be propagated to the layer above.
It is usually propagated.
- The Struts component checks for exceptions. It is displayed
by the GUI.
In general terms this is what happens. This fits the messaging/lego architecture nicely.
Notice that many of the components are provided by the framework (Struts Action, DAO, JDBC).
The use only needs to plug in the specific component to implement the business logic.
Jt is a framework for the rapid development of Java applications. Many
of the lego pieces come out of the box.
I'm familiar with projects that struggle with Exceptions.
In particular when it comes to propagate exception to the GUI layer
from the other layers.
Within the Jt framework, this problem is solved via the straightforward approach
discussed above.
The same concepts apply for remote components. It is a bit more involved
because there are two systems at play:
client -- message-> local JtProxy -- message -> JtWebServicesAdapter .....network message ...> Business Object
--- message -> JtDAO --- message -> JtJDBCAdapter
In this scenario, the exception is propagated all the way back to the local proxy.
The client application can easily check if an exception occurred. A remote exception JtRemoteException is generated when we are dealing with remote components. This exception is needed so the framework can show the stack trace for both JVM (local & remote component are shown).
“As mentioned in the section dealing with the subject, the Jt framework provides a consistent/transparent way of handling errors and exceptions. The same mechanism applies to all the APIs integrated with the Jt Framework. This includes all the remote APIs. Exceptions generated by remote components are propagated to the local components. In the previous example, notice how remote exceptions are propagated to the local component (JtRestService).
Remote components are pretty much treated as local resources. The remote component doesn’t need to do anything special besides updating the objException and objErrors attributes appropriately. This is usually done by invoking handleException() or handleError(). Java beans that implement the Jt Interface will also need to declare and handle the objException attribute. For additional details, please refer to the section dealing with the Jt handling of exceptions and errors. “
If someone can come up with a better mechanism to fit the messaging design
pattern/interface, we will be thrilled to hear it
I hope the exception mechanism makes sense now (within the context of the messaging design pattern). I hope you can see why these are standard Java Exceptions (not just status codes) and why they need to be passed/propagated around. Please feel free to send us follow-up questions related to the exception handling.
I still need to answer some of your additional comments (proxys , …).
Best regards,
|
|
|
Message #329145
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Commentary
Miroslav,
In regards to your comments around Proxys, we need to cover
how the messaging design pattern/interface is able to deal with remote
components.
Well, the thing is that the simplicity of interface can be deceiving.
public interface JtInterface {
/**
* Jt messaging interface used for the implementation
* of the messaging design pattern.
* Process a message and return a reply.
*/
Object processMessage (Object message);
}
" JtInterface is simple but powerful. The simplicity of this interface can be deceiving.
One method is all that is needed (dry). The framework architecture and implementation of
its design patterns is based on JtInterface. It acts as a universal messaging interface
that applies to remote and local framework objects."
The framework lego/messaging architecture provides transparent access to remote components:
remote framework objects are treated as local objects. Design patterns implemented by the
framework (adapters, remote proxies and facades) make this possible. We don’t need to be
concerned as to how the messages are transferred. Messages can be transferred via Web services,
Ajax, JMS, EJBs, RMI, HTTP or any other API."
Remote and local objects are treated the same. Actually objects that implement
the messaging interface can be accessed remotely without having to do anything.
How is this done ? folks may ask.
It is done via the implementation of two design patterns:
proxy and messaging. Jt also implements many other design patterns (GOF, DAO, J2EE, etc).
The proxy provides a handle to the remote instance of the object.
The messaging approach allows this:
reply = sendMesage (objectA, messageA).
I hope you are going to like the following part.
It also allows the following:
reply = sendMessage (JtProxy, messageA)
where JtProxy is the proxy to the remote instance of
the object.
client ----Message-> JtProxy ---Message-> JtWebServicesAdapter ........remote message..........> objectA
Please let us know if there are any specifics aspects that
you don't like about the Proxys. I hope you agree that the use of the
GOF Proxy design pattern is
a correct approach to access remote objects. To understand remote access it is also needed
to start thinking in terms of design patterns.
For this specific example, messaging and Proxy are needed.
I've discussed some of the postings with the others. The examples will be changed
based on your feedback and the feedback provided by others. Casts won't
be used unless they are really required. We'll start changing this.
Some of the examples should be improved for the next release.
In regards to the examples; there are other examples that show the strengths of the
framework.
I provided several of them.
The HashTable example/demo is not a good one. It is very old code
It will be changed or replaced. I'll keep you post it.
You are asking about the String. Your description of the use of String is accurate.
They are use as message IDs (in a lot of places).
You ask why ? The answer is related to the messaging approach yet again.
It is required to keep thinking in terms of messaging.
How can we discriminate the messages that the object is supposed
to process ?
"JtInterface can handle any type of message (Object class).
Framework components are instructed to perform operations by using
these messages. Most of the core Jt components use JtMessage. This class
defines basic messaging information (message ID, message content, message data, message attachment, etc.).
Instances of JtMessage are created as follows:"
For instance, your DAOs need to differentiate between
create, read, update, delete (JtCREATE, JtREAD, JtUPDATE, JtDELETE)
These can be easy done by having message Ids.
That is why you need the message Ids in many places.
On other hand, we have struggled with this issue. integers would be more natural.
On the other hand, It would complicate the BPM pieces. People would need to remember
the integer/message Ids in order to add their components
to UML/BPM diagrams. That is why Strings are used. Strings are easy
to remember . (JtCREATE, JtREAD, JtUPDATE, JtDELETE). This can be used while including your components as part of your BPM diagrams.
If someone finds a better solution for this problem we'll love
to hear it.
Thanks again for the feedback and the insight.
|
|
|
Message #329147
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Further commentary
I would change the name of the framework, it should not be called "pattern" as it not denote "what" it does but "how". Im sure many people are still confused about the primary objective of this framework. The "pattern" bit is superfluous to me understanding at a quick glance what it does.
People dont really care most of the time how something is achieved but rather are more interested in the "what". I dont know how my TV works on a low level, but im happy its a TV and that it works just like all other TVs. How its wired up inside and all the other bits and pieces are irrelevant for my uses. When or if i want to use your framework i dont care how it does its magic, i want to use it at a highlevel as an abstraction that makes my problemspace simpler. All the messy bits inside are not of interest to me in any way most of the time.
|
|
|
Message #329152
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Jt - Java Pattern Oriented Framework (Jt 4.5)
Wesley,
I like the way you put it. No need for it. I don't think it serves any valuable purpose.
The main thing here is the "abstraction". Someone else said it very well.
Once the messaging "abstraction" is grasped all the pieces should fit together:
public interface JtInterface {
/**
* Jt messaging interface used for the implementation
* of the messaging design pattern.
* Process a message and return a reply.
*/
Object processMessage (Object message);
}
It is required to think in terms of the messaging abstraction/concept.
Perhaps I would call it a 'generic messaging framework' or 'generic messaging engine'
I see your point in regards to 50%. Also, I'd like to know
the percentage of folks that actually understand the facts
behind the technology. Obviously I need to study/understand something before I
give my opinion (based on reasons and facts). I need to gather my facts. I also need
to ask questions to determine why I might be missing. I hate to point the obvious. In our particular
scenario, the understanding of the messaging abstraction is required.
I should say that some of the comments
have been really good (real insight!).
I can see your point regarding XML. I hope you agree that messaging is not
the same thing. The world operates in terms of messaging. You can see it everywhere.
The messaging concept is a good way to model the real world.
It is true that the framework can do many things. It is because of
the messaging interface/pattern: the lego pieces can be arranged in many ways.
For instance, the framework can do sendMessage (objectA, messageA)
and at the same time it can do sendMessage (proxyA, messageA)
where proxyA is a remote proxy for objectA:
client ----Message-> JtProxy ---Message-> JtWebServicesAdapter ........remote message..........> objectA ---Message->
JtDAO ---Message -> JtJDBCAdapter
The lego pieces can be rearranged in many ways. The power of the
messaging/lego concept makes it possible.
I should also mention the scope of the project (as defined in the documentation)
In my opinion the scope of the project is well defined.
"Jt is a pattern oriented framework for the rapid
implementation of Java applications. Jt has been utilized in several
large mission critical systems. Jt implements many well-known patterns including Data Access Objects (DAO),
GoF design patterns and J2EE patterns."
A) The pattern oriented framework implements and/or facilitates the implementation of well-known
design patterns like Gang Of Four design patterns (GoF) and J2EE Design patterns. The framework
itself is conceived and implemented, from the ground up, based on design patterns.
The framework also 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 simplicity, strong encapsulation and loose coupling; framework components can be interchangeably
plugged into complex framework applications using a “lego/messaging” architecture. Framework messages can be
processed synchronously or asynchronously.
The framework takes full advantage of the power and simplicity of the messaging design pattern/API.
..........
I agree, you can do anything with Java. The framework is based on pure Java.
On the other hand, you can do it faster and cheaper with our framework (scope above).
The quality/reusability is better as well. Again, people need to think in terms of
the lego/messaging abstraction. You assembly your applications by putting
the lego pieces together.
In terms of the interface:
public interface JtInterface {
/**
* Jt messaging interface used for the implementation
* of the messaging design pattern.
* Process a message and return a reply.
*/
Object processMessage (Object message);
}
Messages can be anything in the real world. The interface models it (Object).
I'm not sure there is another way to do this.
I don't really mind the cast. On the other hand, you don't need to use the cast if you don't want to.
You can still use the messaging design pattern:
MyOutputMessageType processMessage (MyInputMessage) {
}
MyInputMessage mesage = new MyInputMessage ()
MyOutputMessageType reply = a.processMessage (message);
I should mention that the messaging design pattern has been
implemented using other languages.
JavaScript for instance (Jt AJAX components). It is not restricted to java ("abstraction").
If you let us know what specific problems
you are facing, I'll probably be able to give my opinion as to how
the framework can help solve them. In general terms, I can tell you that design patterns,
in particular the messaging
design pattern, can help solve many problems and families of problems.
That is one of their main purposes.
You probably agree that people don't use assembly language anymore.
It is too expensive and time consuming. Tools and frameworks
like ours increase productivity and reduce cost.
Take the following example for instance:
sendMessage (proxyA, messageA)
client ----Message-> JtProxy ---Message-> JtWebServicesAdapter ........remote message..........> objectA ---Message->
JtDAO ---Message -> JtJDBCAdapter
Try to do this using other remote API/technologies. The complexity becomes a real headache (expensive, time consuming ...).
I hope this makes sense. Please feel free to send us any follow-up comments.
|
|
|
Message #329155
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Jt - Java Pattern Oriented Framework (Jt 4.5)
This is a good question. Once the messaging design pattern/"abstraction" is understood:
public interface JtInterface {
/**
* Jt messaging interface used for the implementation
* of the messaging design pattern.
* Process a message and return a reply.
*/
Object processMessage (Object message);
}
...we may ask ... How can we use this messaging pattern to implement OOP design patterns? This is related to your question.
"A) The pattern oriented framework implements and/or facilitates the implementation of well-known design patterns
like Gang Of Four design patterns (GoF) and J2EE Design patterns. The framework itself is conceived and implemented,
from the ground up, based on design patterns. The framework also facilitates and accelerates the implementation of
applications based on design patterns"
You may want to check the previous postings. Good comments have been made in regards to the
Proxy design pattern. These postings/replies should help illustrate how the messaging design
pattern is used to implement other design patterns. Proxy, for instance:
sendMessage (proxyA, messageA)
client ----message-> JtProxy(proxyA) ---message-> JtWebServicesAdapter ........remote message..........> objectA ---Message->
JtDAO ---Message -> JtJDBCAdapter
The Jt documentation covers the other OOP design patterns
There is a complete set of examples for GoF and J2EE and, DAO:
The Strategy design pattern is probably another good example that can be used here.
For instance, the framework supports several DAO strategies via Jt.DAO.JtDAOStrategy,
including Hibernate and a native DAO implementation.
Jt.DAO.JtDAOStrategy uses the strategy design pattern.
You can switch DAO strategies using the Strategy design pattern:
client --Message -> JtDAOStrategy --Message-> JtDAO --Message--> JtJDBCAdapter
client --Message -> JtDAOStrategy --Message-> JtHibernateAdapter
The concrete strategy can be JtDAO, JtHibernateAdapter or your favority DAO implementation.
We need to think in term of messaging in order to understand
why/how this works.
You are going to like this part. The guts of the Strategy implementation becomes the following:
// Let the concrete strategy object handle the message
concreteStrategy.processMessage (message);
The messaging design pattern makes this possible.
It is a very straightforward implementation.
You may want to take a look at the java code (JtStrategy.java and Jt.DAO.JtDAOStrategy)
This note should illustrate how the messaging design patterns are used
to implement and/or facilitate the implementation of well-known design patterns
Feel free to send us any additional questions that you may
have regarding the implementation of design patterns.
If you let us know about the specific problem that you are trying
to solve, I'll be happy to tell you what pattern/lego pieces
may fit.
Java 1.5: The framework supports Java 1.5
On the other hand, the framework also need to support earlier versions of the
JVM. There are production applications that need to be supported.
These applications are running on earlier version of the JVM.
I hope this makes sense.
|
|
|
Message #329164
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Further commentary
I would change the name of the framework, it should not be called "pattern" as it not denote "what" it does but "how".
I think this is an excellent way to put it. Well said, basically what I was thinking but didn't know quite how to say. Of course if I was being facetious, I would say this is an 'anti-pattern' framework :)
Eg., the 'strategy' pattern is well understood by many, I would think. However why does the existence of this very useful pattern automatically give rise to a 'JtStrategy' class in the framework?
Looking at the source for JtStrategy.java, the code DOES NOTHING, except make a bunch of casting assumptions which immediately make a complete mockery of the already ridiculous Object processMessage(Object object) nonsense:
package Jt;
/**
* Jt implementation of the Strategy pattern.
*/
public class JtStrategy extends JtObject {
public static final String JtCLASS_NAME = JtStrategy.class.getName();
private static final long serialVersionUID = 1L;
protected Object concreteStrategy = null; // Concrete Strategy object
public static final String JtEXECUTE_STRATEGY = "JtEXECUTE_STRATEGY";
public JtStrategy () {
}
/**
* Specifies the reference to the concrete strategy.
*/
public void setConcreteStrategy (Object concreteStrategy) {
this.concreteStrategy = concreteStrategy;
}
/**
* Returns the reference to the concrete strategy.
*/
public Object getConcreteStrategy () {
return (concreteStrategy);
}
/**
* Process object messages.
*
* - JtREMOVE - Performs any housekeeping that may be needed before the object
* is removed.
*
*/
public Object processMessage (Object event) {
String msgid = null;
JtMessage e = (JtMessage) event;
//Object content;
//Object data;
if (e == null)
return null;
msgid = (String) e.getMsgId ();
if (msgid == null)
return null;
//content = e.getMsgContent();
//data = e.getMsgData ();
//if (msgid.equals (JtObject.JtREMOVE)) {
// return (null);
//}
// Let the concrete strategy object handle the message
if (concreteStrategy == null) {
handleError ("processMessage: concreteStrategy attribute must be set");
return (null);
}
return (((JtInterface) concreteStrategy).processMessage (event));
}
/**
* Demonstrates the messages processed by JtStrategy.
*/
public static void main(String[] args) {
JtFactory factory = new JtFactory ();
JtStrategy strategy;
JtObject concreteStrategy;
// Create an instance of JtStrategy
strategy = (JtStrategy) factory.createObject (JtStrategy.JtCLASS_NAME, "strategy");
// Specify the concrete strategy to be executed
concreteStrategy = (JtObject) factory.createObject (JtEcho.JtCLASS_NAME, "concreteStrategy");
factory.setValue (strategy, "concreteStrategy", concreteStrategy);
factory.sendMessage (strategy, new JtMessage (JtStrategy.JtEXECUTE_STRATEGY));
factory.removeObject ("strategy");
}
}
Also, do you realise that JtObject.java has upwards of 2200 LOC!? And counting I assume. Here's one choice extract:
/*
* Jt hook for the JBPM api. Defines a jBPM variable that points to the Jt object.
* It uses the name of the action (jBPM process diagram) as the name of the variable.
* @see org.jbpm.graph.def.ActionHandler#execute(org.jbpm.graph.exe.ExecutionContext)
*/
public void execute(ExecutionContext context) throws Exception {
//String reply;
//JtMessage msg;
String name, nodeName;
try {
nodeName = context.getContextInstance().getProcessInstance().getRootToken().getNode().getName();
handleTrace ("JtObject.execute:entering node ... " + nodeName);
name = context.getAction().getName ();
handleTrace ("JtObject.execute:creating a Jbpm variable " + name);
context.getContextInstance().setVariable (name, this);
} catch (Exception ex) {
handleException (ex);
return;
}
loadObjectResources (this);
}
Hmmm... jBPM support built into the framework's core abstraction. In otherwords, this framework is probably implemented by one monolithic class (JtObject).
Crazy crazy crazy!
Stop posting this!
|
|
|
Message #329165
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re:Further commentary
Miroslav,
You got it! The main thing is the abstraction. Excellent, if I may say so.
Changing the name is a good suggestion. We want to avoid any confusion. If people can come up with a better name, we'll
change it.
I checked with the others. Folks feel free to send any potential names. Perhaps we can vote on it
Some names that have been suggested in the past:
a) Jt - Java Pattern Oriented Framework
b) Jt - Java Messaging Engine
c) Jt - Java Messaging Framework
d) Jt - Java Reusable Framework
e) Jt - Java Lego Framework (After talking them into letting us the name.....yeah sure)
Some folks like the term "lego programming". I include myself here.
It is consistent with the idea of the lego/messaging architecture.
The Pattern oriented framework is used because of the term "design pattern". It is widely used:
A) The pattern oriented framework implements and/or facilitates the implementation of well-known
design patterns like Gang Of Four design patterns (GoF) and J2EE Design patterns.
The framework itself is conceived and implemented, from the ground up, based on design patterns.
The framework also facilitates and accelerates the implementation of applications based on design patterns.
We don't like b and c because it can create confusion in terms of JMS, MOM
and so forth.
Most of the framework is based on "design pattern" concepts (including the
messaging design pattern)
The name gives credit to the that fact and those who came up with the concept.
We appreciate your comments and suggestions.
Best regards
|
|
|
Message #329169
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Feedback
Why are all (most ???) class names include pattern in their name but none include the functionality of what they offer to me as a problem solver ? I can see the words Strategy, Adapter, Bridge, Fascade, Momento and all the other GOF pattern names and yet i cannot see a single functionality or technology based name ? Given that you say the framework is about messaging where are the Broadcasters, JMS Senders, Emailers or other message transport type named classes ?
|
|
|
Message #329201
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Feedback
Miroslav,
These are very good questions! How can the Jt Pattern Oriented framework be used to solve specific problems ?
“Jt is a Pattern Oriented Framework for the rapid implementation of Java applications. Jt has been utilized in several large mission critical systems. The framework addresses the following goals …..
Per your earlier comments, we need to think in terms of abstractions.
These Design Patterns are generic abstractions. They can solve
many problems and use many technologies. We have to think in terms of messaging and design patterns.
The previous postings gave you some examples in terms of Web Services, DAO, and DAOStrategy. These
examples are based on real world problems. I'll give you some additional examples shortly.
The framework gives you the lego building blocks. We need know how those building blocks can be used
to assemble a particular application and solve a particular problem. We need to have
an understanding of the design patterns (messaging included) and how they work. If you
let us know what specific problem your are trying to
solve, I can tell you what lego blocks may help you solve the problem.
- Jt Messaging
I've given several examples related to the messaging design
pattern. Once this messaging design pattern is understood it becomes clearer how
the other design patterns are implemented (and how they can be used).
public interface JtInterface {
/**
* Jt messaging interface used for the implementation
* of the messaging design pattern.
* Process a message and return a reply.
*/
Object processMessage (Object message);
}
- JtStrategy Design Pattern
--message-->JtStrategy--message->concreteStrategy
The Strategy design pattern for instance. The Jt Pattern Oriented Framework gives you
an implementation for this design pattern. Once you think in terms of the abstractions,
Strategy can be used to solve many similar problems (like messaging).
For instance, you may need to implement several chess strategies or security strategies for login access.
All these problems can use the Strategy abstraction.
--message-> JtStrategy --message-> ChessStrategyA (messages can be the chess moves)
We can have several strategies (ChessStrategyA, ChessStrategyB, etc).
--message-> JtStrategy -->message-> LoginStrategyA (messages can be login username/password )
I can give you a more tangible example:
"The framework supports several DAO strategies
including Hibernate and Jt native. Additional DAO strategies can be easily plugged in. In some instances,
heavy DAO implementation may not be used due to resource constraints."
--message-> JtDAOStrategy -->message-> JtDAO
You can switch the strategy:
--message-> JtDAOStrategy -->message-> JtHibernate
Our DAO implementation is part of the core Jt Framework (~300k). It is very
lightweight. Some DAO implementations aren't suitable for all ISPs
due to resource constrains. This is part of one of the Jt reference applications (JtPortal).
The application can switch strategies depending on the host/project/company/problem.
This also illustrates how JtStrategy can be used to solve a real world problem.
Once the messaging design pattern is understood the guts of
the Strategy design should become clear:
concreteStrategy.processMessage (message) // The simplicity of this implementation is another ramification of messaging
I hope this illustrated a bit better how the GOF Strategy abstraction can be used to
solve real world problems.
- JtProxy
"The framework makes extensive use of this design pattern. The Web Services adapter and the
EJB adapter rely on JtProxy. A proxy is used to interface with the remote instance. This local
proxy can be manipulated using the framework messaging API. Jt.ejb.JtEJBProxy and Jt.axis.JtAxisProxy
illustrate the use of JtProxy."
I sent you a few examples of this one.
This allows for transparent access to remote objects via Webservices (REST/AXIS) ,EJBs, etc.
The Jt messaging pattern allows us do the following
sendMessage (JtProxy, message).
These are related real problems as well.
-- JtAdapter
How do you connect the Jt framework with other technolgies/APS (JMS, Java Mail, etc) ?
This can done via implementation of the Adapter abstractions
This is a pattern that we haven't covered directly. (page 30 - user's manual)
"Jt.JtAdapter implements the adapter design pattern. The framework makes extensive use of this design pattern. Jt implements adapters for several APIs:
JDBC Adapter: Jt.JtDBCAdapter
JMS Adapters: Jt.jms.JtJMSQueueAdapter and Jt.jms.JtJMSTopicAdapter
EJBAdapter: Jt.ejb.JtEJBAdapter
JBPM Adapter: Jt.jbpm.JtJBPMAdapter
Web Services Adapter (Axis): Jt.axis.JtAxisAdapter
DAO Hibernate Adapter: Jt.hibernate.JtHibernateAdapter
Java Mail Adapter: Jt.JtMail
JNDI Adapter: Jt.jndi.JtJNDIAdapter
JDOM Adapter: Jt.xml.JDOMAdapter
The Jt framework can be easily extended using new adapters.
The source code of the above adapters demonstrates the use of JtAdapter.
These adapters translate Jt messages into calls understood by the appropriate API.
This allows the external API to be plugged into framework applications. For instance,
each one of these adapters can be added to a BPM business process as part of complex applications. "
Note: This is all part of the Jt.jar ~300k
You were asking about JMS and Mail. We already have the lego pieces for these two APIs.
-JMS Adapters
"The Jt Framework provides integration with the JMS API. Two JMS adapters are included:
JtJMSQueueAdapter (point-to-point) and JtJMSTopicAdapter (publish/subscribe).
The documentation for these adapters can be found under Jt/dist/docs/api.
Program examples that demonstrate the use of the JMS adapters can be found
under src/java/Jt/examples/jms. Very few simple lines of code are needed to add JMS
functionality to Jt based applications."
In a real world problem, an order may need to be stored using JMS queue. The may
come via a Web service invocation. The lego pieces could be arranged as follows:
client ----Message-> JtProxy ---Message-> JtWebServicesAdapter ...remote message...> objectA ---Message->JtJMSQueueAdapter
......>JMS API....
-Java Mail Adapter
"The Jt Framework provides an adapter for the JavaMail API. The documentation for JtMail
can be found under Jt/dist/docs/api. Several JtPortal components make use of the JavaMail Adapter."
By the way, we also have two reference applications that solve real problems and demonstrate the use of the framework:
“The framework distribution includes several reference applications built on top of the Jt Pattern Oriented framework. These are complete production quality applications. The JtPortal application implements portal and electronic commerce capabilities: user profile, mailing list, portal administration, shopping cart, forums, chat, etc.The Jt Wizard is an application that provides automated capabilities for generating framework applications. The Jt Wizard is able to automatically generate application modules based on several design patterns including Jt Messaging, DAO, MVC and Gang of Four.”
I hope these answers your questions. Feel free to send us any follow-up questions.
Again, if you send us additional info about the problems,
I'll tell you what lego pieces may fit. I hope you can see how the Jt framework
can be used while solving real world problems.
Also, I'll send you additional info on the broadcasters.
Best regards
|
|
|
Message #329273
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Feedback
@ Dan Evans
Friendly advice. Don't even bother responding to these trolls. Even if there are some mistakes in your framework (I do not know since I haven't checked), they should have responded with constructive criticism, and I am sure you would welcomed such feedback. However, since they are doing here plain ol', slashdot style, epeen, nerd rage trolling.
If you noobs dont like his business proposal, ignore it or post constructive feedback otherwise stfu. You are embarassing yourselves.
|
|
|
Message #329276
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Feedback
Excellent points!! If I may say so. We appreciate your sound advice. I'd like to think about this in terms of the golden rule from the old book. Don't deviate from it and become like dust the wind. It will take you far.
You are right. Constructive criticism is always welcome. Please gather your facts and ask questions to determine what lego pieces you might be missing. Feel free to be "direct", nobody has the monopoly on "Intellectuality" as some other folks put it. Sorry for having to point the obvious.
I must add that some the comments/questions have been really good. People who understand the "abstractions". People who have taken the time to study and gather the technical facts (real insight!)
Best regards
|
|
|
Message #329296
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Feedback
Excellent points!! If I may say so. We appreciate your sound advice. I'd like to think about this in terms of the golden rule from the old book. Don't deviate from it and become like dust the wind. It will take you far.
You are right. Constructive criticism is always welcome. Please gather your facts and ask questions to determine what lego pieces you might be missing. Feel free to be "direct", nobody has the monopoly on "Intellectuality" as some other folks put it. Sorry for having to point the obvious.
I must add that some the comments/questions have been really good. People who understand the "abstractions". People who have taken the time to study and gather the technical facts (real insight!)
Best regards
Dan,
I've made some comments before without explaining myself and for that I apologize.
The fact that I've been rude doesn't change the fact that I think you "framework" is poorly designed, has an awful misleading name and has inherent flaws that makes it one of the worst frameworks I've ever seen.
Here is my opinion about the points I've mentioned:
Poor Design:
In my opinion you framework forces the developer to use an "if/else" approach of programming that is just not object oriented. Forcing every one to use one single method for everything is the same as throwing type safety, method overloading in the trash.
What is better, to have someone that is using your component calls:
myComponent.addTwoNumbers(1,2)
or
myComponent.processMessage("SOMETHING", new int[] {1,2});
Not only the seccond option is longer to write and more error prone (no type safety, no compiler support to checking the message name) it has far worst performance. See, if you have a big component which can perform several operations the if/else you have to perform to check for every operation is a burden that may be too heavy for most applications.
Misleading name
Just because you use some desing patterns in your framework (and about that I'll talk later) does not means it is a Pattern Oriented Framework! The name of the framework made me look at it with high expectations and can make a youger programmer thinks that this is the right way to do patterns!
About the use of patterns, as stated in the GoF book (quoting Christopher Alexander): "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, withou ever doing it the same way twice"
So, by providing canned implementation to these patterns you are hurting the very essence of it.
Also, some implementation are just plain wrong, for instance, in JT why do I need JtStrategy if it only delegates the implementation to someone else? If it is message based I should not need the "strategy" in the middle, I could change it just by changing the receiver of the message registered.
I hope I've made my opinions clear and can improve the level of this discussion.
|
|
|
Message #329316
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
...so if you want it once more
Deceptive API
Your "framework" offers an API that lies. Your "pattern implementations" take java.lang.Object as parameter and cast them internally. This means that the real contract is hidden in the implementations. That's just NOT the way of OO Design. I suggest you read something about S.O.L.I.D design principles, Effective Java, Practical API Design etc. to see how interfaces should be given to the public.
No unit tests
Your "framework" does not provide any reasonable test harness. It is impossible to employ it in a production environment without them. You write about "mission critical systems" where it has been employed. This also shows clearly that yout "framework" does not even follow any contract because it is impossible to give deterministic assumptions about what is done under the hood.
Homegrown logging
If your logging mechanism is so complete, than why didn't you release it as a standalone product? In my opinion it is completely unacceptable e.g. doesn't allow usage of database appenders or standard log levels.
In the end, I must admit that maybe limiting the freedom of speech is not a good option but if a young developer, or, even worse, a manager sees your framework he/she may think that it's the right way to build applications. In my opinion, it is very far away from right - it is simply harmful. I recommend everyone browsing the TSS posts regarding earlier versions of this "framework" - many interesting points have been raised there.
|
|
|
Message #329322
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Feedback
Misleading name
Just because you use some desing patterns in your framework (and about that I'll talk later) does not means it is a Pattern Oriented Framework! The name of the framework made me look at it with high expectations and can make a youger programmer thinks that this is the right way to do patterns!
Rofl!! Is this supposed to be a joke???
|
|
|
Message #329323
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Feedback
Misleading name
Just because you use some desing patterns in your framework (and about that I'll talk later) does not means it is a Pattern Oriented Framework! The name of the framework made me look at it with high expectations and can make a youger programmer thinks that this is the right way to do patterns!
Rofl!! Is this supposed to be a joke???
A joke? Why? Please elaborate!
|
|
|
Message #329324
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Feedback
You said as third post of this thread:
"Re: Jt - Java Pattern Oriented Framework (Jt 4.5)
Posted by: André Rácz on November 09, 2009 in response to Message #328994:
"Is this for real? "
Now you got owned son, so you know how it feels when someone is being a dick.
|
|
|
Message #329326
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Feedback
You said as third post of this thread:
"Re: Jt - Java Pattern Oriented Framework (Jt 4.5)
Posted by: André Rácz on November 09, 2009 in response to Message #328994:
"Is this for real? "
Now you got owned son, so you know how it feels when someone is being a dick.
At least I had the decency to apologize.
|
|
|
Message #329340
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Feedback
Andre,
I accept your apology. We all have our moments. No point in being rude. It doesn't accomplish any valuable
purpose. Obviously “we should seek to understand first” before giving an opinion
on a subject. It also obvious that we need to ask a lot of questions
in order to get to the facts (aspects that we may be missing). We are glad that you are asking questions. Our answers should give you more facts.
I'm afraid that some of your points are not accurate. No problem.
It is quite alright. This is the main idea of having this discussion so we can uncover to the facts.
Please find enclosed answers to some of your questions.
In order to understand the framework we need to understand messaging.
Think about it, the real world works in terms of messaging. Therefore
messaging is a good representation/model of the real world.
Once the messaging design pattern is understood all the lego pieces should fit
public interface JtInterface {
/**
* Jt messaging interface used for the implementation
* of the messaging design pattern.
* Process a message and return a reply.
*/
Object processMessage (Object message);
}
This is 90% of the effort needed to understand the framework. Once people get
it they go like ahh... I get it. There will be ramifications. Trust me.
You need to think in term of "abstractions". Someone else said it best.
We need to think in unconventional ways based on "abstractions" in order to understand this
messaging concept.
Some of the facts that we have gathered so far:
-Does it work ? This approach works. We have the Jt framework, reference applications
and production systems to prove it. Achievements have been made in terms of rapid development, quality, reliability, reusability, etc. There are ramifications.
-Why does it work ? In part because the messaging design pattern is a very
good representation of the real work. It also minimizes coupling and
maximizes encapsulation and reusability.
You raise very valid questions:
How does it compare with the conventional/functional approach ?
This is related to your question and specific example.
This is an important discussion that we
should have. We'll probably have to agree to disagree on this one.
Both ways (messaging/functional) have advantages and disadvantages.
On the other hand, we think that there is a strong/solid case
for the messaging approach.
I hope I have given plenty of examples as to
how the messaging framework can be used to solve problems from the real world.
We have plenty of additional examples that we can provide (previous postings).
if/approach: I'm afraid that your description of if/else is not accurate.
This is not factual. Start thinking in terms of messaging and Ask yourselves this question: In messaging how can I discriminate my
messages. For instance, a DAO component may need to handle several messages - JCREATE, JREAD, JtUPDATE,JtDELETE
On the other hand, you don't need to use the if/else approach. You can use a switch based on a messageId.
You are not forced to do anything (not a fact). The framework gives you complete freedom. Messages can be anything.
You can also use the type of the message to differentiate then ..... It is open to your imagination.
However you need to be thinking in terms of "abstractions" and messaging.
Of course the sender and the receiver need to agree on the message format/protocol.
For example, you can have the following
MyOutputMessage processMessage (MyMessage message) {
switch (message.getId ()) {
case (READ):
....
case (WRITE)
.....
}
}
Again the key question here is: how do I discriminate my messages within a messaging paradigm ?
It is true that most of the existing components use Strings because of the BPM/UML pieces.
Strings are more natural. If someone can come up with a better mechanism, we'll
be thrilled to know about it.
In terms of your example:
myComponent.addTwoNumbers(1,2)
or
myComponent.processMessage("SOMETHING", new int[] {1,2});
This is good question. I should be able to illustrate the benefits of messaging.
By the way, your example should be myComponent.processMessage (new int[] {1,2}); //SOMETHING is not needed
processMessage takes one argument: The message (array).
sendMessage takes two paramenter sendMessage (object, message);
I can see a lot of advantages with the opcion 2.
1)Maintenance. The second option is very flexible. You can write
your component in a generic way to add as many number as you want (0,1, 2, 3…n)
For the first option you would need to change the method and the
places where the method is called. The test cases may need to changes as well.
2) The component can be execute remotely without any changes (transparent access to remote components)
sendMessage (jtProxy, message) // based on the previous postings
where the message is an array and the jtProxy is a remote
proxy to the remote object. (I gave an example of JtProxy in the previous postings)
This can be a headache under the traditional approach.
3) If you want to add it to you UML/BPM diagrams. The component can be easily added:
---->message---->myComponent (very natural)
There no easy way to do this under the functional approach.
This is a good example to demonstrate some of the
limitations of the traditional approach.
4Testing: the second solution can be test via a testing harness (I covered this in one of my previous postings)
5) The second option is also more generic/flexible. It can take as many integers as you want to (without any changes)
Once we are thinking in term of messages we need to train
our mind to think in terms of components that interchange
these messages. The world around us works in terms of messages and individual entities (components)
it is natural to have a messaging model to represent it
As you can see, the messaging approach provides some real/strong advantages: simplicity, reusability, remote access, maintenance,testing, etc. This example also shows the shortcomings of the functional
approach.
These are some of the advantages. If you think in terms of messaging you may come up
with new ones.
Performance: I agree with in terms of performance. Your description is accurate The performance of the functional solution is a bit better. The difference is not that big though. There is a small overhead
Java is slower that assembly language. We use Java
it in part because it is a better/closer representation of the world around us (objects oriented).
We are willing to pay the price (overhead)/
The main problems with system today are reliability, implementation cost, quality, timeframe. Machines are fast enough (getting faster) to handle the overhead associate with Java, tools and other frameworks. In other words, the small performance difference doesn’t outweigh all the benefits(by a large margin) . By the way, the Jt framework is really light and fast (in part due to the simplicity of its design).
In regards to the name. There is a good suggestion about changing the name to avoid confusion. If someone can come up with a better name, we'll change it. There is no intention to deceive anyone. On the hand, there are good reasons for the name. It you look at the Jt user's manual you'll see design pattern everywhere. This is framework based/designed/built on top of design patterns. The facts support our point. I'm afraid I don't quite see your point.
“A) The pattern oriented framework implements and/or facilitates the implementation of well-known
design patterns like Gang Of Four design patterns (GoF) and J2EE Design patterns.
The framework itself is conceived and implemented, from the ground up, based on design patterns.
The framework also facilitates and accelerates the implementation of applications based on design patterns.
C) The framework lego/messaging architecture provides transparent access to remote components:
remote framework objects are treated as local objects. Design patterns implemented by the framework
(adapters, remote proxies and facades) make this possible by hiding the complexities associated with remote APIs.”
There are people with a lot of experience using this framework. If someone can find a better
way to implement the messaging concept we’ll be thrilled to hear it. On the hand, keep in mind that the concepts/”abstraction” are the main thing here. We’ll be happy to debate the implementation decisions. It should be clear that the fact support our implementation decisions. On the hand, the implementation is second nature.
I'll reply to your other questions/comments shortly. Your opinions are clear! In my opinion it has improved the level of the discussion! We appreciate it. I hope this gives you a better idea/understanding in term of the facts behind the framework.
Regards
|
|
|
Message #329369
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Feedback
Andre,
I hope I've been able to give you some of the facts behind the Jt framework
("abstractions/implementation). Please find enclosed additional ones.
DESIGN: In my opinion it is a very straightforward, flexible design based on the messaging "abstraction":
public interface JtInterface {
/**
* Jt messaging interface used for the implementation
* of the messaging design pattern.
* Process a message and return a reply.
*/
Object processMessage (Object message);
}
This interface allows to communicate messages between components. There is simplicity.
As I mentioned earlier, this is also a very good model for a real world.
As a consequence of the simplicity of the messaging/concept, the design of
the core API becomes the following:
createObject
setValue (set attribute value)
getValue (retrieve attribute value)
sendMessage (component, message) . This triggers process message (receiving component)
removeObject
In opinion this is complete, straightforward, concise, expressive, etc.
This messaging design pattern also have some ramifications:
Complex problems like the ones related to the remote interfaces, can be handled via an straightforward/elegant solution:
sendMessage (JtProxy); // The use of proxies was covered in previous postings
---message-->JtProxy .........network..........> Component
this is very neat combination of the messaging design pattern
and the Proxy design pattern. It basically says send a message to a remote
object using a remote proxy and bring me the reply. This can solve many complex problems of the
real world.
Strategy:
(concreteStartegy).processMessage (message) // Strategy pattern covered in previous postings
1) ---message-->JtStrategy---message-->concreteStrategyComponent
This is combination of strategy and messaging.
Per your posting I believe you want to do the following (remove the strategy building block):
2) --message-->concreteStrategyComponent (based on you comment)
The first option is more flexible. It captures what is happening. We need to think in terms of concepts.
There is no need to change any code. Less error prone.
When you use the framework you can simply change a configuration file (Jt.properties).
This is what the JtPortal implementation does. You
can switch the DAO implementation by using the Strategy design
pattern and changing a simple configuration file (the user can choose between JtDAO and JtHibernate)
Again, think in terms of "abstractions". Strategy is the right design lego component
for this specific problem.
If you can find a better implementation of Strategy (based on messaging) we'll
be happy to discuss it. Our implementation works. In my opinion it provides
a good/simple representation of the Strategy concept.
"In software engineering, a design pattern is a general reusable solution to a
commonly occurring problem in software design". On the hand, design patterns
can be implemented and resused. There is a value in doing so.
Think about the Java Iterator (related to the design pattern iterator). Think about the many
DAO implemention available.
The fact is that there is value in implementing design patterns.
It gives people a better understanding of design patterns.
It provides powerful tools (like our framework) to build their systems.
In terms of "canned design patterns" I can tell you that there are other implementations
of design pattern. There are several papers/books dealing with the implementation
of design patterns. As I said, there is value in implementing design patterns.
I'm afraid that the facts doesn't support your point.
There are also very popular implementations of other design pattern (DAO).
As I mentioned we also have our own implementation.
BTW your comment about forcing everyone to use a single method for everything
is not accurate. Nobody is forced to do anything. People can use as many internal
methods as they want to. Same as usual.
The messaging interface on the other hand, is used to interchange messages
between components:
public interface JtInterface {
/**
* Jt messaging interface used for the implementation
* of the messaging design pattern.
* Process a message and return a reply.
*/
Object processMessage (Object message);
}
I have mentioned some of the ramifications in
my previous postings (It minimizes coupling (one method is needed to communicate between components).This
also maximizes encapsulation, reusability, quality and development speed.
This an additional benefit of using design patterns: louse coupling.
I hope that I have been able to provide some of the facts behind the framework.
I'm glad that you are asking these questions. It should provide a better
understanding of the facts and concepts/"abstractions". Please feel
free to send any follow-up questions. I'll be happy to discuss any facts that may not be
clear at this point.
Regards
|
|
|
Message #329370
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Feedback
I've done some research in terms of the broadcasters. There are several design patterns
and components that can be used to broadcast messages. You may want to look at JtCollection, JtObserver, JtComposite
(JtBroadcast message). It is fairly straightforward with Jt. Your particular application/problem will determine what component fits best.
Best regards
|
|
|
Message #329371
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Feedback
I'm glad that we agree on some of the facts (test harness, freedom of speech..).
I believe we have made a lot of progress in terms of understanding.
I believe that I can provide additional facts that can make thinks even clearer
I 'm glad that we have an understanding as to how the testing can be done under a messaging approach (test harness)
I agree that we need to have a test harness. Very good point on your part!
We'll provide a test harness as soon as possible. In terms
of the productions applications they have their own test harnesses. Jt functionality is not tested there.
That is what I mean when I say that the Jt framework is taken for granted.
I'd like to mention that the project web site is based on the Jt technology (Jt/Jt portal components
JSPs/Struts/AJAXs/Jt DAOs/Web Services/etc.). In any case the test harness will be provided.
Based on your insight and comments I think you get the messaging concept:
public interface JtInterface {
/**
* Jt messaging interface used for the implementation
* of the messaging design pattern.
* Process a message and return a reply.
*/
Object processMessage (Object message);
}
I'm not sure that deceptive is right word to be used
when talking about APIs. APIs can be simple, complete, difficult to use, etc.
Since this is generic framework. The interface is telling you
that a generic object should be able to receive messages of any
type (Object), process the message and return a reply of any type (Object)
This is good model of the real world where messages are
interchanged between entities like this. Messages can be anything.
I hope that my explanations show that this is a clear, expressive, transparent, concise API.
The framework messaging interface needs to be generic enough to handle
many types of components and messages (from diverse applications that solve real problems).
This messaging interface is able to handle it. For a generic framework we cannot limit
the interface.
By the way, you can use the messaging design pattern without using the interface.
I gave several examples in my previous emails (POJOs). You can also limit
the message to be whatever you want it to be.
If for some reason you don't like API/interface perhaps the right question for you to ask would be:
How can I provide a better Java API implementation of this messaging concept (advanced question) ?
If someone came with a better implementation, we would be
thrilled to hear it. Credit would be given for you contributions
You need to do the casting because the message needs to have a type.
The sender and the receiver need to agree on the format/type of the messages
being interchanged
For instance, if you have a component that handles email messages (String)
Object processMessage (Object message)
{
String emailMessage = (Object) message; // The receiver/sender need to know that Strings are to be exchanged.
}
I not sure there is a better option to do this. If there is a better way, we'll like
to hear it. On the other hand, I don't see this is as a very big issue. It has been used widely. On the other hand the implementation is second nature. The concepts/abstractions are the main thing here.
I'll reply to your other questions shortly. Again, I'm glad that we are finding common ground based on facts.
Regards
|
|
|
Message #329378
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Dear Mr.Evans
Dear Mr.Evans,
I read carefully almost all the posted messages. Two things mainly kept my attention :
1- You have repeated almost in every message "Once this messaging design pattern is understood it becomes clearer...". Let me say, that it is clear that almost everybody here understood your messaging design pattern, and that's you who doesn't seem to understand that everybody understood your framework.
2- The point of the discussion can be summarized when you said in an older message "Notice that you have all the freedom that you need. No restrictions at all. You just need to implement the interface above." What everybody tried to say since the beginning is : "When we build strong OO design, we don't need any freedom, but we need RESTRICTIONS !!!!", that's what the other meant when they mentioned "type safety".
Your framework could be a good thing to use if it was written in another language, but I don't think that any serious Java programmer would use it for an enterprise project.
Regards,
|
|
|
Message #329402
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Jt - Java Pattern Oriented Framework (Jt 4.5)
This a continuation of my earlier reply. In terms of the homegrown logging, the answer is very simple.
Releasing a standalone logging was never part of the scope of work for this project. The following are the project goals (as described in the documentation):
"This document describes Jt, a Pattern Oriented Framework for the rapid implementation of Java applications. Jt has been utilized in several large mission critical systems. The framework addresses the following goals:
A) The pattern oriented framework implements and/or facilitates the implementation of well-known design patterns like Gang Of Four design patterns (GoF) and J2EE Design patterns. The framework itself is conceived and implemented, from the ground up, based on design patterns. The framework also 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 simplicity, strong encapsulation and loose coupling; framework components can be interchangeably plugged into complex framework applications using a “lego/messaging” architecture. Framework messages can be processed synchronously or asynchronously. The framework takes full advantage of the power and simplicity of the messaging design pattern/API.
C) The framework lego/messaging architecture provides transparent access to remote components: remote framework objects are treated as local objects. Design patterns implemented by the framework (adapters, remote proxies and facades) make this possible 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, Data Access Object implementations (DAO), Model View Controller implementations (MVC), EJBs, JSP, AJAX, JMS, XML REST and Web Services.
E) The framework is designed to be lightweight and fast (low overhead/small footprint).
F) The framework messaging/lego architecture should improve and simplify design/development efforts. There is a tight correspondence between UML design diagrams and the framework messaging based applications and components needed for the implementation. The framework provides wizards and automated capabilities for generating framework applications. Framework components can be easily added to BPM process diagrams. In future versions of the framework, it should be possible for application modules to be generated directly from the UML design diagrams. This goal is still work in progress.
G) The framework messaging architecture facilitates testing and debugging efforts. The framework provides capabilities for testing components as independent units by sending messages to the component and verifying the expected reply messages."
Probably we need to agree to disagree on this one. I gave several good reasons
to justify our implementation decisions in regards to logging
(dependencies, custom features to handle messaging, etc).
As I mentioned earlier, there are several logging alternatives. People can use their favorite alternative.
This was covered in an earlier posting.
BTW the logging mechanism can also be easily customized to handle any logging API that the user likes.
There are a couple of API methods that can be overridden.
The design is flexible enough to allow theses changes. I believe this a good compromise.
In terms of management; you might want to think the way they do.
It might facilitate your job and theirs (by seeing things from their point of view).
The manager is probably
thinking about cost, speed of development, quality, timeframes. They want
to know if the solution works and how the development process can be improved.
. Technical implementation is probably not on the
top of their list.
Messaging and the Jt Pattern Oriented framework can have a significant impact on all these areas.
These are some of the ramifications.
I'll cover some of these ramifications in more detail later on. This point has been touched
a couple of times,
In regards to the points raised in the past; they'll probably need to be brought up again so that
we can get to the facts.
Per previous advice (sound advice) if the criticism was not constructive,
the posting was probably not even read. Also, they were probably missing some
of the key pieces and facts (understanding of messaging)
If understanding of messaging/facts is missing, it doesn't surprise me that
the opinions/conclusions were incomplete/incorrect.
Please feel free to send any follow-up comments or questions. I’m glad that we uncovering the facts.
Regards
|
|
|
Message #329403
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Just so everyone is on the same page here...
package Jt;
import java.io.*;
import java.util.*;
import java.text.*;
import java.lang.reflect.*;
import java.beans.*;
import org.jbpm.graph.def.ActionHandler;
import org.jbpm.graph.exe.ExecutionContext;
/**
* Root class of the Jt Class hierarchy; it implements the functionality
* required by the Jt Messaging pattern.
*/
public class JtObject implements Serializable, JtInterface, ActionHandler {
...
Perhaps the name of this framework could be changed to: 'jBPM Oriented Framework'?
|
|
|
Message #329418
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Jt Pattern Oriented Framework
Dear Mr Douss,
Very good! I'm glad to hear that there are many people that get the messaging concept.
As I mentioned earlier ... there will be ramifications. This also means that we
are taking care of the misconceptions and uncovering the real facts behind the framework.
Once people understand the concept, the lego pieces start to fit. Messaging was the missing piece.
We need to start thinking in terms of messaging for things to make sense.
I plan to do over these ramification of messaging shortly.
Sorry I have to keep bringing it up. I have to keep hammering
Please bare with me on this one.
It is ideal if everyone gets it. It will be even more interesting.
Actually the best part are all the ramifications of messaging.
That’s the main thing what we want to get at.
Once messaging is understood, people can understand the following:
sendMessage (jtProxy, message) // A message is sent to a remote object via local proxy
// A nice combination of the messaging design pattern and
// Proxy design pattern.
---message-->JtProxy .........network..........> Component
Complex problems like the ones related to the remote interfaces, can be handled via an elegant solution/design.
This is more advanced. It is a complex problem. This is one of the
ramifications of messaging. It can provide an elegant solution to a complex
problems from the real world. It is also a good example to illustrate
the shortcoming of the conventional approach.
Actually I am aware of project for a leading software manufacture were
the messaging approach was employed for a enterprise application:
They were employing the traditional remote APIs. The system was complex, hard to understand and maintain.
It also had some performance problems due to the complexity
It had to be redesigned/re-architected using the messaging approach. Messaging and the Jt framework solved their problems: sendMessage (JtProxy);
As I mentioned earlier, people with a lot of experience are using
the framework for complex problems. The project above is just one example.
These are enterprise systems that solve complex problems of real world.
I'll send you a follow-up reply shortly (dealing with you other points).
Best regards
|
|
|
Message #329419
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Jt Pattern Oriented Framework
Thanks for the suggestion. I'm afraid that the Jt Pattern Oriented Framework integrates with many technologies. Jbpm is just one of them. We also plan to revamp our BPM pieces. This is going to be a long project (one year or so)
"D) The framework provides transparent integration with other technologies via framework adapters, proxies and the implementation of related design patterns. These technologies include BPM, Data Access Object implementations (DAO), Model View Controller implementations (MVC), EJBs, JSP, AJAX, JMS, XML REST and Web Services."
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
