NEW DESIGN PATTERN:TAGLIBS only.No servlets

We followed the following architecture:
request response
| *
| *
servlet JSP
ejb
1.Request is given to servlet.
2.servlet fetches data from the Ejb layer
3.servlet forwards data to jsp
4.jsp genreates view to the user
Now we find the following Main TROUBLE with this architecture
The jsp can present only those data that has been provided by the Servlet,i.e. jsp can not demand various differnt types of data from the business layer as it needs.
Reason is Servlet forwards the JSP.
solution we identified is use taglibs to interact with the ejb layer.
jsp will use this tag lib to interact with the business tier.
request/RESPONSE
|
|
jsp ------->TAGLIBS
|
----------------|------
EJB LAYER
Is there any one else who uses such architecture ?
What are the other advantages and disadvantages of this architecture ?

This is a rather standard architecture. The servlet is responsible for collecting all the data that needs to be presented from the business layer. The only responsibility of the JSP is to render this data on screen (generating HTML). The JSP itself must not be bothered with business logic.
Take a look at Struts (http://jakarta.apache.org/struts/). This framework implements the described architecture (aka JSP Model 2).
--Arnout                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

Similar Messages

  • ANN: New Design Pattern (DAO)

    Hello,
    Thanks for your overwhelming response to our previous sample applications demonstrating various [url http://www.oracle.com/technology/sample_code/tech/java/j2ee/designpattern/index.html]design patterns.
    Continuing with the series, this month we have showcased the [url http://www.oracle.com/technology/sample_code/tech/java/j2ee/designpattern/dataaccesstier/index.html]Data Access Object (DAO) Design Pattern which is considered as a best practice for applications accessesing the database or the underlying persistence layer from the business tier.
    The DAO implements the access mechanism required to work with the data source. The data source could be a persistent store like an RDBMS, an external service like a B2B exchange, a repository like an LDAP database, or an XML Repository. Using the scenario of web based News Application, this sample application demonstrates the effective use of this pattern.
    [url http://www.oracle.com/technology/sample_code/tech/java/j2ee/designpattern/dataaccesstier/index.html]Download the sample application to learn more about this pattern.
    More Sample Applications are available at [url http://www.oracle.com/technology/sample_code/index.html]
    http://www.oracle.com/technology/sample_code/index.html
    Thanks,
    Rajat
    OTN Team

    Hi
    This is because you are not using the latest jdbc driver version. Either use the latest ojdbc14.jar downloadable from the location given in the readme(Oracle Database 10g (10.1.0.2.0) drivers),
    Or simply comment this part in the code.
    Also you may just replace the close method call with ods=null;
    Hope this helps
    Shrinivas

  • Design pattern of servlet context

    hi all
    can u please tell me what design pattern is used in servlet context.
    thanks

    http://www.google.com/search?hl=en&client=netscape-pp&rls=com.netscape%3Aen-US&q=design+pattern+for+servlet+&btnG=Search

  • The drawback of design patterns

    It is more and more important to get the skill of using design patterns as a programmer , and there is many material about it , all of them talking about the benefits of using patterns, But I know that Patterns is not so better as they argued , Patterns also have deficiency , Patterns can not be used every where .....
    What I want here is that I hope to hear heatly discussing about the "the drawback of design patterns" , please using your head , typing what u know here !

    Patterns can not solve the problems such as "code
    scattening" and "code tangling"Okay, so there are some problems that patterns can't solve. Apparently by your logic, the fact that concrete doesn't cure cancer is a deficiency of concrete. I suppose that's logically defensible, but it also contains precisely zero information, so it's a pointless statement.
    , these the
    headaches are in the domain of OO , Design Patterns
    are only smart design idiom within OO , but they can
    not solve the drawback of OO , and Patterns should
    not be used everywhere Okay. So, again, concrete is in the domain of construction, but it cannot solve the drawbacks of construction, so that's a deficiency of concrete. Again, zero information, thus pointless.
    , the places where they should
    be used is the place where u face "May be change in
    the future " ! Patterns are not so much about future change as they are about providing a common vocabulary--a means of communication--and a stock of parts to draw from when solving certain problems.
    Use Patterns add many classes into your code ,Maybe, maybe not.
    Good design adds classes. Poor design stuffs everything into a few bloated classs. Many classes is not necessarily a bad thing, and if you've employed good design, you'll likely have the same design as specified in a pattern. So using patterns doesn't in and of itself add classes. The pattern-ness comes into play in applying the name to the good design you did anyway.

  • Connecting - JavaFX + Servlets(??) + design patterns

    Hello
    I'm a total noob in JEE world so I'm sorry if I'm asking for sth really basic.
    I would like to connect my JavaFX application with a simplest there is JEE-server. My guess is - Servlets (a good guess?). But before I start, here are some obstructions I need to face. The general goal of this whole project is to test few (around 5) JEE design patterns. It's because of my science project: "The use/usage of JEE design patterns in creating web applications". So what's the JavaFX for? My promotor asked for an application that would be handy for my College. So again what is going to be done :
    - connect the JFX app with JEE server
    - test the whole project with Cobertura, Checkstyle, Apache JMeter, Findbug, Cobertura, PMD/CMd and so on
    - refactor the project with 5 design patterns. I think I'll try to use: DAO, Intercepting Filter, any suggestions what more?
    - test again
    - compair test results. Make conclusion on the thesis.
    As for now I've found JFX class that could be used to communicate:
    http://java.sun.com/javafx/1.2/docs/api/javafx.io.http/javafx.io.http.HttpRequest.html and other from javafx.io.http
    I'm looking for the simplest way because I don't have a lot of time! :(((( So, is there a book, tool or a tutorial explaining how to quickly and simply do the stuff above?
    What I have installed:
    - winXP SP3 (linux and Eclipse still are crappy with JFX)
    - Netbeans 6.7.1 with JavaFX and now I've installed additionally:
         - Java Web Applications
         - Sun Java System Web Server 7.0
         - EJB and EAR
    Anything else I need?

    Why don't using ejb for remote client?
    It can be simpliest, you avoid web tier dev in the server and http on the fx side.
    Any version requieried for the JEE? With the sixth one, few annotations and just concentrate on your job, very nice.

  • Design Pattern for Servlets

    Hello,
    I am about to organize my huge servlet code. I have a web application which is currently running as a single servlet (I know bad bad design) and I want to filter out from there to a more manageable and appropriate design. I researched the internet and did not find a compelling design pattern or library that I can use to do the same. I would really appreciate if experienced folks could share what design patterns they use for the entry servlet to their web-app. Thanks in advance.
    Ravi.

    Check out the famous Struts.
    Regards,
    Reflex

  • New(?) pattern looking for a good home

    Hi everyone, this is my second post to sun forums about this, I initially asked people for help with the decorator and strategy pattern on the general Java Programming forum not being aware that there was a specific section for design pattern related questions. Since then I refined my solution somewhat and was wondering if anyone here would take a look. Sorry about the length of my post, I know it's best to keep it brief but in this case it just seemed that a fully functional example was more important than keeping it short.
    So what I'd like to ask is whether any of you have seen this pattern before and if so, then what is it called. I'm also looking for some fresh eyes on this, this example I wrote seems to work but there are a lot of subtleties to the problem so any help figuring out if I went wrong anywhere is greatly appreciated. Please do tell me if you think this is an insane approach to the problem -- in short, might this pattern have a chance at finding a good home or should it be put down?
    The intent of the pattern I am giving below is to modify behavior of an object at runtime through composition. In effect, it is like strategy pattern, except that the effect is achieved by wrapping, and wrapping can be done multiple times so the effect is cumulative. Wrapper class is a subclass of the class whose instance is being wrapped, and the change of behavior is accomplished by overriding methods in the wrapper class. After wrapping, the object "mutates" and starts to behave as if it was an instance of the wrapper class.
    Here's the example:
    public class Test {
         public static void main(String[] args) {
              double[] data = { 1, 1, 1, 1 };
              ModifiableChannel ch1 = new ModifiableChannel();
              ch1.fill(data);
              // ch2 shifts ch1 down by 1
              ModifiableChannel ch2 = new DownShiftedChannel(ch1, 1);
              // ch3A shifts ch2 down by 1
              ModifiableChannel ch3A = new DownShiftedChannel(ch2, 1);
              // ch3B shifts ch2 up by 1, tests independence from ch3A
              ModifiableChannel ch3B = new UpShiftedChannel(ch2, 1);
              // ch4 shifts ch3A up by 1, data now looks same as ch2
              ModifiableChannel ch4 = new UpShiftedChannel(ch3A, 1);
              // print channels:
              System.out.println("ch1:");
              printChannel(ch1);
              System.out.println("ch2:");
              printChannel(ch2);
              System.out.println("ch3A:");
              printChannel(ch3A);
              System.out.println("ch3B:");
              printChannel(ch3B);
              System.out.println("ch4:");
              printChannel(ch4);
         public static void printChannel(Channel channel) {
              for(int i = 0; i < channel.size(); i++) {
                   System.out.println(channel.get(i) + "");
              // Note how channel's getAverage() method "sees"
              // the changes that each wrapper imposes on top
              // of the original object.
              System.out.println("avg=" + channel.getAverage());
    * A Channel is a simple container for data that can
    * find its average. Think audio channel or any other
    * kind of sampled data.
    public interface Channel {
         public void fill(double[] data);
         public double get(int i);
         public double getAverage();
         public int size();
    public class DefaultChannel implements Channel {
         private double[] data;
         public void fill(double[] data) {
              this.data = new double[data.length];
              for(int i = 0; i < data.length; i++)
                   this.data[i] = data;
         public double get(int i) {
              if(i < 0 || i >= data.length)
                   throw new IndexOutOfBoundsException("Incorrect index.");
              return data[i];
         public double getAverage() {
              if(data.length == 0) return 0;
              double average = this.get(0);
              for(int i = 1; i < data.length; i++) {
                   average = average * i / (i + 1) + this.get(i) / (i + 1);
              return average;
         public int size() {
              return data.length;
    public class ModifiableChannel extends DefaultChannel {
         protected ChannelModifier modifier;
         public void fill(double[] data) {
              if (modifier != null) {
                   modifier.fill(data);
              } else {
                   super.fill(data);
         public void _fill(double[] data) {
              super.fill(data);
         public double get(int i) {
              if(modifier != null)
                   return modifier.get(i);
              else
                   return super.get(i);
         public double _get(int i) {
              return super.get(i);
         public double getAverage() {
              if (modifier != null) {
                   return modifier.getAverage();
              } else {
                   return super.getAverage();
         public double _getAverage() {
              return super.getAverage();
    public class ChannelModifier extends ModifiableChannel {
         protected ModifiableChannel delegate;
         protected ModifiableChannel root;
         protected ChannelModifier tmpModifier;
         protected boolean doSwap = true;
         private void pre() {
              if(doSwap) { // we only want to swap out modifiers once when the
                   // top call in the chain is made, after that we want to
                   // proceed without it and finally restore doSwap to original
                   // state once ChannelModifier is reached.
                   tmpModifier = root.modifier;
                   root.modifier = this;
                   if(delegate instanceof ChannelModifier)
                        ((ChannelModifier)delegate).doSwap = false;
         private void post() {
              if (doSwap) {
                   root.modifier = tmpModifier;
              } else {
                   if(delegate instanceof ChannelModifier)
                             ((ChannelModifier)delegate).doSwap = true;
         public ChannelModifier(ModifiableChannel delegate) {
              if(delegate instanceof ChannelModifier)
                   this.root = ((ChannelModifier)delegate).root;
              else
                   this.root = delegate;
              this.delegate = delegate;
         public void fill(double[] data) {
              pre();
              if(delegate instanceof ChannelModifier)
                   delegate.fill(data);
              else
                   delegate._fill(data);
              post();
         public double get(int i) {
              pre();
              double result;
              if(delegate instanceof ChannelModifier)
                   result = delegate.get(i);
              else
                   result = delegate._get(i);
              post();
              return result;
         public double getAverage() {
              pre();
              double result;
              if(delegate instanceof ChannelModifier)
                   result = delegate.getAverage();
              else
                   result = delegate._getAverage();
              post();
              return result;
         public int size() {
              //for simplicity no support for modifying size()
              return delegate.size();
    public class DownShiftedChannel extends ChannelModifier {
         private double shift;
         public DownShiftedChannel(ModifiableChannel channel, final double shift) {
              super(channel);
              this.shift = shift;
         @Override
         public double get(int i) {
              return super.get(i) - shift;
    public class UpShiftedChannel extends ChannelModifier {
         private double shift;
         public UpShiftedChannel(ModifiableChannel channel, final double shift) {
              super(channel);
              this.shift = shift;
         @Override
         public double get(int i) {
              return super.get(i) + shift;
    Output:ch1:
    1.0
    1.0
    1.0
    1.0
    avg=1.0
    ch2:
    0.0
    0.0
    0.0
    0.0
    avg=0.0
    ch3A:
    -1.0
    -1.0
    -1.0
    -1.0
    avg=-1.0
    ch3B:
    1.0
    1.0
    1.0
    1.0
    avg=1.0
    ch4:
    0.0
    0.0
    0.0
    0.0
    avg=0.0

    jduprez wrote:
    Hello,
    unless you sell your design better, I deem it is an inferior derivation of the Adapter pattern.
    In the Adapter pattern, the adaptee doesn't have to be designed to support adaptation, and the instance doesn't even know at runtime whether it is adapted.
    Your design makes the "modifiable" class aware of the modification, and it needs to be explicitly designed to be modifiable (in particular this constrains the implementation hierarchy). Overall DesignPattern are meant to provide flexibility, your version offers less flexibility than Adapter, as it poses more constraint on the modifiable class.
    Another sign of this inflexibility is your instanceof checks.
    On an unrelated note, I intensely dislike your naming choice of fill() vs _fill()+, I prefer more explicit names (I cannot provide you one as I didn't understand the purpose of this dual method, which a good name would have avoided, by the way).
    That being said, I haven't followed your original problem, so I am not aware of the constraints that led you to this design.
    Best regards,
    J.
    Edited by: jduprez on Mar 22, 2010 10:56 PMThank you for your input, I will try to explain my design better. First of all, as I understand it the Adapter pattern is meant to translate one interface into another. This is not at all what I am trying to do here, I am trying to keep the same interface but modify behavior of objects through composition. I started thinking about how to do this when I was trying to apply the Decorator pattern to filter some data. The way I would do that in my example here is to write an AbstractChannelDecorator that delegates all methods to the Channel it wraps:
    public abstract class AbstractChannelDecorator implements Channel {
            protected Channel delegate;
    ...// code ommitted
         public double getAverage() {
              return delegate.getAverage();
    ...// code ommitted
    }and then to filter the data I would extend it with concrete classes and override the appropriate methods like so:
    public class DownShiftedChannel extends AbstractChannelDecorator {
         ...// code ommitted
         public double get(int i) {
              return super.get(i) - shift;
           ...// code ommitted
    }(I am just shifting the data here to simplify the examples but a more realistic example would be something like a moving average filter to smooth the data).
    Unfortunately this doesn't get me what I want, because getAverage() method doesn't use the filtered data unless I override it in the concrete decorator, but that means I will have to re-implement the whole algorithm. So that's pretty much my motivation for this, how do I use what on the surface looks like a Decorator pattern, but in reality works more like inheritance?
    Now as to the other points of critique you mentioned:
    I understand your dislike for such method names, I'm sorry about that, I had to come up with some way for the ChannelModifier to call ModifiableChannel's super's method equivalents. I needed some way to have the innermost wrapped object to initiate a call to the topmost ChannelModifier, but only do it once -- that was one way to do it. I suppose I could have done it with a flag and another if/else statement in each of the methods, or if you prefer, the naming convention could have been fill() and super_fill(), get() and super_get(), I didn't really think that it was that important. Anyway, those methods are not meant to be used by any other class except ChannelModifier so I probably should have made them protected.
    The instanceof checks are necessary because at some point ChannelModifier instance runs into a delegate that isn't a ChannelModifier and I have to somehow detect that, because otherwise instead of calling get() I'd call get() which in ModifiableChannel would take me back up to the topmost wrapper and start the whole call chain again, so we'd be in infinite recursion. But calling get() allows me to prevent that and go straight to the original method of the innermost wrapped object.
    I completely agree with you that the example I presented has limited flexibility in supporting multiple implementations. If I had two different Channel implementations I would need two ModifiableChannel classes, two ChannelModifiers, and two sets of concrete implementations -- obviously that's not good. Not to worry though, I found a way around that. Here's what I came up with, it's a modification of my original example with DefaultChannel replaced by ChannelImplementation1,2:
    public class ChannelImplementation1 implements Channel { ... }
    public class ChannelImplementation2 implements Channel { ... }
    // this interface allows implementations to be interchangeable in ChannelModifier
    public interface ModifiableChannel {
         public double super_get(int i);
         public double super_getAverage();
         public void setModifier(ChannelModifier modifier);
         public ChannelModifier getModifier();
    public class ModifiableChannelImplementation1
              extends ChannelImplementation1
              implements ModifiableChannel {
         ... // see DefaultChannel in my original example
    public class ModifiableChannelImplementation2
              extends ChannelImplementation1
              implements ModifiableChannel { ...}
    // ChannelModifier is a Channel, but more importantly, it takes a Channel,
    // not any specific implementation of it, so in effect the user has complete
    // flexibility as to what implementation to use.
    public class ChannelModifier implements Channel {
         protected Channel delegate;
         protected Channel root;
         protected ChannelModifier tmpModifier;
         protected boolean doSwap = true;
         public ChannelModifier(Channel delegate) {
              if(delegate instanceof ChannelModifier)
                   this.root = ((ChannelModifier)delegate).root;
              else
                   this.root = delegate;
              this.delegate = delegate;
         private void pre() {
              if(doSwap) {
                   if(root instanceof ModifiableChannel) {
                        ModifiableChannel root = (ModifiableChannel)this.root;
                        tmpModifier = root.getModifier();
                        root.setModifier(this);
                   if(delegate instanceof ChannelModifier)
                        ((ChannelModifier)delegate).doSwap = false;
         private void post() {
              if (doSwap) {
                   if(root instanceof ModifiableChannel) {
                        ModifiableChannel root = (ModifiableChannel)this.root;
                        root.setModifier(tmpModifier);
              } else {
                   if(delegate instanceof ChannelModifier)
                             ((ChannelModifier)delegate).doSwap = true;
         public void fill(double[] data) {
              delegate.fill(data);
         public double get(int i) {
              pre();
              double result;
              if(delegate instanceof ModifiableChannel)
    // I've changed the naming convention from _get() to super_get(), I think that may help show the intent of the call
                   result = ((ModifiableChannel)delegate).super_get(i);
              else
                   result = delegate.get(i);               
              post();
              return result;
         public double getAverage() {
              pre();
              double result;
              if(delegate instanceof ModifiableChannel)
                   result = ((ModifiableChannel)delegate).super_getAverage();
              else
                   result = delegate.getAverage();
              post();
              return result;
         public int size() {
              return delegate.size();
    public class UpShiftedChannel extends ChannelModifier { ...}
    public class DownShiftedChannel extends ChannelModifier { ... }

  • SERVICE LOCATOR ?? Is it really an interesting Design pattern??

    Hi everybody,
    i've a problem with the J2EE Design Pattern "Services locator" (it's a singleton).
    It is said that by making use of a Service Locator we can :
    - hide to the client the complexities of initial context creation, EJB home object lookup,and EJB objectre-creation.
    - multiple clients can reuse the Service Locator object to reduce code complexity, provide a single point of control, and improve performance by providing a caching facility.
    But i would like to understand at which side should that service locator object reside??!!??
    If it is at server side then the clients need well an initial context in order to make a lookup on that object.
    Conclusion :
    the service locator doesn't hide the complexities of initial context!!
    Furthermore the client has to perform a look-up on that service locator object!! The only advantage left is caching facility.
    If it is at client side, each client needs his own services locator object
    Conclusion :
    multiple client don't reuse the same service locator. What's the advantage to be a singleton ???
    There is certainly something that i don't understand so help me please!! Thanks.

    Hi Yves,
    But i would like to understand at which side should
    that service locator object reside??!!??
    If it is at client side, each client needs his own
    services locator object
    Conclusion :
    multiple client don't reuse the same service locator.
    What's the advantage to be a singleton ???The service locator resides on the client side and is implemented as
    a singleton. Since it is possible that there could be multiple
    class loaders/JVMs on the client side, and therefore, multiple
    instances of the "singleton" service locator. This is typical
    in a distributed environment (e.g. servlets/JSPs in a web-tier
    cluster using service locator). Thus service locator is not
    a truly "distributed singleton" object. But, the empahsis
    is to design the service locator such that it does not hold
    any state that needs to be replicated across multiple
    instances across different JVMs as mentioned. Thus, there
    is no need for multiple clients to use the "same" service locator,
    but still the benefits of implementing this pattern is realized.
    By making it a singleton, and keeping it from holding state
    that needs to be replicated, we realize the benefits of this pattern.
    You may also want to visit the J2EE Pattern interest list
    and see these relevant discussions :
    Topic: Service Locator and passivation
    http://archives.java.sun.com/cgi-bin/wa?A2=ind0106&L=j2eepatterns-interest&F=&S=&P=1026
    Topic: Caching EJBHome interfaces
    http://archives.java.sun.com/cgi-bin/wa?A2=ind0106&L=j2eepatterns-interest&F=&S=&P=9226
    Topic: Using Service Locator for Data Source caching
    http://archives.java.sun.com/cgi-bin/wa?A1=ind0106&L=j2eepatterns-interest#31
    hope this helps,
    thanks,
    -deepak

  • Design Pattern / Best Practice Question

    Hi,
    I have been using Flex for a while now, but there is a
    scenario which I still have not found a solution I'm entirely happy
    with. I'm wondering if anyone else out there might have suggestions
    on a design pattern or best practice.
    Suppose I have a view which depends on model data which
    resides in some back end systems. That model data may or may not
    have been loaded (e.g. via a web service or remote object call) at
    the time the view is displayed.
    I don't know if the user will ever visit this part of the
    application so I would prefer to defer retrieval of the data until
    the user actually navigates to this view. Or I want to retrieve the
    data each time the view is displayed because the data is dynamic
    and could change between one presentation of the view and the next.
    Because the data comes from several systems, I cannot simply
    make one service call and display the view when it completes and
    all the data is available. I need to call several services which
    could complete in any order but I only want to display my view
    after I know all of them have completed and all of the model data
    is available. Otherwise, I can present the user an incomplete view
    (e.g. some combo boxes are empty until the corresponding service
    call to get the data completes).
    The solution I like best so far is to dispatch a single event
    (I am using Cairngorm) handled by a single command which acts as
    the caller and responder for all of the services. This command then
    remembers which responses it has received and dispatches another
    event to navigate to the view once all the results have returned.
    If the services being called are used in different
    combinations on different screens, this results in proliferation of
    events and commands. An event and command for each service and
    additional events and commands to bundle the services and the
    handling of their responses in the right combinations for each of
    the views.
    Another approach is to have some helper class listen for all
    of the model changes and only display the view when the model
    enters some state that is acceptable. It is sometimes difficult to
    determine just by looking at the model whether it is in the right
    state (e.g. how can I tell that a collection is the new collection
    that should just have been requested versus an old one lingering
    from a previous call). The logic required can get kind of
    convoluted and brittle.
    Basically, all of the solutions I've come up with so far seem
    less than ideal and a little hackish. I keep thinking there is some
    elegant solution out there that I am just missing ... but so far,
    no luck finding it. Thoughts?
    Thanks.
    Bill

    i think a service class is right - to coordinate your calls.
    i would have 1 event per call (so you could listen to individual
    responses if you wanted to).
    then i would use a flag. if you want to check for staleness,
    you would probably want two objects to map your service flag to
    lastRequested and lastCompleted. when you check, check if it's
    completed, and if it's not stale and that your lastRequested is
    less than lastCompleted (meaning that you're not currently waiting,
    i.e. you've returned since making a request). then make the request
    and update your lastRequested.
    here's a snippet of what i mean.
    ./paul
    public static const SVC1_LOADED:int = 1;
    public static const SVC2_LOADED:int = 2;
    public static const SVC3_LOADED:int = 4;
    public static const SVCALL_LOADED:int = 7;
    private var completedFlag:int = 0;
    then each call would have it's own callback.
    private function onSvc1Complete( evt:Event):void {
    completedFlag |= SVC1_LOADED;
    lastCompleted[ SVC1_LOADED ] = getTimer();
    dispatchEvent( new Event("svc1complete") );
    checkDone();
    private function checkDone():void{
    if( completedFlag == SVCALL_LOADED )
    dispatchEvent(new Event( "allLoaded" ));

  • Best architecture and design pattern to use

    I am currently designing a moderately sized LabView application and cannot decide on the best architecture/design pattern or combinations thereof to implement.
    The program basically polls an instrument connected to a serial port continuously at a 2-10Hz rate. When operator clicks a button to start a run, the polled data is then filtered, has math functions performed on the data, writes collected data to files, and produces reltime graphs and calculates point-by-point statistics. At the completion of a run, some additional data files are written. I pretty much know how to accomplish all these tasks.
    What is also required is main-vi front panel interaction by the operator to access a database (via a C# dll with .Net) to query for specifications to apply in order to determine pass/fail status. Setup conditions also need to be changed from time to time by the operator and applied to the data in real time (ie- a measurement offset). I have prototyped the database portion successfully thus far.
    For the main vi, I started off using the Top Level Application Using Events design pattern (Event structure within a while loop). Copious use of bundled clusters and shift registers keep the database data updated. I cannot figure out how to have the top level vi concurrently poll the serial device as outlined above. The Event structure is only active when defined control values change, and use of a timeout is no help since it prevent data from being collected while the user is accessing the database. All database and setup parameters must be applied to the data as it comes in from the serial port. Error trapping/recovery is a must.
    I believe what I need is two parallel processes running under my main vi (one for database and setup, the other for polling and data processing/display, but what would be the preferred choice here?
    Revert back to a polled loop in lieu of Events, use notifiers, occurrences, user-defined events, Producer-consumer loops?
    It�s been about 3 years since I have had an application on this level (which used a state machine architecture), and a lot has changed in LabView (using 7.1 Prof Devel). I am currently having a mental block while trying to digest a lot of features I have never used before.
    Suggestions Welcome!
    Thanks.
    ~~~~~~~~~~~~~~~~~~~~~~~~~~
    "It’s the questions that drive us.”
    ~~~~~~~~~~~~~~~~~~~~~~~~~~

    I suggest a (3) state machine(s) architecture. The first is the user interface. Your main VI is a good start. Another state machine handles the instrument I/O (your serial polling). The third handles all data processing. The three loops run independently. Each has a wait to allow LV's scheduler to share CPU time among the loops. I like queues or functional globals for inter-loop communications.
    This allows a lot of flexibility. Each portion can be tested alone. Each can have different timing and priority.
    Spend some time thinking about what needs to be done and plan the structure carefully before you do any coding (except for little test programs to try new ideas).
    I also like Conway and Watts "A Software Engineering Approach to LabVIEW", published
    by Prentice Hall.
    Lynn

  • Design patterns concern

    i am designing a graph api. i have defined interfaces for a node, arc, and graph. there are multiple interfaces defined (using inheritance) defined for each of these three interfaces.
    all my implementations of these interfaces have not considered fields relevant to display on a x-y coordinate graph. now that i have coded the implementations, i am ready to display these objects.
    the problem is that i have many implementations, but they now have to extend another interface for display. i find that i have to create a new class to implement the existing one and implement the new interface for each implementation.
    to illustrate, i have a Node interface. there are only two methods i.e. String getId() and void setId(String id). i have two additional interfaces that extends this Node interface i.e. SimpleNode and ComplexNode (these have their own pertinent methods, not listed). I have implemented the Node interface with NodeImpl, and implemented the other 2 interfaces with SimpleNodeImpl and ComplexNodeImpl, both of which extends NodeImpl and each implementing SimpleNode and ComplexNode interfaces, respectively. at this point, i define another node interface for the purpose of drawing i.e. DrawableNode (which extends the Node interface and has getters/setters for x and y coordinate.
    my problem is, how do i get SimpleNodeImpl and ComplexNodeImpl to implement the DrawableNode interface? i have considered the following approaches:
    1. have SimpleNodeImpl and ComplexNodeImpl implement DrawableNode as well as what they are already implementing (i.e. SimpleNode and ComplexNode).
    2. extend SimpleNodeImpl and implement DrawableNode interface i.e. DrawableSimpleNodeImpl (and likewise with ComplexNodeImpl).
    3. create an implementation of DrawableNode, DrawableNodeImpl, and use composition to place type Node as a field member.
    i find option #1 problematic because that means i have to define getters/setters for x and y in SimleNodeImpl and ComplexNodeImpl. this would NOT take advantage of inheritance.
    i find option #2 problematic because this would mean i would have to extends all my node implementations just to have them drawable. (i actually have more than 2 extensions of nodes that i want to draw). moreover, i would also run into the problem in option #1, where i have to define getters/setters for x and y in each of these subclasses.
    i am currently leaning towards option #3, but i find the relationship clumsy and even counterintuitive to myself; i plan to use the MVC design pattern, and i have calculated that this approach will result in a web of event/listener complications.
    i am sure there are more options, but these are the ones that i have thought of. the goals are to keep the inheritance simple, implementations to a bare minimum, and have something that will fit nicely in with the MVC design pattern.
    the general question may be: how do i design the relationships so that they will operate in the business logic layer and then be displayable on some GUI layer? is inheritance the way? or is composition the way? or is there yet another way that i have overlooked?

    really long questions dont usually get answered here.

  • JDBC Design Patterns

    Hi All,
    I am new to patterns and have started understanding them using the Head First Series.
    I would like to know what all design patterns are there in JDBC?
    Can i say that JDBC uses a Facade design patterns as it hides the database specific details and provides us a interface which helps us to connect to a database. What other design patterns exist as part of the JDBC?
    Request you to clarify my doubts.
    Many thanks in advance

    I would really appreciate a good discussion on it
    rather than any spoon feeding.
    A typical JDBC code will appear as follows:
    try
    /* Load the jdbc-odbc driver
    Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
    // Open a connection to data source
    con
    =DriverManager.getConnection("jdbc:odbc:DBName","","")
    // Get a statement from the connection
    Statement stmt = conn.createStatement() ;
    // Execute the query
    ResultSet rs = stmt.executeQuery( "select * from
    table_name" ) ;
    1. Is it ok to look into each statement of the above
    code snippet in terms of Design Patterns.it's ok, yes. not necessarily appropriate or worthwhile, though
    2. How can one dissect each line of the code in terms
    of various design patterns?you can't. design patterns exist at a higher level of abstraction than code. 'in terms of' is also disconcertingly vague.
    3. Is it correct to conclude that java.sql package
    overall uses Abstract Factory Pattern.
    As it uses lot of interfaces and implemetation is
    provided by the Vendors. yep. that sounds fair enough. not very useful, though
    4. Consider a particular package like
    java.sql.Statement,java.sql.Blob,java.sql.Connection
    etc. is is correct to conclude that
    its an example of a Factory Method Pattern as any
    client would instantiate. Here the client would be
    Statement object,
    Creator is Connection Interface and createStatement()
    is the factory method.possibly. there's little value in trying to define everything as a "design pattern", though. rather than thinking "oh, they must be using PATTERN X here", think "if I were writing this code, I think PATTERN X would be appropriate". or, more usefully, "is there a pattern that solves this problem?". there isn't, necessarily
    5. I am not able to understand if a statement like
    Class.forName() should be viewed only in terms of a
    programming instruction or
    any design patternit's a line of code, nothing more. stop trying to make everything into a pattern. until you realise where patterns are and aren't applicable, you'll never understand them
    6. Can "stmt.executeQuery()" can be viewed as A
    Strategy Pattern? nope. what makes you think that?
    I would really welcome a good discussion on the above
    questions.does the discussion have to involve design patterns? you know, of course, that design patterns aren't magic beans, right? I know you've just discovered patterns, and are all excited by them, but seriously, they're only ideas, not Infallible Solutions To All Software Problems &#8482;. the most common mistake people make using design patterns is to see them everywhere, and try to bend every problem to fit a particular pattern
    for the record, nobody really views JDBC in terms of patterns. there's little value in viewing existing technologies in those terms, since the most you can "gain" is to have guessed what some other developer did, before.

  • Blog Post on a Worker Pool Design Pattern without VI Server

    Sometimes you think there's nothing left to discover and then someone shows you something you never thought of...
    This was fascinating. Tomi, a frequent poster over at the Lava forums, posted a new blog entry on his ExpressionFlow blog on a Worker Pool design pattern that doesn't use VI Server to spawn the worker threads, but instead uses the new recursion functionality in LV8.6 and specifically 2009! This is truly an interesting premise, because it not only uses recursion, which people have wanted to use natively in LabVIEW for years, but it uses recursion in a way that standard imperative programming languages would not do well, even though they've supported recursion from the start!
    Check it out.
    Jarrod S.
    National Instruments

    I am sorry you feel uncomfortable about the license terms. Being a software company owner I know the difficulty of figuring out the license restrictions of various software components. However that is exactly I provide ExpressionFlow example code with creative commons attribution license. The creative commons licenses do not restrict where the example code can be used and the terms are rather widely known. Shoud example code have no license terms, you would not know how you would be allowed to use or share the code. Now you have it black-on-white.
    Human-readable summary of the Creative Commons Attribution 3.0 Unported license:
    You are free:
    to Share — to copy, distribute and transmit the work
    to Remix — to adapt the work
    Under the following conditions:
    Attribution —
    You
    must attribute the work in the manner specified by the author or
    licensor (but not in any way that suggests that they endorse you or
    your use of the work).
    With the understanding that:
    Waiver
    Any of the above conditions can be waived if you get permission from the copyright holder.
    Other Rights
    In no way are any of the following rights affected by the license:
    Your fair dealing or fair use rights;
    The author's moral rights;
    Rights other persons may have either in the work itself or in how the work is used, such as publicity or privacy rights.
    Notice
    — For any reuse or distribution, you must make clear to others the
    license terms of this work. The best way to do this is with a link to
    this web page.
    Tomi Maila

  • [disc]Design pattern - immutable objects.

    I`m working more often with immutable object because it doesn`t cost as much work to keep object consistent. But sometimes an object has to be build or a reference to his child objects has to be set.
    eg
    class A{
        private ArrayList bList = new ArrayList();  
        public A(){}
        public void addB(B b){
            bList.add(b);
    class B{
        private A a;
        public B(A a){
             this.a = a;
    }It`s now more complicated to make a immutable version of A.
    My question is how this problem could be solved. One solution is to add an immutable flag that could be set to true if the last B is added. But this couldn`t be checked compile time.
    Maybe there is a design pattern for this problem.
    I would like to discuss about this problem, so every thought is welcome.

    I have an Immutable Collection wrapper class that I use when I want to have a Collection be read-only.
    If you look at the JavaDoc for AbstractCollection you'll see that the add and remove methods throw UnsuportedOperationException.
    So all you have to do is implement the iterator() and size() methods. i.e.
    public class ImmutableCollection extends AbstractCollection {     
         private Collection collection;
          * only constructor
         public ImmutableCollection(Collection collection) {
              this.collection = collection;
          * returns the size of the collection
         public int size() {
              return collection.size();
          * returns a non-modifiable iterator over the elements of the collection
         public Iterator iterator() {
              return new Iterator() {
                   Iterator iterator = collection.iterator();
                   public boolean hasNext() {
                        return iterator.hasNext();
                   public Object next() {
                        return iterator.next();
                   public void remove() {
                        throw new UnsupportedOperationException();
    }

  • Is there a design pattern for splitting up files into smaller files?

    I am developing a project where I have to load very large files (upto 50 MB). Currently I am loading these files completely into (consecutive) memory. This has the advantage that I can very easily change bytes at certain locations, because I do not know the
    structure of all bytes.
    However, my intention is to also change the structure, e.g. removing/adding 'chunks'. Now I have the idea to remove the 'known' parts out of it, store them in classes with a data chunk only containing those parts and make a sort of reference list to those chunks.
    E.g.:
    Original file:
    Header
    ChunkA 1
    ChunkA 2
    Intermediate
    ChunkB 1
    Footer
    The result will be:
    ChunkA 1 and ChunkA 2 instance. ChunkB 1 instance
    'File' instance and a reference with base offsets + reference to all chunks.
    At the end I have to 'recreate' or write the original file (with changes) back.
    Is this in general a good idea or is there some design pattern helping me in this?

    50MB is not much in the modern era of 6GB+ machines. If you want to optimize memory then consider using a
    memory mapped file.
    But you mentioned making data structure changes. This is generally dangerous as you have to be concerned about things like disaster recovery. What happens if you are in the middle of saving the modified structure when the program dies? You just corrupted
    your file. A better solution is to stream the existing file using BinaryReader to read in the existing file in parts based upon the structure.  Write out the data to a new, temporary file using BinaryWriter. This may be the original data or your modifications
    depending upon need.  Once you've generated the new file replace the old file (with optional backup). So even if something catastrophic happens during saving you don't lose the original file.
    Michael Taylor
    http://blogs.msmvps.com/p3net

Maybe you are looking for