If you've never installed a LDAP server don't worry, its very easy. I like to install via source instead of grabbing packages from repos. You can find the directions for getting started here.
Just so you know, the rootdn (owner the root user for LDAP) can be named anything, in fact I suggest you use something other than cn=Manager, since a lot of people look for that in new LDAP installs.
Also please read up on the Access Control chapter before you go off leaving your LDAP server running for any length of time. Understanding the ACL of LDAP is a little tricky at first so go over it a couple of times just to make sure you have it. It should be understood that most users will need to connect to your server to get login information. Crazy enough, LDAP supports a type of permission called "auth". This allows an unknown client to query the LDAP server but only receive a connection or nothing from the server. This way a client can transmit a query with user name and password and hope that a connection is returned.
If the idea of having unknown people query your LDAP server bugs you, you can always setup a Kerberos server to handle the authentication of users, I'll get to that when I cover SASL. If fact, in some contract jobs with the government, you are legally required to have an external authentication service.
Well I'll fire up VirtualBox and begin doing some LDIF entries into LDAP and then some python code.
Thursday, October 29, 2009
What is LDAP and Friends
LDAP stands for the Lightweight Directory Access Protocol, you can read more about it here.
Barring that, I'll give you a really quick run down of the history and uses of LDAP. LDAP is the Internet version of the X.500 Directory Access Protocol (DAP). In the beginning there was DAP, and no one used it (except maybe a couple of companies and the government, oh and Outlook as well.) DAP used the full OSI protocol stack which, in short, is seven layers thick. The Internet runs on a slightly lower calorie protocol, weighing in at four layers. Now one can transition between the two quite easily.
(NOTE: When people hear OSI they think OSI Model, there are also a ton of ITU-T papers that actually define a real set of protocols, you can check them out here.)
So at any rate, X.500 defined this whole suite of protocols that allowed globally unique messaging and directory services (basically the precursor to email and a global phone book for all those email accounts.) Needless to say this was a pretty lofty goal. Moving on, some companies actually implemented OSI and started using X.400 (mail) and X.500 (directory) for company mail. Then along came the Internet and suddenly DAP and all related technology found itself isolated. Enter LDAP, whereas DAP was made to use a seven layer protocol, LDAP was made to use TCP/IP. This includes IPv4 and IPv6 and TCP and UDP variations. It is important to note that LDAP runs only on TCP/IP, so if you are using an IPX/SPX network then you will be using something like NDS (Novell eDirectory) which is a X.500 implementation on IPX/SPX (NOTE: NDS doesn't do everything X.500 does, but neither does LDAP).
Since LDAP was made to use the protocol of the Internet, and the Internet has become so wildly popular, LDAP has become a very popular replacement for X.500 installations. The rest of the history of LDAP isn't all that fascinating so I'll leave at that.
So what is LDAP used for? Well it can be used as a limited gateway to X.500 directories (and for a lot of large companies that is exactly what it is used for) but also it can be it's own trimmed down X.500 directory. Trimmed down because LDAP doesn't implement the parts of X.500 that rely on the OSI protocol. So what is this directory? Well it is basically a database that houses user information. Usually the LDAP database is optimized for many reads and few writes and usually doesn't implement things in a relational manner like an RDBMS. Instead, LDAP is tree like and the database is optimized to think that way as well. LDAP is also good at storing user information that can be used on the application side. A RDBMS usually has data types that you store into it, an LDAP has a schema that is more role based as opposed to data based.
As an example, an RDBMS would have a user name and password field for user logins. LDAP would have a user schema that stores user name and password. Not much difference really but the schema is mostly role based, as you can imagine you can find a role that fits your needs from the IANA and add that to your LDAP server to fulfill that role. It makes a lot of sense when you get more complicated examples like a FedEx Account Contact role versus (FULLNAME, ADDRESS1, CITY, STATE, ZIP, ACCOUNT, ...) like you would find in a RDBMS.
Also, LDAP is tree like in nature. To implement the same ability in a RDBMS you need at least two tables, one to hold the normalized data and the other to add the structure you need. So you may have a list of contacts: in a LDAP directory each branch may separate that contacts role in your company; in a RDBMS you would need another table describing the roles and who belongs to them. I know it's not a big difference but it makes all the world of difference when you try to make optimizations and LDAP generally requires less administration and complex layouts.
So what role does LDAP play in the real world? Usually it stores user information, logins, contacts, and so on. Basically the same kind of information you might find in a phone book sans the whole computer aspect of it. This is really important in the real world as it allows people to centralize user information. Allowing only a few trusted sources to edit the data and allow the rest of the users to use it while conducting business. Think of it as a company wide Roladex. Because it stores contact information it can also store login information (basically a list of contacts that work for the company). The LDAP server can tell the difference between the role of "Standard-Contact" and "Employee-Contact". The standard contact might just have the regular information you'd expect, but the Employee contact may have everything a standard contact has and also have a password and username field within it.
I hope this gives you a better idea of how LDAP works in the real world. LDAP stores user information and anything that you might be interested in storing for that user (notes, bookmarks, appointments, etc...) It's not a replacement for a RDBMS, but it is a good solution for the purpose it was written for. If you find yourself building an application that doesn't need RDBMS but needs millions of reads and very few writes, LDAP would be a good solution for you.
Barring that, I'll give you a really quick run down of the history and uses of LDAP. LDAP is the Internet version of the X.500 Directory Access Protocol (DAP). In the beginning there was DAP, and no one used it (except maybe a couple of companies and the government, oh and Outlook as well.) DAP used the full OSI protocol stack which, in short, is seven layers thick. The Internet runs on a slightly lower calorie protocol, weighing in at four layers. Now one can transition between the two quite easily.
(NOTE: When people hear OSI they think OSI Model, there are also a ton of ITU-T papers that actually define a real set of protocols, you can check them out here.)
So at any rate, X.500 defined this whole suite of protocols that allowed globally unique messaging and directory services (basically the precursor to email and a global phone book for all those email accounts.) Needless to say this was a pretty lofty goal. Moving on, some companies actually implemented OSI and started using X.400 (mail) and X.500 (directory) for company mail. Then along came the Internet and suddenly DAP and all related technology found itself isolated. Enter LDAP, whereas DAP was made to use a seven layer protocol, LDAP was made to use TCP/IP. This includes IPv4 and IPv6 and TCP and UDP variations. It is important to note that LDAP runs only on TCP/IP, so if you are using an IPX/SPX network then you will be using something like NDS (Novell eDirectory) which is a X.500 implementation on IPX/SPX (NOTE: NDS doesn't do everything X.500 does, but neither does LDAP).
Since LDAP was made to use the protocol of the Internet, and the Internet has become so wildly popular, LDAP has become a very popular replacement for X.500 installations. The rest of the history of LDAP isn't all that fascinating so I'll leave at that.
So what is LDAP used for? Well it can be used as a limited gateway to X.500 directories (and for a lot of large companies that is exactly what it is used for) but also it can be it's own trimmed down X.500 directory. Trimmed down because LDAP doesn't implement the parts of X.500 that rely on the OSI protocol. So what is this directory? Well it is basically a database that houses user information. Usually the LDAP database is optimized for many reads and few writes and usually doesn't implement things in a relational manner like an RDBMS. Instead, LDAP is tree like and the database is optimized to think that way as well. LDAP is also good at storing user information that can be used on the application side. A RDBMS usually has data types that you store into it, an LDAP has a schema that is more role based as opposed to data based.
As an example, an RDBMS would have a user name and password field for user logins. LDAP would have a user schema that stores user name and password. Not much difference really but the schema is mostly role based, as you can imagine you can find a role that fits your needs from the IANA and add that to your LDAP server to fulfill that role. It makes a lot of sense when you get more complicated examples like a FedEx Account Contact role versus (FULLNAME, ADDRESS1, CITY, STATE, ZIP, ACCOUNT, ...) like you would find in a RDBMS.
Also, LDAP is tree like in nature. To implement the same ability in a RDBMS you need at least two tables, one to hold the normalized data and the other to add the structure you need. So you may have a list of contacts: in a LDAP directory each branch may separate that contacts role in your company; in a RDBMS you would need another table describing the roles and who belongs to them. I know it's not a big difference but it makes all the world of difference when you try to make optimizations and LDAP generally requires less administration and complex layouts.
So what role does LDAP play in the real world? Usually it stores user information, logins, contacts, and so on. Basically the same kind of information you might find in a phone book sans the whole computer aspect of it. This is really important in the real world as it allows people to centralize user information. Allowing only a few trusted sources to edit the data and allow the rest of the users to use it while conducting business. Think of it as a company wide Roladex. Because it stores contact information it can also store login information (basically a list of contacts that work for the company). The LDAP server can tell the difference between the role of "Standard-Contact" and "Employee-Contact". The standard contact might just have the regular information you'd expect, but the Employee contact may have everything a standard contact has and also have a password and username field within it.
I hope this gives you a better idea of how LDAP works in the real world. LDAP stores user information and anything that you might be interested in storing for that user (notes, bookmarks, appointments, etc...) It's not a replacement for a RDBMS, but it is a good solution for the purpose it was written for. If you find yourself building an application that doesn't need RDBMS but needs millions of reads and very few writes, LDAP would be a good solution for you.
Wednesday, October 28, 2009
LDAP and Python
I have no idea why I am so attracted to LDAP. At any rate, I'll be over the next couple of weeks posting some LDAP python work that I'm doing. Here is the python library that I'll be (and most people) using. I figure it was time that someone made Yet Another LDAP GUI Tool (YALGT).
Nah I take that back, that sounds way too much like YAST from Novell.
Nah I take that back, that sounds way too much like YAST from Novell.
ScribeFire
I love the web proxy at my company. Basically it is useless. At any rate, since I can not use the web interface on Blogger, I've started using ScribeFire at work to publish post. Right now my views about it are mixed. I just have a funny feeling about it because it has the little logo in the top right corner.
Why is that a big deal?! Well ever since we left the era of Netscape Navigator, I haven't seen the logo in the top right corner in some time, except for adware. Therein lays the point. The add-on reminds me of adware. So I'm a little cautious about it.
Also the <br /> in ScribeFire acts weird and sometimes it tries to add a <div> that adds a invisible tracking pixel to my blog. (Which reminds me I've got to go through and make sure I removed them all).
Why is that a big deal?! Well ever since we left the era of Netscape Navigator, I haven't seen the logo in the top right corner in some time, except for adware. Therein lays the point. The add-on reminds me of adware. So I'm a little cautious about it.
Also the <br /> in ScribeFire acts weird and sometimes it tries to add a <div> that adds a invisible tracking pixel to my blog. (Which reminds me I've got to go through and make sure I removed them all).
Anyone know this person?
Don't know anyone per se in Canada, but it is at least worthwhile to re-post this. Please help find this person's family
Pitfalls of AS400 and MS Access
Where I work we have an AS400 system that provides our DB. However, our IT admins decided to use a rather uncommon naming scheme. Our Libraries "folders if your looking for a Windows equal" have a period in their name.
Well you may, or may not, know that the period is how the AS400 system tells the difference between a library and a member when using the *SQL naming scheme. So usually you have something like this:
Then you have the FNTUSR library and the ACCNUMB member of that library. But if you have something like this:
You basically have garbage, at least as far as ODBC goes. The problem actually lies within the ODBC driver that IBM includes. It doesn't follow the same resolution method as the actual AS400 system, maybe because it is local and ODBC is remote but details aren't really that important. The ODBC driver goes out and yanks the CHK member during the resolution and asks for the BILLNO member, skipping completely the ENTR part of the name.
Needless to say this may prevent you from using ODBC to connect to the AS400 system. If there was only a way to pass the name as one chuck so that the ODBC driver would stop parsing the second period and placing the resulting token in the garbage.
Oh wait, there is...
The wonderful world of Microsoft allows you to pass a chuck of information into the ODBC parser, bypassing the tokenizer, by surrounding it with quotes! Hooray! But wait! In addition to the wonderful-ness that is Microsoft. None of their GUI offerings allow you to give quotes (except Excel, go figure). So if you are wanting to connect to an AS400 system that is administer by half witted admins that place extra periods all over the place in an AS400 system (look *SYS != *SQL, you can not use *SYS when you are brainwashed into thinking that it is the same as *SQL). You will need to go the VBA route (hooray... please shoot me now).
For those of you not really familiar with the VBA way of doing things, it involves a lot of pain. Please observe (I've named the DSN as400_connect):
That should get you started on getting crap out of the AS400 system and into your MS Access database. Notice that I am using the *SYS naming scheme. Try both the *SYS and *SQL naming scheme (library/member, library.member) to see which one your AS400 system is using (or at least will resolve). You can change that bit of information in the DSN entry on your system under ODBC Administration in Windows.
PS: Please make sure you have the damn ODBC driver from IBM before you even try setting up the DSN.
Well you may, or may not, know that the period is how the AS400 system tells the difference between a library and a member when using the *SQL naming scheme. So usually you have something like this:
FNTUSR.ACCNUMB
Then you have the FNTUSR library and the ACCNUMB member of that library. But if you have something like this:
CHK.ENTR.BILLNO
You basically have garbage, at least as far as ODBC goes. The problem actually lies within the ODBC driver that IBM includes. It doesn't follow the same resolution method as the actual AS400 system, maybe because it is local and ODBC is remote but details aren't really that important. The ODBC driver goes out and yanks the CHK member during the resolution and asks for the BILLNO member, skipping completely the ENTR part of the name.
Needless to say this may prevent you from using ODBC to connect to the AS400 system. If there was only a way to pass the name as one chuck so that the ODBC driver would stop parsing the second period and placing the resulting token in the garbage.
Oh wait, there is...
The wonderful world of Microsoft allows you to pass a chuck of information into the ODBC parser, bypassing the tokenizer, by surrounding it with quotes! Hooray! But wait! In addition to the wonderful-ness that is Microsoft. None of their GUI offerings allow you to give quotes (except Excel, go figure). So if you are wanting to connect to an AS400 system that is administer by half witted admins that place extra periods all over the place in an AS400 system (look *SYS != *SQL, you can not use *SYS when you are brainwashed into thinking that it is the same as *SQL). You will need to go the VBA route (hooray... please shoot me now).
For those of you not really familiar with the VBA way of doing things, it involves a lot of pain. Please observe (I've named the DSN as400_connect):
Public wspAS400 as Workspace
Public cntAS400 as Connection
Public dbAS400 as Database
Public Function IWroteThisFunctionBecauseOurAdminsAreDumb()
Dim qryDef as QueryDef
Dim rs as RecordSet
Dim SQLString as String
On Error GoTo ConnectionError
Set wspAS400 = DBEngine.CreateWorkspace("idiot", "", "", dbUseODBC)
Set dbAS400 = wspAS400.OpenDatabase("idiot_db", , , "ODBC;DSN=as400_connect;DATABASE=SM456J12")
Set cntAS400 = wspAS400.Connections(0)
On Error GoTo QueryError
SQLString = "SELECT * FROM ""CHK.ENTR""/BILLNO"
Set qryDef = cntAS400.CreateQueryDef("", SQLString)
Set rs = qryDef.OpenRecordset
DoCmd.SetWarnings False
'Insert you records into you MS Access DB here
DoCmd.SetWarnings True
ConnectionError:
MsgBox "Something got F***ed up!"
GoTo CleanUp
QueryError:
MsgBox "Something got F***ed up!"
GoTo CleanUp
CleanUp:
On Error Resume Next
rs.Close
qryDef.Close
Set rs = Nothing
Set qryDef = Nothing
cntAS400.Close
wspAS400.Close
Set cntAS400 = Nothing
Set dbAS400 = Nothing
Set wspAS400 = Nothing
End Function
That should get you started on getting crap out of the AS400 system and into your MS Access database. Notice that I am using the *SYS naming scheme. Try both the *SYS and *SQL naming scheme (library/member, library.member) to see which one your AS400 system is using (or at least will resolve). You can change that bit of information in the DSN entry on your system under ODBC Administration in Windows.
PS: Please make sure you have the damn ODBC driver from IBM before you even try setting up the DSN.
Saturday, October 24, 2009
I have a problem
I think you can see what it is:
I'm more upset that they didn't show the peas being eaten as well.
At least that's how I see a SOAP based conversation going.
I'm more upset that they didn't show the peas being eaten as well.
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body>
<m:RSVP xmlns:m="http://justy.yogabagaba.lan/partyparty">
<m:InYoTummy>False</m:InYoTummy>
</m:RSVP>
</soap:Body>
</soap:Envelope>
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body>
<m:GreenBeans xmlns:m="http://justy.yogabagaba.lan/partyparty">
<m:Message>I feel your pain</m:Message>
</m:GreenBeans>
</soap:Body>
</soap:Envelope>
At least that's how I see a SOAP based conversation going.
USB Zebra doggy style
Do you have a Zebra printer that has firmware restrictions? I'm looking at you FedEx!
Well, most FedEx printers with custom firmware (99% of them) still understand raw ZPL II commands. If you have a dotNET or Java application that is sending ZPL II commands to the printer then you already know that the parallel port is the easiest way to do it.
But let's say that you code with the assumption that you'll always be on a parallel part and then suddenly you find yourself toe to toe with a locked up FedEx Zebra (Z4M is the one I seem to be running into lately).
These printers are USB and using the dotNET stack to send USB ZPL II to the printer is not only a headache, but you'll have a better chance to make PNGs and send them to the printer to be printed.
Instead, setup the printer to have a network share "we'll say Printer in this case", pull up a command line in windows and chant the following words:
Ta-Da! Now you can send ZPL II to a USB printer via the usual raw data port API Stuff. This also has the happy effect of by-passing evil FedEx firmware locking out stuff thingies.
Well, most FedEx printers with custom firmware (99% of them) still understand raw ZPL II commands. If you have a dotNET or Java application that is sending ZPL II commands to the printer then you already know that the parallel port is the easiest way to do it.
But let's say that you code with the assumption that you'll always be on a parallel part and then suddenly you find yourself toe to toe with a locked up FedEx Zebra (Z4M is the one I seem to be running into lately).
These printers are USB and using the dotNET stack to send USB ZPL II to the printer is not only a headache, but you'll have a better chance to make PNGs and send them to the printer to be printed.
Instead, setup the printer to have a network share "we'll say Printer in this case", pull up a command line in windows and chant the following words:
NET USE LPT1 \\127.0.0.1\Printer /PERSISTENT:YES
Ta-Da! Now you can send ZPL II to a USB printer via the usual raw data port API Stuff. This also has the happy effect of by-passing evil FedEx firmware locking out stuff thingies.
JSF and beyond
As far as intros to the Java EE go, once you understand the idea of JSP you just start adding layers.
JavaServer Faces (JSF) uses JSP to dispaly pages, however, instead of messing with the URL or setting cookies to keep track of your session, JSF adds Java objects to keep track of that. The objects are Java Beans (not to be confused with EJB) that provide a layer between the JSF container and your Java objects.
That's right, JSF is a container that runs inside a web container. You might think that this would add a ton of overhead, but you'd be surprise at what they squish in there.
JSF was based on the ideas of Struts from Apache. Struts brought a MVC container to the web container. The ease of MVC made people go ga-ga. In the end the number of layers and MVC frameworks exploded. So it would be difficult to try and cover them all. I am going to focus on ICEFaces here on my page since that is what I use.
JSF is an awesome method to make web based applications and over the next couple of posts, I'll show some basic uses.
JavaServer Faces (JSF) uses JSP to dispaly pages, however, instead of messing with the URL or setting cookies to keep track of your session, JSF adds Java objects to keep track of that. The objects are Java Beans (not to be confused with EJB) that provide a layer between the JSF container and your Java objects.
That's right, JSF is a container that runs inside a web container. You might think that this would add a ton of overhead, but you'd be surprise at what they squish in there.
JSF was based on the ideas of Struts from Apache. Struts brought a MVC container to the web container. The ease of MVC made people go ga-ga. In the end the number of layers and MVC frameworks exploded. So it would be difficult to try and cover them all. I am going to focus on ICEFaces here on my page since that is what I use.
JSF is an awesome method to make web based applications and over the next couple of posts, I'll show some basic uses.
Maybe it is because I have a kid that this seems all the more funnier.
At any rate this is very wrong and do not play this in an area where others can hear it. I can assure you it will offend.
I think the best part is that the Nick Jr. is visible even in the lil' Jon parts.
Update: So Lazy Town Entrainment decided to enforce their copyright claims on the last video, so par for the course someone re-posted it. It's a shame that Google has no backbone.
At any rate this is very wrong and do not play this in an area where others can hear it. I can assure you it will offend.
I think the best part is that the Nick Jr. is visible even in the lil' Jon parts.
Update: So Lazy Town Entrainment decided to enforce their copyright claims on the last video, so par for the course someone re-posted it. It's a shame that Google has no backbone.
Monday, October 19, 2009
JSP and Java EE
If you are looking for a good intro into the semantics of JSP then may I suggest here.
So what are Java Server Pages (JSP)? If you have done any work with PHP then you'll be right at home with JSP.
JSP is a method of creating Servlets with specially formatted HTML pages. You add in Java code scripts inside tags delimited by <% and %> (properly called: scriptlets I know, I find myself calling them Java Script sometimes too, but that's a whole different thing)
Expressions, one line shots of Java code that return a String, are encapsulated in <%= %>
Here is a quick sample of the two intermixed:
If that brings up memories of PHP, you wouldn't be the first. JSP also adds Directives <%@ %> and Declarations <%! %>. The latter being important because this is how you add methods to the servlet that will be created from your JSP.
The servlet that is created for also has some special data members added to help you out. The tutorial covers how to use these quite well. It is important that you use these members because most of the time you're JSP is assumed to be thread safe (try not to break that assumption.)
The really cool thing is JSP tags! Unlike PHP (but like ColdFusion, if you've ever used it) you have access to a tag library. These tags quickly provide functions that you're most likely to use (like include another page.) You can also write your own library of JSP tags to encapsulate logic in your pages. This effectively allows you to separate logic from presentation (the ultimate goal in web application.)
But this brings us bark to the idea of MVC vs. Three Tier. JSP acts as our presentation in Java EE, however JSP brings us almost too close to Three-Tier design. Things that you want to go from page to page (shopping cart contents come to mind) have to either be pushed down to the database or passed through cookies/URL. This can make a lot of developers feel uneasy because it is a lot of work for such a small gain (easy presentation of Java objects.) If only there was a way to keep the ease of MVC design, have the ease of JSP presentation, and still have the flexibility of Three-Tier design.
Lucky for you, there is. There has been a lot of Java community members banging their heads over this, and over the years it has yielded about a dozen or so very mature frameworks. All coming together in the Java standard call Java Server Faces (JSF).
As you can see JSP offers a very powerful method of building presentations of Java objects. Many companies use JSP as the display end of their products. Later I'll cover JSF and show you how to bring the ease of MVC design into a Multi-Tier development platform.
So what are Java Server Pages (JSP)? If you have done any work with PHP then you'll be right at home with JSP.
JSP is a method of creating Servlets with specially formatted HTML pages. You add in Java code scripts inside tags delimited by <% and %> (properly called: scriptlets I know, I find myself calling them Java Script sometimes too, but that's a whole different thing)
Expressions, one line shots of Java code that return a String, are encapsulated in <%= %>
Here is a quick sample of the two intermixed:
<%
int j = 0;
while (j != 12 {
%>
<div style="border:1px dotted #338833">
This is line #<%= j %>
</div><br />
<% } %>
If that brings up memories of PHP, you wouldn't be the first. JSP also adds Directives <%@ %> and Declarations <%! %>. The latter being important because this is how you add methods to the servlet that will be created from your JSP.
The servlet that is created for also has some special data members added to help you out. The tutorial covers how to use these quite well. It is important that you use these members because most of the time you're JSP is assumed to be thread safe (try not to break that assumption.)
The really cool thing is JSP tags! Unlike PHP (but like ColdFusion, if you've ever used it) you have access to a tag library. These tags quickly provide functions that you're most likely to use (like include another page.) You can also write your own library of JSP tags to encapsulate logic in your pages. This effectively allows you to separate logic from presentation (the ultimate goal in web application.)
But this brings us bark to the idea of MVC vs. Three Tier. JSP acts as our presentation in Java EE, however JSP brings us almost too close to Three-Tier design. Things that you want to go from page to page (shopping cart contents come to mind) have to either be pushed down to the database or passed through cookies/URL. This can make a lot of developers feel uneasy because it is a lot of work for such a small gain (easy presentation of Java objects.) If only there was a way to keep the ease of MVC design, have the ease of JSP presentation, and still have the flexibility of Three-Tier design.
Lucky for you, there is. There has been a lot of Java community members banging their heads over this, and over the years it has yielded about a dozen or so very mature frameworks. All coming together in the Java standard call Java Server Faces (JSF).
As you can see JSP offers a very powerful method of building presentations of Java objects. Many companies use JSP as the display end of their products. Later I'll cover JSF and show you how to bring the ease of MVC design into a Multi-Tier development platform.
Sunday, October 18, 2009
Going easy on the breaking return!
Wow I looked at my post on servlets and I see that I need to lay off the <br /> tag for awhile.
Servlets are the starting topic when covering the Java EE platform. So let's begin.
In a Java environment you have three key pieces to making your program run.
The class loader is the important one here. It is the job of the class loader to get your Java class loaded into the JVM. This is much the same as a loader for an OS.
The Class Loader is "boot strapped" by the java command line utility. This is all fine and dandy, up till you get to a point where you need classes loaded by a remote client.
Enter the container. The container is a concept much like the class is. A container is a class that loads other classes, much like the class loader. It can other things as well like support LDAP security, email users, establish an SSL connection, manage database transactions, and so on. The container is limited by the scope of the system class loader, but the container can load classes based on whatever rules it provides.
Much like a class hides data members from the programmer, containers hide the method of invocation for classes loaded into it. A web container gets an HTTP request and loads Java objects in response, it doesn't really matter how it goes about doing it.
Servlets are the base of the Java EE model. They are invoked by an HTTP request, by means of a web container (see above). Servlets implement the Servlet interface which allows a container to invoke and maintain the life cycle of the object. More than likely you will be looking to extend the javax.servlet.http.HttpServlet class. This class comes with pre-built methods to handle the common HTTP request. Such as:
and so on... Each servlet that you create translates into a web page. Each method implements logic to handle a type of request. You'll be spending the bulk of you code in the doGet and doPost methods.
Working with the base servlet model is not the idea tool for interactive web pages. Basically you are writing a web page in Java as opposed to HTML, which adds to the complexity. Using the base servlet model is good for operations that you really want fine grain control over the entire logic flow. Here is an example of a servlet. You can readily see that we're just writing a web page within Java.
As you can see this isn't exactly the greatest model. That's where JSP comes into play, but I'll cover that later. For now, you can see that a servlet allow fine control over what type of request will cause what action, but it is a lot to be asking you programmers to be Java/Web/Http experts all the time (ie, you could not manage [reasonably] a web site strictly made up of servlets.) Usually you will reserve servlets for testing EJBs and stuff that requires fine control over the process. You'll mostly use JSP/JSF for all other stuff.
Cheers!
In a Java environment you have three key pieces to making your program run.
- The Java Virtual Machine (JVM)
- The Classpath
- The Class loader
The class loader is the important one here. It is the job of the class loader to get your Java class loaded into the JVM. This is much the same as a loader for an OS.
The Class Loader is "boot strapped" by the java command line utility. This is all fine and dandy, up till you get to a point where you need classes loaded by a remote client.
Enter the container. The container is a concept much like the class is. A container is a class that loads other classes, much like the class loader. It can other things as well like support LDAP security, email users, establish an SSL connection, manage database transactions, and so on. The container is limited by the scope of the system class loader, but the container can load classes based on whatever rules it provides.
Much like a class hides data members from the programmer, containers hide the method of invocation for classes loaded into it. A web container gets an HTTP request and loads Java objects in response, it doesn't really matter how it goes about doing it.
Servlets are the base of the Java EE model. They are invoked by an HTTP request, by means of a web container (see above). Servlets implement the Servlet interface which allows a container to invoke and maintain the life cycle of the object. More than likely you will be looking to extend the javax.servlet.http.HttpServlet class. This class comes with pre-built methods to handle the common HTTP request. Such as:
- doDelete - to handle the HTTP DELETE request
- doGet - to handle the HTTP GET request
- doPost - to handle the HTTP POST request
and so on... Each servlet that you create translates into a web page. Each method implements logic to handle a type of request. You'll be spending the bulk of you code in the doGet and doPost methods.
Working with the base servlet model is not the idea tool for interactive web pages. Basically you are writing a web page in Java as opposed to HTML, which adds to the complexity. Using the base servlet model is good for operations that you really want fine grain control over the entire logic flow. Here is an example of a servlet. You can readily see that we're just writing a web page within Java.
import java.io.IOException;
import java.io,PrintWriter;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public class HelloWorld extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
PrintWriter wout = response.getWriter();
wout.println("<html>\n<head><title>Hello, World!</title></head>
\n<body><h1>Hello, World!</h1></body>\n<html>");
}
}
As you can see this isn't exactly the greatest model. That's where JSP comes into play, but I'll cover that later. For now, you can see that a servlet allow fine control over what type of request will cause what action, but it is a lot to be asking you programmers to be Java/Web/Http experts all the time (ie, you could not manage [reasonably] a web site strictly made up of servlets.) Usually you will reserve servlets for testing EJBs and stuff that requires fine control over the process. You'll mostly use JSP/JSF for all other stuff.
Cheers!
Thursday, October 15, 2009
Hello from BloGTK
Hello everyone. I'm trying out BloGTK as a client to Blogger. Mental note, SVG rendering will crash the program. So this is my second go at this post.
Pre-formatted code:
Thank you and now a random image.
Pre-formatted code:
#include<iostream>
int main(int argc, char * argv []) {
std::cout << "You entered " << argc << " CLI arguments. They are:" << std::endl;
for(int x=0; x<argc; x++)
std::cout << argv[x] << std::endl;
return 0;
}
Thank you and now a random image.
Understanding OOP pitfalls in Java EE:
Object Orientated Programming (OOP) is the foundation on which the Java language is built upon. When you build a Java program you are building a set of objects that will work together towards a goal. This brings me to the first point: in Java EE it is important to remember to think of the object and not the task.
A common pitfall is to start adding logic into a class that broadens its scope. Remember, objects should be single shot, single idea things. Let's say you have an object call BankAccount. You would put into this class the account number, the account name, address, details, balance and so forth. However, you may be tempted to place logic that converts the object into, say a SQL string or properly formats an address for display in a GUI. NO! Do not add logic to the class if it does not need to be added to keep the concept that the class represents, sane. A bank account does not need to know about SQL, a bank account does not need to know about GUIs.
The reasoning behind this is that the Java EE platform takes a lot of the bridge work out for you, you adding it back in prevents you from fully accessing all of the features (besides if you're adding them in who is Java to tell you wrong?)
Complex logic goes into classes that will handle other classes. In the example above you might include the BankController class. It will be this class' job to gather the needed objects to handle the object you pass in. The BankController
class may need to gather the objects that handle permissions, validation, database connectivity, and so forth. The Java EE platform has this covered for you. So you just worry about modeling classes after the real world thing they represent.
Object Orientated Programming (OOP) is the foundation on which the Java language is built upon. When you build a Java program you are building a set of objects that will work together towards a goal. This brings me to the first point: in Java EE it is important to remember to think of the object and not the task.
A common pitfall is to start adding logic into a class that broadens its scope. Remember, objects should be single shot, single idea things. Let's say you have an object call BankAccount. You would put into this class the account number, the account name, address, details, balance and so forth. However, you may be tempted to place logic that converts the object into, say a SQL string or properly formats an address for display in a GUI. NO! Do not add logic to the class if it does not need to be added to keep the concept that the class represents, sane. A bank account does not need to know about SQL, a bank account does not need to know about GUIs.
The reasoning behind this is that the Java EE platform takes a lot of the bridge work out for you, you adding it back in prevents you from fully accessing all of the features (besides if you're adding them in who is Java to tell you wrong?)
Complex logic goes into classes that will handle other classes. In the example above you might include the BankController class. It will be this class' job to gather the needed objects to handle the object you pass in. The BankController
class may need to gather the objects that handle permissions, validation, database connectivity, and so forth. The Java EE platform has this covered for you. So you just worry about modeling classes after the real world thing they represent.
MVC, why is it so important and why n-tier matters:
If you've been programming for a while, you've undoubtedly have come across the Model-View-Controller (MVC) design pattern. When I started programming my code started out as just one long procedural call, the "everything in the main function" design pattern. As I got better with programming I started breaking logic into different functions and calling the functions. Eventually, I got to Object Oriented Programing (OOP) and began the path of looking at programming not as a bunch of steps that need to take place to reach a goal; but instead as distinct ideas and concepts that put together, made a program.
The MVC design pattern was developed to give developers a way of looking at a problem and separating common areas of a program. Basically, a program has to deal with the end-user and a database. We could easily design a monolithic program that did the task, but if something changes in the database, then we need to modify all of our code (or at the very least hunt down the section in our code that deals with the database) to adapt to the change. Logically speaking, it wasn't long until people started to understand that the user interface should be a separate body of code from the part that deals with the database. As user interfaces got more and more complex, the logic that handles validation and talking to the database module had to be separated too. Thus was born the MVC design pattern. In essence, gurus would preach the divide and conqueror technique of MVC to new developers in hopes that they would start their programs in the vein of MVC. This way as the program evolved, it evolved with ease.
However, there is one fall down to MVC. It assumes that all things are on the same machine. When we start connecting to a remote database to update our view, we start getting into handling SQL statements, exceptions, invalid return values, and many more issues (does NULL mean that the line should be blank or does it mean invalid?). The view is not the place to handle this type of code, or at least if you want to keep things simple. Thus, people holding to the MVC design pattern have created ways of wrapping database connections into convenient APIs that handle the mess, so that you can devote more time to making a good user interface.
It's a nice thought, but it only goes so far. Just pick up a book on MySQL and PHP and notice how many times they suggest that you just ignore exceptions. Eventually, way back in the day don't let me make you think that this is a new development, it was understood that one machine just couldn't run everything (contrary to IBM's claims), and thus we embarked on a mission to find a way to make a program run on multiple machines. Enter multi-tier design patterns.
At first, people used messaging systems to communicate between different machines. Think of it as Bob's copy of program A is running on Server A, Jane's copy of program A in running on Server B, and so on. Server A and Server B talk to each other to keep data in sync using a messaging protocol. This was an alright solution, but it really didn't get far from the MVC way of looking at things. It was also a waste of resources, the View didn't use as much resources as say the Controller; the Model used the most disk space; the View was limited to the interface capabilities of the machine holding the Model and the Controller. Basically, if your database had eaten all of your hard drive, you upgraded the drives; controller eating all your memory, you added more. It would have been better to place the Model on a machine with tons of hard disk space, the Controller on the fastest CPU, and the View on a system that supported familiar GUI elements.
Multi-tier design patterns were developed to allow each layer in the tier (Presentation, Logic, and Data) to run on different machines. Some used proprietary protocols to achieve this (SNA comes to mind). With the advent of the Internet, the standardization of TCP/IP as the protocol of choice, Microsoft bringing open network connectivity (I know, who would have thought), and the desire for things to be less single vendor and more heterogeneous, new methods would need to be put into place to actually implement multi-tier design patterns.
This is where multi-tier underwent its first redesign. Now instead of assuming that the protocol would be packed with the vendor, multi-tier patterns had to abstract protocols altogether; in essence the developer shouldn't have to worry about the protocol, as long as the program can see the server everything should work. While we haven't gotten away from the idea that a program is tied to a protocol (Web browsers still assume TCP/IP as the transport), we have made progress (Web browsers can used IPv4 or IPv6). So it's important to remember that multi-tier is still protocol dependent, just now you don't have to worry about directly working with the protocol (unless you really want to!?).
This redesign is what gives us the model that we all know and love. It breaks the way an application works into three parts. Presentation, Logic, and Data. At face value it looks a lot like MVC, and to an extent it is. However, in a multi-tier application the Presentation is assumed to never talk to the Data, all things must pass through the Logic layer. Where as in MVC, the Controller provides input to the Model, and the view gets the output of the Model. This is the fundamental difference between the two.
In MVC your View must deal with the data straight from the Model. In multi-tiered applications the Logic formats the Data into something that can be Presented.
In MVC, your web designers must know what kind of assumptions should be taken on data from the data source and how to issue the commands to get that data.
In Multi-tiered applications, the Logic handles all of this, your web developers simply access the properties of you logic (much better to write something like #{shoppingCart.orderNumber} versus SELECT ORDERNUMB FROM ORDERS WHERE SHOPPINGCART='cartnumber';).
All in all, multi-tiered design patterns have been developed to make use of multiple machines, abstract protocols from developers, and allow specialty developers to concentrate better on the task at hand. I know that some people still have the notion of what three and four tier development was like in the 60's, 70's, and 80's (which wasn't good and took long amounts of time to deploy) but the methods and tools have been refined to a point to make multi-tier more like Rapid Application Development (RAD) software. Simply put, MVC is an easier model to work within, but Multi-tier is continuing to keep the pressure on MVC as an easy model to develop within. Multi-tier isn't like it was back in the day, it has mature enough to be seriously considered before you begin your next enterprise application.
If you've been programming for a while, you've undoubtedly have come across the Model-View-Controller (MVC) design pattern. When I started programming my code started out as just one long procedural call, the "everything in the main function" design pattern. As I got better with programming I started breaking logic into different functions and calling the functions. Eventually, I got to Object Oriented Programing (OOP) and began the path of looking at programming not as a bunch of steps that need to take place to reach a goal; but instead as distinct ideas and concepts that put together, made a program.
The MVC design pattern was developed to give developers a way of looking at a problem and separating common areas of a program. Basically, a program has to deal with the end-user and a database. We could easily design a monolithic program that did the task, but if something changes in the database, then we need to modify all of our code (or at the very least hunt down the section in our code that deals with the database) to adapt to the change. Logically speaking, it wasn't long until people started to understand that the user interface should be a separate body of code from the part that deals with the database. As user interfaces got more and more complex, the logic that handles validation and talking to the database module had to be separated too. Thus was born the MVC design pattern. In essence, gurus would preach the divide and conqueror technique of MVC to new developers in hopes that they would start their programs in the vein of MVC. This way as the program evolved, it evolved with ease.
However, there is one fall down to MVC. It assumes that all things are on the same machine. When we start connecting to a remote database to update our view, we start getting into handling SQL statements, exceptions, invalid return values, and many more issues (does NULL mean that the line should be blank or does it mean invalid?). The view is not the place to handle this type of code, or at least if you want to keep things simple. Thus, people holding to the MVC design pattern have created ways of wrapping database connections into convenient APIs that handle the mess, so that you can devote more time to making a good user interface.
It's a nice thought, but it only goes so far. Just pick up a book on MySQL and PHP and notice how many times they suggest that you just ignore exceptions. Eventually, way back in the day don't let me make you think that this is a new development, it was understood that one machine just couldn't run everything (contrary to IBM's claims), and thus we embarked on a mission to find a way to make a program run on multiple machines. Enter multi-tier design patterns.
At first, people used messaging systems to communicate between different machines. Think of it as Bob's copy of program A is running on Server A, Jane's copy of program A in running on Server B, and so on. Server A and Server B talk to each other to keep data in sync using a messaging protocol. This was an alright solution, but it really didn't get far from the MVC way of looking at things. It was also a waste of resources, the View didn't use as much resources as say the Controller; the Model used the most disk space; the View was limited to the interface capabilities of the machine holding the Model and the Controller. Basically, if your database had eaten all of your hard drive, you upgraded the drives; controller eating all your memory, you added more. It would have been better to place the Model on a machine with tons of hard disk space, the Controller on the fastest CPU, and the View on a system that supported familiar GUI elements.
Multi-tier design patterns were developed to allow each layer in the tier (Presentation, Logic, and Data) to run on different machines. Some used proprietary protocols to achieve this (SNA comes to mind). With the advent of the Internet, the standardization of TCP/IP as the protocol of choice, Microsoft bringing open network connectivity (I know, who would have thought), and the desire for things to be less single vendor and more heterogeneous, new methods would need to be put into place to actually implement multi-tier design patterns.
This is where multi-tier underwent its first redesign. Now instead of assuming that the protocol would be packed with the vendor, multi-tier patterns had to abstract protocols altogether; in essence the developer shouldn't have to worry about the protocol, as long as the program can see the server everything should work. While we haven't gotten away from the idea that a program is tied to a protocol (Web browsers still assume TCP/IP as the transport), we have made progress (Web browsers can used IPv4 or IPv6). So it's important to remember that multi-tier is still protocol dependent, just now you don't have to worry about directly working with the protocol (unless you really want to!?).
This redesign is what gives us the model that we all know and love. It breaks the way an application works into three parts. Presentation, Logic, and Data. At face value it looks a lot like MVC, and to an extent it is. However, in a multi-tier application the Presentation is assumed to never talk to the Data, all things must pass through the Logic layer. Where as in MVC, the Controller provides input to the Model, and the view gets the output of the Model. This is the fundamental difference between the two.
In MVC your View must deal with the data straight from the Model. In multi-tiered applications the Logic formats the Data into something that can be Presented.
In MVC, your web designers must know what kind of assumptions should be taken on data from the data source and how to issue the commands to get that data.
In Multi-tiered applications, the Logic handles all of this, your web developers simply access the properties of you logic (much better to write something like #{shoppingCart.orderNumber} versus SELECT ORDERNUMB FROM ORDERS WHERE SHOPPINGCART='cartnumber';).
All in all, multi-tiered design patterns have been developed to make use of multiple machines, abstract protocols from developers, and allow specialty developers to concentrate better on the task at hand. I know that some people still have the notion of what three and four tier development was like in the 60's, 70's, and 80's (which wasn't good and took long amounts of time to deploy) but the methods and tools have been refined to a point to make multi-tier more like Rapid Application Development (RAD) software. Simply put, MVC is an easier model to work within, but Multi-tier is continuing to keep the pressure on MVC as an easy model to develop within. Multi-tier isn't like it was back in the day, it has mature enough to be seriously considered before you begin your next enterprise application.
Wednesday, October 14, 2009
Logic, Database, Your customer:
That's the basic breakdown when it comes to providing central application services. You centralize the applications so you don't have to network share every single application you want your clients to use (it just doesn't look professional).
When you centralize your applications in your company, you add many different complex challenges to providing those applications and keeping things manageable and agile.
In a multi-tier environment, you have separate processes that manage all of that. You have a web server that sends out the web page, you have an application server that handles the logic of your session and validating values, and you have a presistance layer that handles the logic of connecting to your database. Each layer can service any other application as well. You build the logic and use it in every application where it is needed.
This simplifies management because now you can take a project and break it into many smaller parts, instead of passing around one large PHP file with about a dozen includes.
It makes sense to break your large projects into smaller more manageable chunks. It's nice to know that you can write and execute common code once, instead of writing 30 or so include file and having who knows how many threads of execution going over the same include file. With a multi-tier platform one can manage the ever increasing demand of constantly growing flat file systems, add new features without major code surgery, and reduce the amount of covering the same ground (not only in code, but in CPU cycles as well).
Giving credit where credit is due, RoR is really starting to mature in the MVC realm of web frameworks, but it still has many short comings like reducing number of threads doing the exact same thing, or rich messaging between processes (however they do have a nice RESTful services API, but so does Java and dotNet).
In the end, modern web application frameworks provide robust one shot solutions to many problems, but as your demands grow managing those applications becomes harder and harder. Multi-tier applications make it easy to scale to large deployments with a little investment up front. Modern multi-tier has come a long way since the days of spending months on each single layer, frameworks have become more compact and interchangeable, providing quick application development, testing, and deployment.
That's the basic breakdown when it comes to providing central application services. You centralize the applications so you don't have to network share every single application you want your clients to use (it just doesn't look professional).
When you centralize your applications in your company, you add many different complex challenges to providing those applications and keeping things manageable and agile.
- How do we secure our applications?
- How do we make them available to the clients?
- How can we remove redundant functionality?
- How can we simplify the deployment process?
- Database, logic, and client...Oh my!
- The client (web, thick, thin, or services) calls up an action like: *Create new shopping cart, *Add product #23, #46, #107, and #428-A to the cart
- Check out using the following information: (name, address, CC# etc...)
- Send back the result of the transaction.
In a multi-tier environment, you have separate processes that manage all of that. You have a web server that sends out the web page, you have an application server that handles the logic of your session and validating values, and you have a presistance layer that handles the logic of connecting to your database. Each layer can service any other application as well. You build the logic and use it in every application where it is needed.
This simplifies management because now you can take a project and break it into many smaller parts, instead of passing around one large PHP file with about a dozen includes.
It makes sense to break your large projects into smaller more manageable chunks. It's nice to know that you can write and execute common code once, instead of writing 30 or so include file and having who knows how many threads of execution going over the same include file. With a multi-tier platform one can manage the ever increasing demand of constantly growing flat file systems, add new features without major code surgery, and reduce the amount of covering the same ground (not only in code, but in CPU cycles as well).
Giving credit where credit is due, RoR is really starting to mature in the MVC realm of web frameworks, but it still has many short comings like reducing number of threads doing the exact same thing, or rich messaging between processes (however they do have a nice RESTful services API, but so does Java and dotNet).
In the end, modern web application frameworks provide robust one shot solutions to many problems, but as your demands grow managing those applications becomes harder and harder. Multi-tier applications make it easy to scale to large deployments with a little investment up front. Modern multi-tier has come a long way since the days of spending months on each single layer, frameworks have become more compact and interchangeable, providing quick application development, testing, and deployment.
Java EE 5:
I'm really big into Java. I know a ton of people boo Java because they think it is slow or some other reason. I'm here to tell you that Java is very prevalent and very useful. Many websites are powered by Java EE and with good reason.
Over the years Sun and the Java Community have added really exciting technologies to the Java Platform. Some have seen their day come and go, but many have really useful corner cases. However, the best platform I've seen in some time is the Java EE 5 platform.
Java EE is one of the few multi-tier application platforms still in town. The really hot craze right now is your good old LAMP stack or RoR. However, these approaches return to the days of monolithic hosting of network applications. This approach is nice for small to medium deployments, but without some serious modifications, do not scale well in large deployments. This is one of the reasons why LAMP has taken off so much, the stack is completely open source, so modifications can be done on the code easily to adjust to large deployments.
Multi-tiered software was made to scale. It has lost favor since it takes a lot of resources to get started at first (due mostly from configuring and creating the first bits of each layer.) Java and .NET have taken steps to address this large problem, how do we make multi-tiered APIs but still make it easy for small deployments?
Java EE 5 and the future EE 6 bring a lot to the table to make it easy to stop boiler plating things and start deploying services to meet your customers demands. I know it sound a lot like a big commercial.
Multi-tier software has gotten a bad rap from things like DCOM and CORBA. But if you sit down and try Java EE 5, I'm sure you'll see that multi-tier has come a long way from where it was.
I'm really big into Java. I know a ton of people boo Java because they think it is slow or some other reason. I'm here to tell you that Java is very prevalent and very useful. Many websites are powered by Java EE and with good reason.
Over the years Sun and the Java Community have added really exciting technologies to the Java Platform. Some have seen their day come and go, but many have really useful corner cases. However, the best platform I've seen in some time is the Java EE 5 platform.
Java EE is one of the few multi-tier application platforms still in town. The really hot craze right now is your good old LAMP stack or RoR. However, these approaches return to the days of monolithic hosting of network applications. This approach is nice for small to medium deployments, but without some serious modifications, do not scale well in large deployments. This is one of the reasons why LAMP has taken off so much, the stack is completely open source, so modifications can be done on the code easily to adjust to large deployments.
Multi-tiered software was made to scale. It has lost favor since it takes a lot of resources to get started at first (due mostly from configuring and creating the first bits of each layer.) Java and .NET have taken steps to address this large problem, how do we make multi-tiered APIs but still make it easy for small deployments?
Java EE 5 and the future EE 6 bring a lot to the table to make it easy to stop boiler plating things and start deploying services to meet your customers demands. I know it sound a lot like a big commercial.
Multi-tier software has gotten a bad rap from things like DCOM and CORBA. But if you sit down and try Java EE 5, I'm sure you'll see that multi-tier has come a long way from where it was.
Subscribe to:
Posts (Atom)