Will Hartung

Greenhorn
+ Follow
since Nov 19, 2008
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Will Hartung

Mark Masse wrote:
I also want a forum to debunk the idea that WRML is "like SOAP". As a colleague of mine said, "that's silly - your book is way to small for WRML to be about SOAP!". I certainly understand that WRML may look a bit foreign at first - but I think that it is new and it might have some value to anyone wanting to easily develop web apps without writing a bunch of rote, boilerplate code.



I've looked over the wrml.org site, and the slide decks you've posted, etc. I didn't study them in particular detail, but all I saw was some references to some workflows and tools and frameworks.

I haven't seen any examples of anything looking like a modeling language.

There's mention of schemas and formats, but those aren't in regards to WRML itself.

There's the application/wrml media-type, but that appears to not be a media-type (at least as generally understood), but rather a mechanism to link the schemas and formats together.

The RFC draft on the website is "working on it, come back later" message.

So, do you have some examples of the WRML, or other documentation, besides the book that we can see?

8 years ago

David Newton wrote:I don't see any relation at all; could you elaborate on how they're similar? Thanks!



Perhaps in the sense that the rules and actions are "around" the events, versus the actual events themselves. You have various observers keyed to the lifecycle of the event and execute logic upon those, rather than necessarily specifically on the event.

The events are "ignorant" of the logic, the processing system is firing logic as the events go by.

In a similar manner, but perhaps reversed manner, in AOP the logic is ignorant of the aspects. AOP is all about instrumenting the runtime to get your aspect logic injected in to the function call flow of the application, much like event processing is based on the event flow.

Perhaps it's a reach, but in the right light, you can perhaps see how they're similar.
9 years ago
On the one hand, the EJB Timer service won't gain you much more than simply having the Quartz callback methods calling a Session Bean method to do the work you need, since effectively that's all that the Timer service is doing.

In both cases there can be security/role issues (since the Timer service doesn't "log in" as anybody, you don't know "who" is making the EJB calls, well you do, it's Anonymous, but that's not helpful if Frank scheduled the job), if that's an issue for you.

JEE 6 timers are much better than JEE 5 timers, but most of that capability is available only from code (vs, say, the servers admin console, though some server may offer this facility, I don't know any that do. Services like "how many jobs are pending in the timer service" from the console.)

For example, in JEE 6 you can annotate a bean to "run every 5 minutes" or "every friday" etc.

That's all well and good, but if you wish to change that schedule, you get to rebuild/redeploy your application.

The other aspect to consider is that, by default, JEE timers are persistent. In JEE 6, this is now optional, it's default, but you can change it, however it was not optional in JEE 5.

By persistent that means that if you create a Timer that runs every 5 minutes, and restart the server, then when the server restarts the Timer will remain and execute again. Very likely it will execute immediately if the 5 minute window has passed, as Timers execute when the current time has passed their scheduled start time.

This is all well and good.

Where it become frustrating is two fold.

First, if you create a Timer for some future date (say, "run this next Wednesday"), then that Timer will fire next Wednesday, even if the server restarts.

However, the Timer is persistent to the APPLICATION, not the SERVER. If the server restarts you're good. If you redeploy the application, the timer Goes Away. Since the application is removed form the server (for redeployment), all of its Timers go with it.

That means your Wednesday job needs to be rescheduled.

If you were naive, every time the application started, you would create a Timer job that "runs on Wednesday". But if you simply rebooted the server, you'd end up with TWO jobs that run on Wed. So, you need to scan the current timer list to see if your job is already queued up. If "hard coding" the schedule in your bean is sufficient, that handles this problem nicely.

The other issue is that the container will start all (ALL) expired Timers as soon as the container has restarted. The problem here first is the potential "Timer storm". Say you have 5 jobs that are schedule to run in 1, 2, 3, 4 and 5 minutes. You have some issue with the system and it's down for 10 minutes before its restarted. When it's restarted, all 5 jobs will begin automatically, and simultaneously. Your container may have some way to throttle how may Timers can run at the same time.

But the other issue is that the lifecycle of Timers were, in JEE 5, undefined. In JEE 5, there was really no place to "hook in" when the application started up. Many folks hook in to a ServletContextListener to let them know when an application is starting up. This mostly works, but the nut is that the EJB tier pretty much has to be already running before the Servlet tier fires up (since the Servlet tier will very likely be calling the EJB tier). So, by the time the ServletContextListener.contextInitialized method was called, any expired Timer sessions may well be off and away and running.

This is important in case your application start up need to initialize anything the Timer job may need to run, like some caches or other services.

JEE 6 MAY address this, indirectly, with the Singleton Session Bean. You can add @Startup to a Singleton Session Bean and it's guaranteed to be called before any EXTERNAL client requests are made. External as in external to the application. Are Timers external calls? *shrug* I dunno.

So, these are some "gotchas" regarding EJB timers that you should be aware of.

If it were me, I'd manage all of the timers in my application, and mark them as non-persistent in EJB. That simplifies a lot of issues. Also, since methods can be Asynchronous, that relieves some of the processing issues with Timers (as they were the only "approved" way to run background processes in the EJB tier in JEE 5 since you shouldn't spawn threads).

We manage all of our timers in our app. On startup we lock down our Timer jobs, and then purge the EJB Timer service and reapply the timers from our DB. Our Timer jobs can't run until we've triggered that the system has started up to OUR satisfaction, and they just block waiting for that, and then quietly exit hoping they're rescheduled.

But we're on JEE 5, so we have to do that. JEE 6 would simplify my code a little, but likely not that much.
Hi all.

This sounds like an interesting book.

We've dabbled with event processing (formally and informally) in the past.

One of the benefits of event processing is more in being aware of how much can be thrown away.

At a basic level, especially with modern systems, with all of the auditing and monitoring traffic, there is an enormous amount of POTENTIAL data being pushed around. But, 99% of the time, that data is ignored yet still stored. It's almost always used for post-mortems after something had gone awry.

Many times systems may well display, or make available, that data in real time, for example for presentation on running graphs monitoring activity. Very pretty graphs, but when the data scrolls off, it will likely never be seen again, save for post-mortem review.

A potential advantage of event processing is that the system can be informed as to what data is interesting at a specific time. The system can look at what rules are in place, what events are actually "interesting", and forego processing for those that are not interesting.

This concept make event processing interesting because a rule can make its decision based on the current event, plus any retained state.

A simple example is say that you're interested when a customer makes more than 10 orders in a 30 day period.

One way of implementing that rule is every time an order come in, you can do "SELECT COUNT(*) FROM ORDERS WHERE ORDER_DATE >= NOW() - 30", or some such thing, and compare the result to your threshold (10 in this case).

But, that can get expensive. Doing potentially large aggregate queries with a large order volume, can be expensive.

Another technique, however, is that the rule itself knows what it is interested in, and thus keeps track of if its own state. The rule can track a customers recent orders, or simply a date and a count. When a new order comes in, the rule adds 1 to the numbers of orders for the order date, and then sums up the last 30 days of orders to compare against the target. Even more important, though, is that when 31 days have gone by, the older data is simply removed from the system, as the rule doesn't care about it any more.

So, the rule is tracking a moving window on the data, and its tracking only a subset of the total data (orders per date in this example, rather than entire orders).

You can see that in a fast moving system, like in a system monitoring application, how you can have short temporal windows (requests/minute say), managed locally in memory, with the rule system creating individual buckets on the fly (for example, when it sees a customer it has not seen before, it can create a holder for the rule state data specific to the customer criteria).

The dark side is that if you rule engine goes down, all of this data is lost. If all of your rules are for short time spans (i.e. 5 minutes), then it's likely not that important -- in 5 minutes you'll be caught up.

But if you're tracking data over larger time spans, say 30 days, then that's much more a problem.

It can be mitigated by replaying event data, perhaps with a flag to disable firing of events that have, in theory, already been fired. But that can certainly add to the start up time of the event application.

So, the problem is really more of an issue with persisting rule state. What little I've seen in this field, it seems that persisting the rule state wasn't common.

Does the book address this issue? I would think this would be a fairly common issue, particularly if you want to support failover for the event processor, etc. Perhaps the more commercial systems support this, I have not seen those.

I've skimmed through the sample Chapter 10, which seems perhaps most relevant to this (you mention Recoverability, which is probably what I'm primarily discussing here), but it seems pretty high level.

9 years ago
Pat, it comes down to this.

If you've been writing code for ages, and you've ever said "There has to be a better way to do this", and you haven't made your own "better way", then you might want to look at a framework using your use case.

If you have been doing similar work using the core Servlets platform for any length of time, you have most likely managed to develop "your own framework". Perhaps it is better than the devils you don't know out there in the world of frameworks, in terms of elegance, etc. Perhaps it's worse, but it's "good enough", and the intimate knowledge you (and ideally your team) have of your internal library of utilities more than compensates for anything that a new framework may offer simply in terms of risk and speed of development for you and your team.

Simply put, the reason to not use a third party framework is 'You don't know it, don't have time to learn it, and can't risk falling in to a black hole of uncertainty because of it".

No framework can address that. If that's the concern, then you should sign off with "Thanks for the conversation" and go on your merry way. No harm, no foul.

All we can say is that in our experience, and some us have pretty good experience in this domain, for some time, we have found that the frameworks (in our case, Stripes) have been a Net Win overall. And I've been bitten by black holes, unknown surprises, etc. But none of them have convinced me that the choice was wrong. Rather, we simply fixed the issue and moved on.

As I've said before, I think anyone new to the Java Servlet platform should write a non-trivial application in pure JSP and Servlets. Pure JSP and Servlets can go quite far with even the most minor amount of tweaking (like pounding out a quick Front Controller so you don't have to use raw Servlets everytime -- hardly rocket surgery).

But it seems to me that after you've endured that experience, you should have enough experience to make a sound decision to use one of the several dominant frameworks available. The time spent on that research and adoption will be minor, long term, to carving that wheel out of stone again.

In your case, you may well have already solved the problem. You've already got util functions, idioms, and tooling to make writing an application easier than using raw servlets. I can't advocate that anyone switch out a mature, working infrastructure for "something new". That's crazy.

That said, tho, I think that it would still be worthwhile for you, if you have time, to explore some of these frameworks. If nothing else, you may learn something that you may well want to apply and incorporate in to your current code base.

JPA is a classic example of that. JPA/Hibernate/ORMs in general have swept the Java world by storm, and for good reason. They're really nice, and they really work. They have problems, they're imperfect, and they introduce a large layer of "dark matter" in to your system that only hands on experience can decipher. But, in the end, for us, JPA has been a net win, and it's hard to imagine doing persistence any other way unless absolutely necessary. In the end, it's another tool in the tool box, but it's also the first tool we reach for today.

We're constantly looking at the new things available and try to take advantage of opportunities to try them out in anger on a real project. We take advantage of our long experience in knowing what we already know, and being comfortable that as we move down the path trying something new, we always have a backup plan should something go awry. With reasonable modularity, layering and testing practices, yanking out a new technology to replace it when it "goes bad" with an old technology is rarely a big issue. If it was a big issue, we wouldn't have done it at all to begin with.

Sounds to me you're happy with your code and your practices. If you have time, look at some new stuff if for no other reason than to get an alternate point of view of the problem, otherwise, no big deal.

I use Stripes on my own projects, and at work. I use, probably, 20% of the platform. I'm a big fan of its binding model, that's the Silver Bullet for me as it eliminates so much boiler plate garbage from my code. The other Stripes guys use far far more of the framework than I do. I'm the luddite of the Stripes community.

That said, I find it invaluable. I can't really fathom writing a system that responds to HTTP requests using anything else. To anyone reading this thread, if you need to respond to an HTTP request (whether that response is a forward, redirect, or streaming PDF, XML, or JSON), there isn't anything better, faster or easier than Stripes for the 95% use case. It's painless to use, and painless to incorporate, and Solves The Problem elegantly and efficiently.

If you like the Servlet model of web development, Stripes is the best evolution of that model available.
For many, frameworks are a solution to a problem.

If you don't have that problem, a framework may not help you.

But the detail is that you may be doing something and not consider it a problem, yet if you had used a framework that made that thing simpler, when you went back to try the task without the framework, you find it more tedious, or error prone, or whatever. Now you look at that task and see "it's a problem".

For example, the classic argument against Garbage Collection. "Why would I ever need garbage collection, I've mastered malloc/free/sbrk/etc., etc.". And then you code with GC and "see the light".

For me, specifically regarding a web application, I went bumbling around looking at some, notably Struts, but decided that after seeing the pain in setting it up, that I didn't really understand "the problem" is was trying to solve. So, I wrote my first app in pure Servlets/JSP.

It basically worked, as you'd expect. But I wasn't happy with it.

When I had to do another application, I decided to try again, and again I went with Struts (had a book and everything). And it was allright until I reached a particular sticking point. In this case, it was dealing with indexed property binding.

Struts failed at that point completely. Effectively, I could use Struts and its mechanics for some chunk of my app, but for this area, Struts simply didn't exist -- it offered NO value.

See, at this point I knew what I wanted to do. I knew I could code it up if I wanted to, but I also knew that someone, somewhere, had solved this particular problem. I just had to find it.

This is a particularly black hole to be in, because as you're flailing around the net try to find the magic bullet, you're burning time -- time which could have been used to "just code it".

But on the other side of the coin, from my Servlet experience, I knew that doing it "from scratch" just wasn't what I wanted to do. Nothing draws a crowd like a crowd, and the Web App Framework "market" was crowded.

People weren't making these things to waste time, but to solve the mundane issues that you encounter when doing web applications. Servlets are functional and usable, but the frameworks were solving real issues, not just being make work projects by folks with nothing better to do.

So, the game was to find the right framework for me. Obviously, in my case, at the time, Struts wasn't it.

My wife rejoices the day I finally stumbled on to Stripes, because I was in a sour and surly mood for a week beating my head against the wall trying all these frameworks.

For my case, the Stripes Framework offers 2 major advantages over stock Servlets for Web App development.

1) Stripes Action Beans are thread safe. Each request gets its own Action Bean compared to a stock Servlet, which is shared across requests.
2) Stripes binding. The Stripes binding model is the best I've seen. It's simply fabulous. I can't imagine doing a Web App of any magnitude without something like the Stripes binding and data conversion features.

It's got other things, but those are the "Killer Apps" of Stripes.

The first one is easy enough to roll your own, and many do. But it's still a great feature. Struts 1, for example, followed the original Servlet model of one Action per server -- which is just crazy to work with, frankly.

The second, tho, the binding, is just a plain ol lot of work to do, and I'm glad I'm not the one who did it.

For a web app framework, those are the two things the Stripes brings to the table for me. You may have different pain points and some other framework (or none at all) may suit you.

It's impossible to rate a framework in a vacuum. You need to have a problem you're solving, otherwise you can't judge whether the framework is actually a benefit for you, or simply another way of doing the same thing. At the same time, your use case needs to be complicated enough to really stress the framework. Otherwise you may just get a one trick pony.

That may be all you need, but it's nice to have something reasonably robust that solves a lot of the common issues.

Note, I know it's "pimp Stripes week", but the guidelines apply to any framework. The 3 "hot spaces" on the server for frameworks are the Web/Presentation space, the Logic/Transaction space (Spring, JEE, etc.), and ORMs and other tools for databases (JPA, Hibernate, iBatis).

I threw out Struts for my task because it offered me nothing, and Stripes was able to pick up the ball. Stripes does a LOT of stuff that I DON'T use, but for the stuff I do, I'm grateful that it exists.
My opinion is basically that Component Frameworks are an intermediate step that will eventually cede to "pure Ajax". The point of the component frameworks is to shoe horn the square peg that is the component/event model into the stateless transaction oriented round hole of HTTP.

The issues with server side state are legion when it comes to scalability and complexity, and the component models go to great length to hide those concerns from the developer, but that doesn't mean the concerns don't exist. The complexity is there, but it's like sharks circling below the water -- unobtrusive and ignored until one of them rises up and bites off your leg, then you look under the waves and go "OMG! It's filled with sharks!".

"We're going to need a bigger boat."

And that boat is the modern, powerful "thick client" Javacript browser.

So, over time as the browsers race each other and the older ones drop off the face of the planet, the component frameworks will go the wayside as the browsers take over their role.

Mind, this is specifically in reference to mostly back office applications with really complicated user interfaces, etc. Not "web sites", that is those sites dedicated to content distribution.

So, what happens when you get a rich client is that the server basically becomes a pure service host, and web clients prefer that "REST" style of communication. Here, any action framework will handily do the job, and Stripes is well suited to being a good backend for these kind of systems with its new URL support, JSON support, etc.

As you say here, what exactly the term non-full-stack means here? I don't quite get that.



Some frameworks provide not just the web side of the application problem, but also the persistence side. Seam is a "full stack" framework tidying up and tying up everything from JSF to JPA to Session Beans. Stripes simply handles the HTTP layer.

Again when you say near-to-zero configuration, how exactly Stripes manages the configurable properties,values? If I am right, it should atleast have one configuration file of its own as a minimum requirement.



What little configuration there is for Stripes is contained within the web.xml file.

When you say, Stripes is more-or-less a replacement of Struts (may not be exactly 100% right), does it provide an abstraction over Struts?



Stripes and Struts "are the same thing". Struts 1 and Stripes while conceptually similiar (i.e. an Action framework) are quite different in terms of actual execution and use. Struts 2 and Stripes are more the same than different.

Does Stripes have its own customized syntax? To what extent an application developed at present can be easily migrated to an xyz framework in future? I mean to ask about the tight bound nature and dependency of Stripes!



The tightest binding in Stripes is through the use of the Stripes Tag Library and JSP. But, in truth, those are completely optional. While integral to some of the "ease of use" aspects of Stripes, Stripes without the Tag library is still really powerful and very useful.

You're not required to use JSP or the tag libraries, but they are certainly useful and most folks do use them.

# As a successor of Struts, for sure Stripes should follow the MVC pattern. Is there any other design pattern Stripes follows which is worth mentioning for its so called ease of use?



Stripes also implements the "Stay out of my way" pattern, the "Do what I mean" pattern, "My, this certainly is easy" pattern and the "Where have you been all my life" pattern.

I've found those compelling in my use of Stripes.
Just to clarify, Stripes I think is a great start for the beginner, and you don't need to "know Struts" first.

You should have some basic JSP/Servlet and HTTP knowledge though to get the most out Stripes.

I think anyone learning web programming in Java should start with a simple JSP/Servlet application to understand the work flows and development process. Also, it helps to understand what the hub-bub is about and why you'd want something like Stripes in the first place.
Any framework will let you "do anything", it's just a matter of how easily.

Early on, Stripes was one of the few frameworks that did indexed binding really well (for example, in Struts 1 you had to pre-allocate the size of the array you were bind to, where Stripes created and expands it on the fly).

Stripes major values are:

a) simplicity -- 99% of your problems are in your actual HTTP requests, and those are 99% of the time simple urls or forms.
b) "doing the right thing". Stripes surprises me more by simply "working" the way it should, it really does get out of the way
c) incremental complexity. You can go very far with more base Stripes knowledge. Yet as you run in to hurdle where you need more advanced use of the framework, not only is there a mechanism already in place, you find you don't have to learn the entirety of the rest of the implementation to use it. There's no huge wall you all of sudden have to cross to do that "just one more thing".

They done a very good job of exposing the guts of the system to the user in fine piece, and most every aspect of it is "patchable" without having to hack the actual Stripes code.
Many folks have also incrementally migrated from Struts to Stripes, as they don't really stomp on each other. So you can try and test it out if you like and not worry about having to redo the entire site all at once.
Opposites would be the component frameworks (JSF, Wicket, etc.).

Stripes is an Action framework for dealing with HTTP requests, the component frameworks tend to take over the HTTP request and hide it from the developer in order to manage all of the complicated state that they need to get that component "look and feel".
This specific feature of Stripes binding can not be underestimated.

There is a lot of power in being able to do something like this:



Assuming these simple beans:


When this form is submitted, Stripes will:
a) Create a list (an ArrayList)
b) create the Map (a HashMap)
c) create an empty MyData
d) bind the name to the MyData name field
e) convert the age to an Integer and bind it to the MyData age field
f) convert the date to a Data and bind it to the MyData date field
g) put the MyData in the the Map using the "theKey" key
f) put the Map in to the 10th slot of the ArrayList

If any of those bindings fail, it will redisplay the form, WITH the bad values, and flag the offending fields.

You get all of that "for free", out of the box.

This makes developing things like forms with dynamic fields VERY easy to do, yet still leverage the binding and validation capabilities of Stripes.

When it comes to dynamic forms, a lot of frameworks make you toss out much of their functionality and rewrite it from scratch because they only work well with static fields.

The dynamism of Stripes binding is very powerful.