|
|
||
|
|
For a while I had a blog on Software Architecture and Design hosted at JavaWorld. I no longer post to this blog but here're all my postings in reverse chronological order: |
| KISS Your Web Services |
| In my previous blog entry, I talked about the state of confusion that many professionals dealing with Web Service technology are in. Well, that blog entry stirred up some interest and I ended up writing a follow-up article about the issue. The article is titled "KISS Your Web Services". Check it out in the Magazine Articles section. Feel free to pass your thoughts on to me. It’s always good to hear from fellow developers. |
 Top |
| WS-Confusion? |
| There’s absolutely no doubt about it… Web Services are hot and are here to stay. XML Schemas, SOAP, and WSDL are all indispensable while working with Web Services. Yes, to some extent (and in some form) UDDI too. And let’s not forget the Security related specifications such as XML Encryption, XML Digital Signatures, and WS-Security, which are quite useful when Web Service boundaries extend beyond the corporate firewall. As a consultant and an architect, I have implemented and audited/assessed complex business software systems that leverage Web Service technology as a core part of their architecture. The specifications that I mentioned above are pretty much all that I have used/seen used. Furthermore, all the Web Services have always been over HTTP/HTTPS. So what about all the other Web Service Specifications such as WS-Transaction, WS-Routing, WS-Reliability, WS-ReliableMessaging, WS-BPEL, WS-Notification, WS-Eventing, WS-AtomicTransactions, WS-Coordination, WS-SecureConversation, and so on? While I agree with the theory of these specifications and that most of them are very well written, my question is: Are we making Web Services more complex than they need to be? I am very interested in knowing if any one of you have used or seen these or other WS-specifications used in real-world (existing) systems? |
| Top |
| Web Service Interoperability |
| For the past year I have been the Technical Architect on a very unique and interesting project that uses J2EE on the presentation tier and Microsoft on the middle tier. Care to guess what technology I am using to call my business logic implemented in C# from my Java code. Suffice it to say “Thank God for Web Services.” Microsoft .NET has built in support for it. And on the Java side I am using Apache Axis (no, not the Java WSDP). For each Web Service, I start off with an XML Schema (created using XML Spy), use Microsoft’s XSD.exe tool to create my C# classes, and top it off with Axis’ wsdl2java tool to create the Java Stubs. After that, it’s coding as usual. Sounds easy, and for the most part it is, except for those minor annoyances… I was going to create a list of these “annoyances”, but [luckily] found a blog entry that does exactly that. Appropriately titled “Top Ten Tips for Web Services Interoperability”, you can check it out at http://blogs.msdn.com/smguest/archive/2004/08/12/213659.aspx. |
| Top |
| SOA Blueprints |
| In my first blog posting, I talked about Service-Oriented Architecture (SOA). But instead of belaboring the pros and cons of SOA, I provided a simple definition of SOA and then spent the rest of my time talking about ways to identify an SOA and weed out potential imposters. At about the same time that I was busy with my SOA blog, a group of companies led by The Middleware Company (TMC), and BEA were busy putting the final touches on a specification that defines best practices for developing applications using SOA. The specification is aptly called “The SOA Blueprints”. And thankfully, rather than being an abstruse specification that bores the readers with endless theory, the SOA Blueprints highlights the best practices through a fictitious, diverse corporation called GeneriCo. What is not fictitious though is that like many corporations, GeneriCo has also decided to standardize on SOA as its main application architecture. The SOA Blueprints shows us how GeneriCo navigates itself to its end goal of achieving a true SOA. Ultimately, the SOA blueprints is all about how SOA can solve real-world issues. In the process of doing so it creates a common vocabulary that allows discussing SOA in an architecturally neutral way. And since the SOA Blueprints specification is architecturally neutral, it can be equally employed in all SOA implementations regardless of whether they are built in J2EE, CORBA, Microsoft .NET, or using Web Services. I strongly urge you to find out more about the SOA blueprints at http://www.soacenter.com/. |
| Top |
| JSF: Did Sun Mess Up (Again)? |
| In March 2004, Sun released the final version of the JavaServer Faces (JSF) 1.0 specification (JSR 127). If you were completely naïve (which I know you are not!) and read the final JSF specification (or any of its earlier draft versions) along with Sun’s marketing spin on it (JSF), you would probably think that JSF is the best thing since sliced bread. You would probably wonder how the Java community ever survived without JSF. Sun obviously seems to think so and to that end has even made JSF part of J2EE 1.4. I beg to differ. Granted, Sun needed to formalize web application architecture and the relation between Servlets, JSP pages, and tag libraries (such as the well designed JSTL) with more than just some theory on Model 2 (Sun’s term for MVC) architecture. Therefore the need for JSF is justified. Not to belittle Sun’s efforts, JSF does have a reasonable architecture that takes into account Internationalization, Event Handling, Component Rendering, Data Validation, etc., all of which are core pieces of today’s web applications. So, what is my problem? I’ll discuss two of them in this blog. Issue #1: JSF does not allow extension of its controller Most J2EE web developers are familiar with an MVC framework available from Apache called Struts. Struts is a well designed and proven framework that has been used on countless projects. I, myself, have used Struts on numerous projects with very good results. While Struts does not always do exactly what I want it to do, it is very extensible. For example, I have extended the Struts controller significantly (using its well defined extension points) to provide a very configurable and tight security model to all my web applications. Since all requests are always intercepted by the controller, the caller’s credentials are always authenticated to ensure that the caller is only allowed access to resources (pages) for which they have been granted permission. This is even more powerful because none of the JSP pages or other Java code (such as Action beans and Form beans) written by developers has any security related logic in them at all. I have also extended the controller to allow the end user (i.e. the person using the browser) to change the desired locale (language) in other ways besides changing the browser settings. There are several other extensions as well. The salient feature here is that this very ability to be extended (sometimes in ways that even the original designer had not foreseen) is the mark of a good framework. Unfortunately, JSF does not allow extension of its controller. It does not even provide “extension” or “pluggability” points where one can insert custom code to be executed and affect the controller behavior. As a result, there is no central point in JSF from which custom code (such as code that enforces security) can be guaranteed to be executed. Issue #2: The JSF Validation framework is incomplete Apache’s Commons Validation framework is a powerful and highly extensible framework that provides both server- and client-side validation. It can be used in conjunction with Struts (where it originated) or stand alone. JSF has a validation framework as well. While this framework works well on the server side, it does not provide any facility for generating client-side validation code. Client-side validation is a very important step in enabling web applications to give the user an illusion of a highly responsive, “fast”, and “friendly” desktop application. Am I being too hard?... I think not. While these issues by themselves may not be enough to frustrate me, it is the fact that Sun somehow missed (or worse yet, ignored) them that vexes me. I have to believe that the Sun architects behind JSF are very familiar with Struts and the Validator framework. After all, for a long time Struts was the only real game in town for creating MVC based web applications on the J2EE platform. And yet the Sun architects did not incorporate similar functionality (to Struts) within JSF. To establish a standard and be a viable alternative, JSF should have subsumed all of the capability provided by popular frameworks such as Struts and offered even more. Instead, JSF provides a bare minimum, sufficient only for creating simple applications. Proponents justify this stance by stating that JSF can be used in conjunction with other more powerful frameworks such as Struts. In fact they tout this as one of JSF’s strengths. In my opinion, this defeats one of the prime goals behind JSF; that of simplicity. If using Struts by itself is complicated (as claimed by many), then think about how complicated using JSF and Struts together would be. In my opinion, JSF does not provide the added benefit that would warrant the additional complexity. In my opinion, it also seems as if Sun was trying so hard to catch up with (and be like) Microsoft’s ASP.NET framework that they neglected some of the excellent architectural pieces that were already present in the J2EE camp. Does anyone see a pattern here (JSP and ASP, EJB and MTS)? Many JSF proponents argue that the internal implementations are different. To them I say “think Windows and Mac”. Worst of all, in the process, JSF also inherited a limitation from ASP.NET; a weak controller model. So while JSF is officially part of J2EE 1.4, I am more than likely going to continue to use Struts for the foreseeable future… unless of course someone can convince me otherwise. Care to try? |
| Top |
| Client Side Data Validation: A False Sense of Security |
| Microsoft defines a Web Application (WebApp) as a software program that uses HTTP for its core communication protocol and delivers Web-based information to the user in the HTML language. Such applications are also called Web-based applications. Although one could create a custom client for such an application, most applications will leverage an existing web browser client such as Internet Explorer, Netscape Navigator, Opera, etc. In this blog, I will be focusing entirely on the set of webapps that leverage a browser on the client side. There are many benefits of creating a web application. A few of them are:
That’s where data validation and a properly designed validation framework fit in. No, this is not a typo or misprint. Security details such as SSL, certificate management, firewalls, etc. are important, but provide only the icing on the cake. They don’t guarantee that the cake (i.e. your webapp) is baked well. What I mean is that while these “details” may make it harder for a hacker to find holes in your webapp, they don’t seal the loopholes themselves. That is, they only delay the inevitable hacking of your application. Take SSL as an example. A common misconception is that SSL provides web application security. The fact is that it does not. SSL is used only to encrypt the data between the web browser and the web server, and thus prevents eavesdropping. SSL has no knowledge of your webapp and hence provides no security to it. As a software consultant, I’ve had the opportunity to not only design and implement webapps but to assess/audit many webapps as well. I often encounter web pages within the application that are very sophisticated with lots of client side JavaScript that perform all kinds of checks on the data entered by the user. Even the HTML elements have data validation attributes such as MAXLENGTH. The HTML form is only submitted upon successful validation of all the data entered. The server side happily performs the business logic once it receives the posted form (request). Do you see the problem here? The developers have made a big assumption of “control” here. They assume that all users of the webapp will be equally honest. They assume that all users will always access the webapp through the browser(s) that they (the developers) have tested upon. And so on. What they have forgotten is that it is very easy to simulate browser-like behavior through the command line using freely available tools. In fact, almost any “posted” form can be sent by typing in the appropriate URL in the browser window; although an easy way to prevent such “form posting” is to disable GET requests for these pages. But there is no way to prevent any one from simulating or even creating their own browser to hack into your system! The underlying problem here is that the developers have failed to recognize the main difference between client side validation and server side validation. The main difference between the two is NOT where the validation is occurring such as on the client or on the server. The main difference is in the purpose behind the validation. Client side validation is merely a convenience. It is performed to provide the user with quick feedback. It is performed to make the application appear responsive and give the illusion of a desktop application. Server side validation, on the other hand, is a must for building a secure webapp. It is done to ensure that all data sent to the server from the client is valid data, no matter how the data was entered in on the client side. Thus, only server side validation provides real application level security. Many developers fall into the trap of a false sense of security by performing all data validation only on the client side. Here are two examples to put things in perspective Example 1 A typical “Logon” page has a textbox to enter a username and another textbox to enter a password. On the server side, one may encounter some code in the receiving servlet that constructs a SQL query of the form "SELECT * FROM SecurityTable WHERE username = '" + form.getParameter("username") + "' AND password = '" + form.getParameter("password") + "';" and execute it. If the query comes back with a row in the results then the user successfully logged in, otherwise not. The first problem here is the way that the SQL is constructed, but let’s ignore that for this blog. What if the user types in a username such as “Alice’--“? Assuming that there is a user named “Alice” in SecurityTable, the user (or shall we call her “hacker”) successfully logs in. I’ll leave finding out why this happens as an exercise for you. Some creative client side validation can prevent normal users from doing this from the browser. But what about the case where JavaScript is disabled on the client or for those advanced users (hackers) who can use another “browser like” program to send direct commands (HTTP POST and GET commands)? Server side validation is a must to prevent something like what was described above from happening and hence plugging a security hole in the webapp. SSL, firewalls, and the likes won’t help you here. Example 2 A typical “User Registration” page for a public but limited access webapp includes several textboxes for user identification and authentication information such Name, SSN, Date of Birth, and other relatively uniquely known information. Once the user has proven her identity, she is issued a username and password to access the protected parts of the system. In special cases, the user may be prevented from directly registering and an “Administrative” user (i.e. the administrator) may have to register the user instead. The administrator uses the same registration page, but checkmarks a special checkbox on the page that tells the system (receiving servlet) to bypass all [special] checks and directly register the user. The JSP that renders the HTML page is smart enough only to include the checkbox if the user accessing the page is an administrator. So far so good? Not unless there is some server side validation in the receiving servlet. The receiving servlet checks to see if the “bypass checks” parameter is present and if it is then it bypasses all special checks and registers the user. But it must also check to see if the logged in user is an administrator. Even though the JSP page did that when it rendered, the receiving servlet must perform the check again. In this case, the JSP check can actually be considered as part of the client side validation. It was merely done for convenience. After all, we don’t want to confuse regular users trying to register with the extra checkbox, since no matter what they select (checked or unchecked), it’s not going to make a difference. This is because regular users do not have the authority to bypass “authentication” checks. Furthermore, it would not be an impossible task for a hacker to figure out what the name of the checkbox was and manually issue a registration request with the checkbox name included in the request (with its value set to “checked” of course). Therefore the receiving servlet must check the identity of the logged on user (if there is a user logged on) and only allow an administrator to bypass special checks in the registration process. Conclusion Remember, client side validation is for convenience and server side validation is for security. You must always perform at least as much validation on the server as you perform on the client. All properly designed validation frameworks, such as the Struts Validation Framework, handle this for you. Feel free to leave me a comment and let me know your thoughts… |
| Top |
| Model Driven Architecture |
| If you’ve been keeping up with your daily doze of buzzwords then you’ve most likely heard of MDA. MDA stands for Model Driven Architecture and is required knowledge for cocktail discussions. The Concept The concept behind MDA is certainly not new and is quite simple in theory. In its most rudimentary form, it is the all too familiar code generation that has been offered by leading software modeling tools such as Rational Rose and the Together family of products. These tools allow you to model your system as a series of packages and classes (for Java) and then generate the skeletal code based off of these models. They also offer something called “round trip engineering” in which you can make changes to your code and import these into your models thus keeping your models in sync with your code. Although a very noble concept, I have rarely seen it fully implemented in real projects. Even if a project did implement “round trip engineering”, I would question the benefit provided for the cost of doing so. MDA is more than code generation. It is a formalization of several concepts by the Object Management Group (OMG). The OMG is best known for its distributed object model specification called CORBA and the widely used modeling language called the Unified Modeling Language or UML. The Lingo At the very core of MDA is the concept of a model. A model is an abstraction of the end (or target) system. It serves as a prototype and a proof-of-concept. MDA defines two types of models. A Platform Independent Model (PIM) is one that describes the target system without any details about the specifics of the implementation platform. On the other hand, a Platform Specific Model (PSM) describes the target system on its intended platform, such as J2EE, .NET, CORBA, etc. The process of converting a PIM into a PSM is called transformation. A model (PIM or PSM) is written in a modeling language. The OMG does not restrict MDA to any particular language. However, the modeling language must be well defined, which means that it must be precise to allow interpretation by a computer. Therefore, a human language such as English is not an option (at least for the foreseeable future). An example of a good modeling language is (obviously) the UML. Is it just Hype? As I mentioned earlier, MDA is not a novel concept. We already talked about code generation, but database designers have been using a form of MDA for a long time. ErWin by Computer Associates is a CASE (Computer Aided Software Engineering) tool that provides MDA abilities to database designers and administrators. ErWin allows you to define your database design using a logical model. A logical database model is free from any database vendor specific details. In MDA terminology the logical model is a PIM. ErWin automates the process of converting the database agnostic logical model into a database specific (such as Oracle, SQL server, etc.) model. This database specific model is known as the physical model by database designers and as a PSM in MDA lingo. As I mentioned earlier, the process of converting a PIM into a PSM is called transformation. Finally, ErWin can be used to generate the SQL code (DDL) to create the database structure (tables, views, indexes, triggers, etc.) for the targeted database. Based on the definition of MDA and the capabilities offered by the tool, ErWin is an MDA tool. In this case the modeling language is the well defined E/R diagramming notation. So there is no doubt that MDA tools are possible. However, there are several hurdles to overcome before such tools become mainstream for general purpose software development, and especially for custom development. Two such hurdles include:
In my opinion, MDA tools, even with their existing limitations, have a definite place in any architect’s toolbox. But then, everything can be taken to an extreme and the same applies to MDA, which is not without its associated hypes. Here are the two most common ones that I encounter:
|
| Top |
| Service Oriented Architecture |
| Welcome to my first monthly installment of the blog on Java Design and Architecture that will focus on principals for good design, explore design patterns as they apply in Java (and in general), drill down into “buzzwords”, and much more. Service-oriented Architecture I was in a quandary about what my first blog should be ever since JavaWorld approached me with the idea of a Java Design blog. It was a few days later as I was talking with a good friend of mine (after a couple of sets of some rigorous tennis) that he happened to describe the architecture of a product that he works on at his job. Without really thinking, I blurted out “Oh, it’s a service-oriented architecture”. As it turns out, it was not, which is when the idea of writing about the term service-oriented architecture came to mind. Thanks, Kurt. The phrase “Service-oriented Architecture” is probably by far one of the most used and abused buzzwords today. It is abused not because people don’t know what the term means, but because they are too generous in its application. Although this may seem paradoxical, as you’ll see in a moment, it’s really not so. First, let’s define a service-oriented architecture or SOA as it’s commonly abbreviated and referred to in conversation and literature. In its simplest form, an SOA is any architecture that can, at least on a logical level, be decomposed into three categories of components: a service, a provider of the service, and a consumer of the service. Here’s the catch: almost any software application with a basic level of object orientation can be described in such a way, even if the designer of the application had never heard of SOA! The problem with this definition is that it is too vague and does not imply any level of sophistication in the application [architecture]. So how do you know if an architecture that appears to be an SOA actually is an SOA? Here are four litmus tests that I typically use:
|
| Top |