Discussions

News: Jt - Java Pattern Oriented Framework (Jt 4.5)

  1. Jt - Java Pattern Oriented Framework (Jt 4.5) (70 messages)

    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.

    Threaded Messages (70)

  2. lol
  3. wtf
  4. Is this for real?
  5. Does anybody take this seriously?[ Go to top ]

    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.
  6. Re: Does anybody take this seriously?[ Go to top ]

    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.
  7. Re: Does anybody take this seriously?[ Go to top ]

    Totally agree. The worst thing is that a younger programmer might see post this and end up thinking it's a good framework.
  8. 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.
  9. 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"); }
  10. 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 :)
  11. 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"> 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.
  12. 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.
  13. 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.
  14. Commentary[ Go to top ]

    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!
  15. Re: Commentary[ Go to top ]

    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,
  16. Re: Commentary[ Go to top ]

    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.
  17. Further commentary[ Go to top ]

    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.
  18. Re: Further commentary[ Go to top ]

    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!
  19. Re: Further commentary[ Go to top ]

    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 :)

    Even seriously..., that's a lot closer to what it is. Did a bit of searching: "J2EE Pattern Oriented Framework (Jt) & Jt Messaging Pattern Posted by: Dan Evans on September 13, 2006" http://www.theserverside.com/patterns/thread.tss?thread_id=42184 The last comment on this one says it all: http://www.theserverside.com/news/thread.tss?thread_id=50360 http://www.theserverside.com/news/thread.tss?thread_id=57929 indeed, what's new? If I understand this right, JT is a poor wrapper for a lot of good APIs.
  20. Re:Further commentary[ Go to top ]

    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
  21. Feedback[ Go to top ]

    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 ?
  22. Re: Feedback[ Go to top ]

    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
  23. Re: Feedback[ Go to top ]

    @ 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.
  24. Re: Feedback[ Go to top ]

    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
  25. Re: Feedback[ Go to top ]

    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.
  26. Re: Feedback[ Go to top ]

    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???
  27. Re: Feedback[ Go to top ]

    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!
  28. Re: Feedback[ Go to top ]

    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.
  29. Re: Feedback[ Go to top ]

    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.
  30. Re: Feedback[ Go to top ]

    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
  31. Re: Feedback[ Go to top ]

    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
  32. Re: Feedback[ Go to top ]

    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
  33. ...so if you want it once more[ Go to top ]

    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.
  34. 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
  35. Re: Feedback[ Go to top ]

    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
  36. 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.
  37. 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.
  38. 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
  39. 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...
  40. Lol! +1 for the comments
  41. 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 JtServlet Jt.servlet.JtServlet 1 JtServlet /JtRestService 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/
  42. // 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.
  43. 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);
  44. Design and testability questions[ Go to top ]

    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?
  45. Re: Design and testability questions[ Go to top ]

    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,
  46. Didn't catch the irony?[ Go to top ]

    "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".
  47. One more thing[ Go to top ]

    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!
  48. 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..........
  49. 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.
  50. it is not POJO[ Go to top ]

    the model that supported by your framework is POJO. and static is not good method. see another DDD Oriented Framework architecture: https://jdon.dev.java.net/doc.htm
  51. sorry[ Go to top ]

    the model that supported by your framework is *NOT* POJO.
  52. 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.
  53. Pattern oriented framework?[ Go to top ]

    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?
  54. 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.
  55. Dear Mr.Evans[ Go to top ]

    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,
  56. Jt Pattern Oriented Framework[ Go to top ]

    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
  57. Dear Mr. Douss This is a continuation of my previous posting. I have mentioned some of the ramifications of the lego/messaging architecture: - Encapsulation & Reusability: It maximizes encapsulation and reusability. Each component/lego piece is pretty much self-contained. - Coupling: It minimizes coupling - Simplicity. Components are usually simpler. They only need to deal with a very specific set of responsibilities (messages). This also reduces complexity in terms of the framework API - Debugging. It becomes easier because messages are logged automatically. It reduces the need for print/logging statement inside the code. The user is usually able to track down what message/component is causing the problem with minimum effort. - Testing. It is not required to include testing code. Because of messaging this can be done on a component basis/Black box via a harness. - Maintenance. Maintenance is improved because of all the above. - Quality: Quality is also are improved because of all of the above. - Speed of Development: This is improved because of many of the above (In particular reusability of lego components) . - Cost: Reduced cost because of all the above - Simplification in terms of design. The bulk of the work becomes designing a good set of components and the input/ouput messages that need to be handled by each independent component. - Component may use independent threads (independent entities). This is how the real world works. - Learning curve. Our messaging framework doesn’t require a lot of time in terms of learning curve (because of the messaging approach). I covered some of these ramifications in my earlier postings Once the messaging concept is clear the ramification above should become clear as well. This is a also strong case for messaging. There is another ramification that I haven't mentioned so far. It is related to the development/design process. A very large number of people can cooperate in the development without stepping on each other's code/work. Testing can be done independently (test harness) Each component is self-contained. In the ideal situation responsibility for one component/package can be given to an individual. S/he just needs to know what input/output messages the component is supposed to handle. This is result of messaging/component/lego approach. Testing/QA people can do their testing independently. New functionality usually is implemented by adding new messages. Changes made to a component should not break anything else (all the components are pretty independent) " Notice that you have all the freedom that you need. No restrictions at all. You just need to implement the interface above." This comment was in reference to some specific misconceptions that I had to clarify. Of course we have guidelines, best practices, etc (based on s messaging approach). Type safety is fine. We plan to do this as much as possible. In some cases, you need to use generic type. The Iterator java class for instance. This is a implementation of the iterator design pattern. The generic type Object is used. The use of cast is required. There are many other Java classes that need to use the generic java type (Object). They need to be implemented in a generic way. I have to agree with some of the point made earlier. Type safety is good thing. The use of cast should be avoided (when possible). This is not mayor aspect (it doesn't impact functionality). The code can be easily improved. I believe development teams require some freedom. They would probably enjoy the flexibility of a non-intrusive framework. I agree that there should be disciplined approach to doing this. I wouldn't use the word "restrictions". Notice that we have a disciplined approach based on a messaging approach. We also propose some discipline in terms of the use of design patterns (proxies, adapter, etc), There are many benefits as explained earlier. I found a quote that might be relevant to our discussion. I agree that there are many benefits can be found in the component approach. In the article, Joe Nuxoll,.. says that "the lack of a vibrant Java component market may partly be the result of a cultural gap....In the Java world, the solutions are focused on class libraries, not component libraries. .NET developers, on the other hand, think of solving problems in terms of components, rather than class libraries and configuration files." Again I'm glad to hear that many people understand messaging. The ramifications that I mention above should be clear. It should be easier to see all the benefits that messaging brings to enterprise applications and problem from the real world. Please feel free to send any follow-up comments or questions. Best regards,
  58. - Encapsulation & Reusability: It maximizes encapsulation and reusability.
    Each component/lego piece is pretty much self-contained.

    - Coupling: It minimizes coupling

    - Simplicity. Components are usually simpler. They only need to deal
    with a very specific set of responsibilities (messages).
    This also reduces complexity in terms of the framework API


    - Debugging. It becomes easier because messages are logged automatically. It reduces
    the need for print/logging statement inside the code. The user is usually able to
    track down what message/component is causing the problem with minimum effort.

    - Testing. It is not required to include testing code.
    Because of messaging this can be done on a component basis/Black box
    via a harness.


    - Maintenance. Maintenance is improved because of all the above.

    - Quality: Quality is also are improved because of all
    of the above.

    - Speed of Development: This is improved because of many of
    the above (In particular reusability of lego components) .

    - Cost: Reduced cost because of all the above

    - Simplification in terms of design. The bulk of the work becomes designing
    a good set of components and the input/ouput messages that
    need to be handled by each independent component.


    - Component may use independent threads (independent entities).
    This is how the real world works.
    - Learning curve. Our messaging framework doesn’t require a lot of time in terms of learning curve (because of the messaging approach).
    I'm really sorry, but I don't agree at all. I don't really have enough time to discuss every point, but it should be obvious that the messaging approach is all against (almost) every point you mentioned. Messaging approach should be used only when needed and avoided if possible.
    Type safety is fine. We plan to do this as much as possible.
    How would you do it ?? Would you break the framework logic ? I don't really see how it could be done while keeping messaging.
    I believe development teams require some freedom. They would probably enjoy the flexibility of a non-intrusive framework.
    I agree with freedom for development teams, but freedom should not exist when writing code. Using Jt Framework, will let many errors that could be avoided at compile time, to compile fine and only discovered (often with luck) at runtime. And just I want to ask : do you really think that your framework is non-intrusive ?? Regards,
  59. I welcome your opinion. I understand the time limitations. On the other hand, I'm sure you agree that an opinion need to come with reasons/facts/examples in order to carry real weight. I have given plenty of reasons/examples/facts that support the messaging/lego approach. There is a strong case for messaging based on facts/examples, etc Some of the following ramifications should be very clear (Maximum encapsulation, Minimum coupling, Easier debugging, etc.). Complex problems like the ones related to the remote interfaces, can be handled via an elegant solution: sendMessage (JtProxy, message); // 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. "I have mentioned some of the ramifications of the lego/messaging architecture: - Encapsulation & Reusability: It maximixes encapsulaption and reusability. Each component/lego piece is prety much self-contained. - Coupling: It minimizes coupling - Simplicity. Components are usually simpler. They only need to deal with a very specific set of reposabilities (messages). This also Reduces complexity in terms of the framework API - Debugging. Easier because messages are logged automatically. It reduces the need for logging messages inside the code. The user is usually able to track down what message/component is causing the problem. - Testing. It is not required to include testing code. Because of messaging this can be done on a component basis/Black box via a harness. - Maintenance. Maintenance is improved because of all the above, - Quality: Quality is also are improved because of all of the above. - Speed of Development: This is improved because of many of the above. - Cost: Reduced cost because of all the above - Simplification in terms of design. The bulk of the work becomes designing a good set of components and the input/ouput messages that need to be handled by each independent component. - Component may use independent threads (independent entities). This is how the real world works." In summary, there is very strong case for messaging. In our opinion it is just a matter of time before messaging becomes widely used. Obviously the messaging approach is key. The Iterator class implements the Iterator design pattern. It uses a generic approach (Object class and cast). There are many other Java classes that use this approach. Nobody expects these Java classes to be changed/restricted. Type safety is good. That doesn't mean that it should be used for everything. In my opinion we don't want to become fanatic about it. Type safety is not the solution for every problem. In particular, for problems where a generic type is needed. THere are cases where Type safety is not possible. The Iterator implementation is a good example. Since our framework implements design patterns (generic solutions) there will be many places where we need to keep it generic (Object class/cast). There are other cases where we can restrict the type and use type safety. Somewhere in the middle is probably a good compromise, I have to agree with you. The compiler won't be able to catch all the errors. On the other hand, the Java classes won't be changed because of this (Iterator for instance). We won't be able to change all our classes These classes try to solve generic problems and they need to be implemented using a generic approach (Object and cast). In my opinion this is not such a big issue. The Object type is used very often. I agree that people need to be more careful since the compiler won't be able to catch as many errors. In my opinion people need some degree of freedom while they write code. It is a creative activity. It is OK. We don't need to agree on every single aspect. I agree that a disciplined approach is required: guidelines, best practices, some limitations. Yes. I think the framework is non-intrusive. It does a lot via a set of lego pieces/component/design pattern that you can reuse. It also gives you the Jt Messaging 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); } Understanding messaging is 90% of the effort. 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 processMessage (receiving component) removeObject This seems very straightforward, flexible and non-intrusive. It is true; It requires a disciplined/messaging/component approach: "In the article, Joe Nuxoll,.. says that "the lack of a vibrant Java component market may partly be the result of a cultural gap....In the Java world, the solutions are focused on class libraries, not component libraries. .NET developers, on the other hand, think of solving problems in terms of components, rather than class libraries and configuration files." If this component/messaging approach is followed all the benefits listed above should become evident. Feel free to send any additional follow-up comments or questions. Best regards
  60. 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'?
  61. Jt Pattern Oriented Framework[ Go to top ]

    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."
  62. Another short question[ Go to top ]

    What's the purpose of this class? (my code review comments included) package Jt; import java.util.*; /** * Handles a list of objects. */ public class JtList extends JtObject { //so how am I going to know I'm serializing //the correct version? private static final long serialVersionUID = 1L; public static final String JtCLASS_NAME = JtList.class.getName(); //no generics - java 4 is dead since long ago //access to list using implementation not interface private LinkedList col = null; public static final String JtADD = "JtADD"; public static final String JtCLEAR = "JtCLEAR"; public static final String JtFIRST = "JtFIRST"; public static final String JtLAST = "JtLAST"; public static final String JtREMOVE_FIRST = "JtREMOVE_FIRST"; public static final String JtREMOVE_OBJECT = "JtREMOVE_OBJECT"; //parameterless constructor //not setting the internal list //so one can create the object //in an inappropriate state public JtList() { } /** * Returns the LinkedList used to implement this class. */ //does not return a defensive copy of the list //so the internal state of the class is mutable public LinkedList getLinkedList () { return (col); } /** * Sets the LinkedList used to implement this class. */ //ok so now no preservation of the old values //is foreseen? public void setLinkedList (LinkedList col) { this.col = col; } /** * Returns a JtIterator. */ public Object getIterator () { JtIterator jit; //Collection values; jit = new JtIterator (); //why null in brackets? if (col == null) return (null); /* //Commented out code - why? values = col.values (); if (values == null) return (null); */ jit.setIterator(col.iterator ()); return (jit); } /** * void operation. */ //your method and void - why? public void setIterator (Object iterator) { } /** * Void operation. */ //why void? document it please public void setSize (int size) { // this.size = this.size; // void operation } /** * Returns the number of elements in this list. */ public int getSize () { return (col != null ? col.size (): 0); } /** * Process object messages. *
      *
    • JtADD - Appends the object specified by msgContent to the end of * this list *
    • JtCLEAR - Removes all the objects from this list *
    • JtFIRST - Returns the first element in the list *
    • JtLAST - Returns the last element in the list *
    • JtREMOVE_FIRST - Removes and returns the first element in the list *
    • JtREMOVE_OBJECT - Removes the object specified by msgContent. *
    * @param message Jt Message */ public Object processMessage (Object message) { //uh-huh, so the Object is really //a JtMessage, in any other case //you get a ClassCastException? String msgid = null; JtMessage e = (JtMessage) message; Object content; //Object data; //null returning framework, very risky if (e == null) return null; msgid = (String) e.getMsgId (); //where are the cases of null returns //documented? if (msgid == null) return null; content = e.getMsgContent(); //data = e.getMsgData (); // Remove this object //what is removed? null is returned //while nothing is removed! if (msgid.equals (JtObject.JtREMOVE)) { return (null); } if (msgid.equals (JtList.JtADD)) { // Add object to the list if (content == null) { handleWarning ("JtList.processMessage(JtADD):invalid content (null)"); return (this); } //this method is useless in multithreaded //environment, but this is not documented if (col == null) col = new LinkedList (); col.add (content); return (this); } //following methods are just a mockery //above java.util.List API if (msgid.equals (JtList.JtCLEAR)) { if (col != null) { col.clear (); } return (this); } if (msgid.equals (JtList.JtFIRST)) { if (col == null) return (null); if (col.size () < 1) { return (null); } return (col.getFirst ()); } if (msgid.equals (JtList.JtLAST)) { if (col == null) return (null); if (col.size () < 1) { return (null); } return (col.getLast ()); } if (msgid.equals (JtList.JtREMOVE_FIRST)) { if (col == null) return (null); if (col.size () < 1) { return (null); } return (col.removeFirst ()); } if (msgid.equals (JtList.JtREMOVE_OBJECT)) { // Remove an object from the collection if (content == null) { handleWarning ("JtList.processMessage(JtREMOVE_OBJECT):invalid message content (null)"); return (null); } if (!col.contains (content)) { handleError ("element not found " + content); return (null); } col.remove (content); //why return null after remove? return (null); } //what has list in common with JtObject? return (super.processMessage(message)); } /** * Demonstrates the messages processed by JtList. */ //so this is the "unit" test? public static void main(String[] args) { JtObject main = new JtObject (); JtMessage msg; JtIterator it; Object obj; Integer I; //main.setObjTrace (1); //main.setLogFile ("log.txt"); // Create a JtList main.createObject (JtList.JtCLASS_NAME, "list"); msg = (JtMessage) main.createObject (JtMessage.JtCLASS_NAME, "message"); main.setValue (msg, "msgId", JtList.JtADD); main.setValue (msg, "msgContent", new Integer (1)); // Add an object to the list main.sendMessage ("list", msg); main.setValue (msg, "msgId", JtList.JtADD); main.setValue (msg, "msgContent", I = new Integer (2)); // Add object to the list main.sendMessage ("list", msg); System.out.println ("Size=" + main.getValue ("list", "size")); obj = (Object) main.sendMessage ("list", new JtMessage (JtList.JtFIRST)); System.out.println ("First=" + obj); obj = (Object) main.sendMessage ("list", new JtMessage (JtList.JtLAST)); System.out.println ("Last=" + obj); it = (JtIterator) main.getValue ("list", "iterator"); for (;;) { obj = (Object) main.sendMessage (it, new JtMessage (JtIterator.JtNEXT)); if (obj == null) break; System.out.println (obj); } main.setValue (msg, "msgId", JtList.JtREMOVE_OBJECT); main.setValue (msg, "msgContent", I); main.sendMessage ("list", msg); System.out.println ("Size=" + main.getValue ("list", "size")); // Clear the list main.setValue ("message", "msgId", JtList.JtCLEAR); main.sendMessage ("list", "message"); main.removeObject ("list"); } } Could you please take a look at the review?
  63. I'll pass your comments around. I can speak in general terms about some of these components. As I mentioned earlier, the concept/"abstraction" is the main thing Implementation is second nature. Another important aspect is that these components work. They meet the requirements of a messaging a approach. On the other hand, this List component is a very simple component. I have provided other components that really showcase the capabilities of the framework (Rest, Web services, etc.) We didn't plan to reinvent the list object using the latest JVM version. This will never be one of our goals. Obviously it wouldn’t bring additional benefits. Per my previous emails we need to be thinking in terms of messaging. We might want to ask .... Why are these components useful in a messaging environment? How should they be implemented within a messaging environment? These components are designed to handle messaging. They can be included in BPM/UML diagrams. These components can be accessed remotely (transparent access) using messaging: “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.” These are the main advantages that the simple List component provides. Additional questions that people may ask ... working within a messaging approach: How can I ask the component to do housekeeping (release the resources that were allocated)? Answer: The JtREMOVE message ID is used for this. "Some component need to process the JtREMOVE message. This message is sent to the object when the removeObject method is called. Upon receiving this message, the object should release any resources that were allocated (database connections, sockets, etc). Our simple Hello World class doesn’t need to release any resources; the following piece of code is sufficient: if (msgid.equals (JtObject.JtREMOVE)) { return (null); }" What should I do If component doesn't need to return a reply ? 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); } Anwers: Since the framework components implement the messaging interface (JtInterface) they need to return something. null is returned. This is clear and simple. This should be safe because the sender is not expecting any reply as result of the specific message. - Do I need to implement Java serialization within the messaging framework? - How about mutable class? These are not required within the context of the Jt messaging framework. - JUnit testing: we already covered this point (previous postings) - Earlier versions of JVM: They need to be supported because of production systems (previous postings) - How do I implement multithreading within the Jt messaging framework? As a ramification of messaging each component is self-contained. They can also execute using an independent/separate thread. This is very natural (a good representation of how the real world works). JtThread Framework objects that inherit from JtThread can execute in a separate/independent thread. This class handles the complexities associated with dealing with multiple threads. Jt Messages sent to the object are processed asynchronously using the separate thread. JtSTART and JtSTOP start and stop the thread. What is the JtMessage used for? As mentioned earlier (previous postings) sender and receiver need to agree on the message format. "JtInterface can handle any type of message (Object class). You can define your own message types; MyMessageType for instance. 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.)." I hope this answers some of your questions. We need to think in term of messages. I afraid I need to keep reiterating this point. That is the only way in which the framework and the implementation/ramifications can be understood. A traditional mindset will probably not work (the messaging point and the ramifications will probably be missed).
  64. BTW, I forgot to mention that for a list object that needs to be accessed locally (no UML/BPM) our Jt component doesn't provide any extra benefits. The functional approach works just fine in this case.
  65. Don't use names you don't understand[ Go to top ]

    Java is an Object Oriented, not a functional language. A typical object oriented approach means e.g: java.util.List.add( new Car() ); ...and functional approach means something completely different. When it comes to serialization: how do you image working in a server environment without serialization. Your "framework" is, as you say, designed for component based projects. If so, some of them may be remote, and objects have to be serializable to be transmitted through a network protocol. Mutability: with your statement you just revealed your lack of knowledge of Java's basics. I don't think that anyone who took the time to browse your code may consider using it. Threading: So you start a separate thread for every task inside your "framework". So how is it possible to call your processMessage nonsense being sure that the Object received is the correct one?
  66. with your statement you just revealed your lack of knowledge of Java's basics.
    Why do you have to be such a dick? I do not know creator of this framework, not am in any way affiliated with it, but, he is doing honest work, he was polite to explain his views, made his business proposal, you may like it or you may not, and it was clear from your (and other posters) that you believe there are better ways to accomplish what he is trying to do. Putting down someone like this is not nice, I mean, who the feck are you to judge someone? Lets say I do your tactics and quote you:
    //why null in brackets? if (col == null) return (null);
    Do you have any idea how ridiculous/irrelevant/childlish this is? Yes, brackets are not needed in this statement, but it shows that you basically scanned through code looking for any (even the smallest and most irrelevant) errors so you can boost your epeen ratings. What you gonna complain next about, maybe because he of indentation he uses?
  67. You're basically right, but..[ Go to top ]

    I agree with you that making such detailed comments may blur the overall vision, but have you scanned through the comments Mr. Evans did? Repeating the same slogans and buzzwords all the time without ANY proof of his statements. I understand your point - people should be humble and tolerant in expressing their opinions, but the nonsense of this idea is simply so blatant, that I just couldn't put it in any other way. How many times (if you are working in a larger organisation) have you heard some wanna-be-manager or nearly-as-good-as-(put your favorite architect here) telling you empty words about how great his politically or mentally motivated "framework" will help you put your work and company's money down the drain?
  68. /**
    * Root class of the Jt Class hierarchy; it implements the functionality
    * required by the Jt Messaging pattern.
    */

    public class JtObject

    ....

    First I don't understand why you named all of your classes with Jt*... Perhaps one should not think they are using java.lang classes? :-)

    Second, your documentation is flawed just like your framework, IMHO. Why for the sake of good documentation, you write useless documentation... like... "This class implements funcionality required by this other class" ???

    Thanks, but no thanks. I rather code my programs with POJaC (plain old java classes).
  69. Folks, We are pleased to announce version 4.9. The documentation and some of the examples have been revised in order to avoid potential confusion and/or misconceptions. A test harness based on Junit has been included. We’ll keep it up-to-date. For the now, the test harness mainly deals with the core Jt components and new components. Thank you for your feedback. Best regards -------------------------------------------------------------------------------- Jt4.9 - Java Pattern Oriented Framework - Axis/RESTful Web Services Jt4.9 has been released. Jt is a design pattern 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.9 features several components for implementing web services (Axis/RESTful). This implementation is based on Jt design patterns and components: - Axis and RESTful web services - Transparent access to remote components and services via a messaging approach. Design patterns implemented by the Jt framework (adapters, remote proxies and facades) make this possible by hiding the complexities associated with remote APIs. - Reusable components for bean/XML conversion - Security features via Access Manager component - Test harness and enhanced documentation based on feedback received from members of the TSS community - http://freedom.lunarpages.com/Jt/Jt.htm - Simple configuration of Web Services .......
  70. BTW, type safety is also being used when possible. The Java components are being revised without changing functionality.
  71. Hi folks,


    We are working on a paper for publication regarding the Messaging Design Pattern and the Jt Design Pattern Framework:

    http://jt.dev.java.net/files/documents/5553/149437/JtFramework1.pdf
     

    Enjoy