Just stumbled upon a wonderful way to memorize stuff at memorize.com
Say you want to test yourself or just plain want to memorize Design Patterns for example, just head over here and discover how fun it can be.
Design Patterns
Core JEE Design Patterns
I must admit, this is a really unique way of using a wiki!
*I am in no way affiliated with memorize.com. I just happen to like their stuff
New TripleDES encryption compatibility when using Java and .NET By Patricbensen
Note: This article shows you how to generate a SecretKey to use with a TripleDES encryption cipher. The shared-secret key can be 24 byte or even 16 bytes long.
The most common problem related to encrypting something in Java and decrypting in .NET or vice-versa is a misunderstanding of the Keying options that are defined in the standards and those implemented by Java and .NET
A DES key is made up of 56 bits and 8 parity bits (8 bytes)
A 3DES key is made up of a bunch of 3, 8-byte DES keys i.e. a 24 bytes long
If you are going to use a 24 byte key for both Java and .NET, you're safe; then encryption will be compatible.
Java will force you to use only a 24 byte key when using TripleDES; the subtly is that .NET supports both a 16 byte as well as a 24 byte key.
Now If you generate a key from a MD5 hash of a shared secret, it will be just 16 bytes. .NET has no problem with this. It implements Keying Option 2. It will intelligently take the first 8 bytes and append it after the 16th byte - forming a 24 byte key. Java, *sigh* sadly doesn't do this. You'll have to spoon feed it like so:
public SecretKey getSecretKey(byte[] encryptionKey) {
SecretKey secretKey = null;
if (encryptionKey == null)
return null;
byte[] keyValue = new byte[24]; // final 3DES key
if (encryptionKey.length == 16) {
// Create the third key from the first 8 bytes
System.arraycopy(encryptionKey, 0, keyValue, 0, 16);
System.arraycopy(encryptionKey, 0, keyValue, 16, 8);
} else if (encryptionKey.length != 24) {
throw new IllegalArgumentException("A TripleDES key should be 24 bytes long");
} else {
keyValue = encryptionKey;
}
DESedeKeySpec keySpec;
try {
keySpec = new DESedeKeySpec(keyValue);
SecretKeyFactory keyFactory = SecretKeyFactory.getInstance("DESede");
secretKey = keyFactory.generateSecret(keySpec);
} catch (Exception e) {
throw new RuntimeException("Error in key Generation",e);
}
return secretKey;
}
New Damn Small Linux: Install files with .dsl extension By Patricbensen
The DamnSmallLinux live CD/USB allows you run DSL in memory. It also allows you to run apps that you download from the MyDSL repository. If you install DSL to HDD/USB then you'll want to have these apps permanently on your system. You can do this easily.
If you look carefully, the MyDSL repository, contains a lot of files (apps) with the .dsl extension.
A .dsl extension file is nothing but a compressed archive in the tar-gzip format.
All you need to do is:
If you look carefully, the MyDSL repository, contains a lot of files (apps) with the .dsl extension.
A .dsl extension file is nothing but a compressed archive in the tar-gzip format.
All you need to do is:
- download the .dsl file to any location (lets say /home/dsl)
- cd /
- tar -zxvf /home/dsl/
.dsl
New JPA and Stored Procedures By Patricbensen
I recently stumbled upon many queries on google about how to make Stored Proc calls via JPA. Something was not right with questions like this.
If you have a lot of business logic in stored procs, you have the advantage of speed, security and maintainability, however, you lose portability of your business logic if you change your database. Now, in any large-scale enterprise, the database vendor is not really going to change and a database (oracle/sql server/db2) is going to be a uniform commitment across the organization. Having said that, even if you have to port the procs from one database to another, the vendor documentation will include quite comprehensive migration guides for the same. They have to :) For the record, IMHO, I normally stick with stored procs for the reasons listed above. I always have some real DBA cats working on my team that perform something called ATM (Application Transaction Modelling) on the database. Look it up (ATM). Once they are through with this you can flex your ORM muscles all you like, but in the end what you will be left with will just be UGLY.
Stored Procs and JPA are completely different beasts with completely different philosophies behind them. Sure you can call stored procs using JPA but thats using the wrong hammer. JPA deals with persistence of entities; Stored procs, with business logic being closest to the data.
If you have a lot of business logic in stored procs, you have the advantage of speed, security and maintainability, however, you lose portability of your business logic if you change your database. Now, in any large-scale enterprise, the database vendor is not really going to change and a database (oracle/sql server/db2) is going to be a uniform commitment across the organization. Having said that, even if you have to port the procs from one database to another, the vendor documentation will include quite comprehensive migration guides for the same. They have to :) For the record, IMHO, I normally stick with stored procs for the reasons listed above. I always have some real DBA cats working on my team that perform something called ATM (Application Transaction Modelling) on the database. Look it up (ATM). Once they are through with this you can flex your ORM muscles all you like, but in the end what you will be left with will just be UGLY.
:New HP Laptops with XP - Brightness buttons dont work - Fix By Patricbensen
If you've got a new HP laptop and have formatted it (to probably get rid of the lousy Vista OS)
and installed or downgraded it to XP you'll have noticed something that people all over seem to be annoyed with:
The brightness keys Fn F7 and F8 don't work once the XP OS starts loading into memory.
HP has probably rigged this to work only with Vista. So you're stuck.. right?
Nope :)
Here's the surefire fix:
2. And then hop across to HP and search for something called HP Quick Launch Buttons or do a google search for "HP Quick Launch Buttons "
3. Download it for your laptop model. Install it and reboot.
After this you should have your laptop running XP with the Fn F7 and F8 brightness buttons working!
New BPEL: Get clobbered with the Golden Hammer By Patricbensen
Somewhere in the lobby after an IBM/Oracle seminar showing off their shinny and latest BPEL products
Brainwashed customer: I just met with IBM and Oracle and I'm convinced that I need their BPEL engines since we are going down the SOA road. After all, what am I going to do with my business services?
BPEL Zen Master (to herself): Ah. I see I have to do more penance on this earth by suffering these zombies. Looks like they dont know that SOA is dead
BPEL Zen Master : I agree you need to model and monitor your business processes and also automate some 'processes' that you have. How did they convince you that you need BPEL to do this?
Brainwashed customer: They told me that with BPEL my business activities can be modelled and hence I will have control and I can monitor them and I can tweak them and ....
BPEL Zen Master: Ahem! Have you tried modelling your process in a tool that supports BPMN? Have you tried the same with a tool that does it in BPEL.
You must know that you cannot model your Business Process completely in BPEL as you can do in BPMN.
Contrary to what a vendor might tell you, a business analyst just CANT manage (draw, manage, round-trip) a business process as a BPEL today. Anyway, once you model your processes in the vendors modeller, round-tripping that back is virtually impossible. Besides, BPEL is all very technical...Would your like your Business Analyst to know what a SOAP fault is?
Brainwashed customer: SOAP what?!... Nevermind..But...I can orchestrate my stateless "processes" easily!
BPEL Zen Master: Vendors have been fooling customers into using microflows (an IBM innovation... verbiage-wise) which are nothing but stateless 'programs' that invoke (orchestrate) webservices. You're better off using a mediation module (Take that, IBM.. you can stick your microflows where the sun dont shine). Speaking about Oracle, there's really not much to speak of. After acquiring BEA, they seemed to have dumped their BPEL engine in favor of BEA's. Actually, from a quick look at their conFUSION Middleware stack, they dont know their butt from their heads. Buttheads! For the rest of us, a simple composite business service will do. Not only will you yourself save mucho $$$ by not buying the BPEL engine, but also CPU, storage space, administrator time and most importantly user frustration.
Brainwashed customer: But I will be backed by standards if I go with BPEL, wont I? What about long running processes with human interaction? Is'nt BPEL the best for this? I'm solid with the support on standards aren't I?
BPEL Zen Master: Oh yes! A million of them, non which make sense to any business analyst anyway. And here something to thing about: Any decent business process will probably require some human interation.
Well Long running with Human Interaction... Hmm dont let the BPEL vendors fool you on this one. The moment you get human interaction as part of your BPEL, you'd have to use their extensions to BPEL (which are completely proprietary).
That flushing sound you are now hearing is the standards going down the toilet.
In case your still wondering about which way to go, this should enlighten you
I will reproduce it here for your convenience.
Hermann Schmidt: BPEL is advertized as a high-level process design language. That's a lie. BPEL exposes the designer to lowest-level issues like communication failures, SOAP faults, and XML unmarshalling problems. Drawing a BPEL process naively will not produce any usable artifact. It is a programmers job. Picking up the recent discussion about "BPMN is not software engineering", I think it is fair to say that BPEL is one reason why BPMN still is software engineering. I have seen tutorials from SUN that show how to access rows in a database table with BPEL. What a brilliant idea. Let business people drag their data from databases directly! That about says it all how some vendors treat BPEL. It's just yet another programming language with a fancy graphical interface. "Hey, look what I can do with BPEL! Isn't that neat?". Hello? Service orientation? BPEL has no modularity. BPEL has no concept of reusable patterns or code fragments (besides functional decomposition into yet more processes - did someone say high-level?). Reusing patterns in BPEL means cut&paste of sourcecode. No signs of object orientation anywhere. It is a low-level web-service caller with a functional decomposition design model and a little event dispatching with parallel execution. Oh, and you can shuffle data around in XML-based structures. The ubiquitous GUIs give the illusion of a high abstraction. Ironically, they are necessary because BPEL code is a pain to write as text. The graphics are merely the syntactical representation of a very basic programming language. Vendors pimp up BPEL engines with additional features to alleviate weaknesses of the language. This may even result in practically usable products, if done well. However, that makes BPEL non-portable in all but trivial cases and renders the whole standard useless. I am deeply frustrated by the level of intelligence in this standard. I believe that it will not take the software industry any closer to more efficiency or excellence. I don't need it. It doesn't get the job done. |
Brainwashed customer: Master, that was enlightening. During my meditation my mind drifted to a scene from the movie 'The Matrix' and then... then it hit me