ASP.NET 4.0 and its confliects with ASP.NET 2.0
Wednesday, June 17, 2009
Monday, June 15, 2009
J2EE Design patterns Part 1
Any enterprise application is divided into tiers
1- Client presentation tier.
2- Server-side presentation tier.
3- Server-side business logic tier.
4- Sever-side domain model.
5-
The first three tiers are defined in java by sun, but you can the last two tiers according to your application.
The client presentation tier is the user interface for the end user, the client can be either thin of fat client. This tier can be implemented using HTML and JavaScript.
As you noticed presentation tier are divided into two tiers, the server-side and client presentation tier. The server-side presentation tier is responsible to provide client presentation tier with materials to be shown to end user. The server-side presentation tier can be Servlets and JSPs.
While considering the verbs of the system (e.g. purchase, remove, ….,etc ), you have to mention the server-side business logic tier. It handles the business logic of the system.
The extra two tier are server-side domain model which handles all the models used by the business logic. In this tier we consider nouns in system (e.g. Order, Customer, ….,etc ). The final tier is the enterprise integration tier which handle connection between your system and other systems (e.g. web services, CORBA,…. , etc ).
When evaluating the end product of any enterprise development project, we can score it on four factors: Extensibility, Scalability, Reliability, and Timeliness. Using design patterns increases the score of the project.
Patterns will be divided according to the mentioned tiers, starting with presentation tier where most of the changes occurs. These patterns make presentation tier more extensible
A- Model-View-Controller Pattern.
Dividing the application to javaBeans and jsp and servlets. JavaBeans will show the data from the business logic to view. JSP will view the data. Servlet for navigations between views.
We have two models in MVC pattern , the first model is making a controller (servlet) for each view but it`s not the best practice, because if you need to add a logging mechanism it will cost you time and effort to handle it in all controllers. The second approach is making one controller to dispatch the requests to each service, also this approach isn`t the best practice because if you want to add new feature you will need to retest and redeploy,…etc.
B- Front Controller pattern.
Front controller merges MVC models, by using one front controller that perform the common functions and delegate other specific functions to a page-specific controller. Front controller is also responsible of redirecting to pages. The page specific controller can be Servlets or simple classes that is based on the GOF command pattern. Good example is the Actions in the Struts framework, classes that have common parent class and each class perform page specific functionalities. In the front controller you can add common functionalities so that you won`t have duplicate functions in page specific controllers. Adding common functionalities in front control can be applied using the GOF decorator pattern so that you can extent functionalities dynamically.
Wednesday, June 10, 2009
Optimizing Hibernate Usage
Well, getting straight to the point, using hibernate is totally different from effectively using it. You can set up and put hibernate in action very fast in your application and enjoy ORM features, however, as any project grows and expands by time, you may find that the application is acting slow and with overhead on the DBMS, most people - (mostly seniors and architects :D) - just blame hibernate for being inefficient and tend to prove that the ORM concept itself is wrong and hibernate is just saving some JDBC code with a great performance tradeoff. This article aims at helping you to know how you can optimize the usage of hibernate to minimize performance penalty. we suppose you already have some experience with basic usage of hibernate by the way, so if you are an absolute beginner this is not for you.
Before we proceed, there are two rules that we need to stress on:
1- Using hibernate does not completely isolate the developer from that database, the relational model is still involved.
2- Hibernate is not some sort of magic, it can not predict what you want, it will do what you configured it to do.
===== Basic Principles =====
99% of problems faced with hibernate is due to misconfiguration or misunderstanding, both reasons are the common two reasons when dealing with any framework that abstracts details behind the scenes. In order to start effectively using hibernate, we need to talk about the following terms:
1- Session.
2- Object state.
3- Transaction.
4- Locking.
5- Caching.
6- Connection Pooling.
Session: A session object in hibernate is that place created to store and manage objects and their states in memory, it can be considered as a cache, in other words, it is the heart of communication between your business model and the relational model represented by the DBMS. When you retrieve an object from the DB it is stored in the session, when you update that object and call session.save(object) the session manages to synchronize the data in the data base with the one in the session in object. A session's life ends once the thread which created it is killed, so, when a web user requests a web page which needs to contact the DB, the thread that was initiated to handle the HTTP request will create the session to be used as long as the thread is alive, once the HTTP request is done and the thread is killed the session object is killed too.
When you retrieve an object, hibernate checks if the object is in the session first, if not, it gets it from the DB and saves it in the session object for further requests.
Object State: The word "state" here means how hibernate sees an object from the session perspective, an object has one of 3 states:
1- Transient : The object is still not saved in the DB.
2- Persistent : The object has already been saved to the DB and hibernate session can manage it.
3- Detached : The object has an entry in the DB, but the session that saved or retrieved it has been closed, so the object now has no associated session to manage it.
A developer needs to keep in mind the states of objects, because this can lead to many problems if not handled correctly, for example; a user requested a web page which loaded an object from the DB, that object will be updated by the client, however, the client took too long to perform that update, after he submitted the page again, the business logic simply calls session.update(object), but, a problem is there. The problem is because the hibernate session which retrieved the object in the first place has been closed, so the object is now detached, and can not be updated until it is re-attached to a hibernate session again. There are many solutions for this problem, we might look at later.
Transaction: A transaction with the terminology of hibernate is any kind of operations taking place between the application and the database, do not mix this with the atomic data base transactions. A transaction in hibernate is any data manipulation operations; when u need to reflect any thing to the database you need to put your code within begin Transaction and commit calls.
Locking: When a DB record is accessed by many threads, we need to manage the way these threads are dealing with the DB, a typical situation is where a thread reads a certain value and before it updates it another thread has already put another value, so, the information now being processed by thread one is considered invalid. Locking is the mechanism which decides the action taken by the DB when some records are being read. One solution for the previously mentioned problem is to tell the DBMS not to permit any updates for a certain record while a thread is reading it and intending to update it. There are different locking mechanisms for different situations. Hibernate can manage locking for objects on the DB level, that means that hibernate never locks an object in memory - ( in other words; the session) - so, always take care that hibernate only supports a certain locking mechanism if the underlying DBMS supports it.
Caching: Caching is a way to save extra hits to the database to retrieve info, a cache saves information in memory for fast retrieval and a cache is also responsible for maintaining that the data stored in the cache is valid and synchronized with the DB. Caching in hibernate takes place at 2 levels:
1- First level cache: Which is the session object, however, as we said before, a session is valid as long as the thread that initially created it is running, so, it is a caching layer per-thread. This caching can not be disabled, you can not manage to disable the caching in the hibernate session by any means.
2- Second level cache: Which can be any caching manager, ex; ehcache. A second level cache is a caching for the application, it is not tied to a specific thread, as long as the application is running, this cache will be used, if you use a second level cache and try to retrieve an object from the DB Hibernate will first check the first level cache (Session) if it does not find it, or finds it invalid, the first level cache will check with the second level one, if it does not find it, the second level cache will manage to get a fresh copy from the DB and saves it for further uses.
Using of second level caching needs caution, objects on the second level chache may not be in some cases synchronized with the DB or the first level cache, there are some types of applications the can not use second level caching by any means,like; financial applications.
Connection Pooling: Like any pool, this is a pool containing some open connections to the DB. Pooling techniques serve performance by keeping it fast and reliable to talk to the DB without the overhead of always opening and closing connection, also, a connection pool may control the number of open connections to a DB so no overload occurs. Hibernate offers a connection pooling provider "C3p0", however, you can use any other pooling mechanism.
===Approaches to optimizing hibernate===
We will now try to define a roadmap to how you can start the process of optimization, sure we can not give or describe all problems and techniques, however, we try to provide your first steps towards optimization.
Some Advices:
1- Never try to start optimizing an application using hibernate from day zero, you will never be able to effectively tune it, wait until you have an application running and then manage to optimize.
2- A use of a load testing tool along with a profiling one may help a lot in determining bottle necks and bad written code.
3- Tuning requires a lot of team work effort and time, it is not always hibernate that is the cause of bad behavior, it may be from the DB, Java itself, network or server issues.
4- Review & fix your object model design for the application as it direclty affects your relational model, many problems arise from bad object models, the more you enhance your object model, the more you save your self a lot of trouble in the optimization process.
5- Configure hibernate to write the queries generated on the standard output, this will help you very much in tracing problems.
6- The ultimate solution for your problems is not here, every problem has its specific solution, you have to explore alternatives to decide what to use, there is nothing totally right or totally wrong.
===== Lets Go ======
1- It all starts from mapping:
As a hibernate developer, you must have a good knowledge about the ".hbm" files even if you use a generation tool. Mapping is a critical section, as a wrong or a bad mapped object may result in an unwanted heavy behavior. Make sure you define relations between objects in the right way, the tags you write in mappings defines how hibernate will build queries to retrieve and save your objects.
Hint 1: When mapping a one-to-one relations, its very effective to use the "constrained=true" attribute if you are sure that there is a record matching the foreign key association, this way, hibernate will not attempt a lookup first before selecting the records, it will direclty go and pick up the record as it previously knows of its existence.
Hint 2: Revisit your fetching strategy for objects, the "fetch" attribute tells hibernate how to retrieve a certain relation, it has many options. You may need to tell hibernate to use a certain type of join for a specific object, or a sub-select for another, that depends on the situation.
2- Queries:
Your queries may be the source of the problem, you may override an association strategy defined in the mapping file and then wonder why it is going wrong!!. Using SQL, HQL, or Criteria API are all valid options for object retrieval. Criteria API just gets translated to HQL before execution, so, using HQL is slightly better in terms of performance. Using SQL is needed at some cases when HQL lacks a certain feature for a specific DBMS.
Using query caching may be effective in cases where the application does not write too much to the DB, as caching a result set of a query become invalid if any update, delete or insert takes place at the DB table, you may enable query caching by setting
hibernate.cache.use_query_cache true
and use the setCacheable(true) of the query class before execution of a query.
Hint 1: Suppose a users logs in to your website, simply, you will hit the database to get the user profile object to compare the password supplied by the user, using a default hibernate get operation will retrieve the whole object graph which may include references to other objects and as a result a bad looking join SQL statement may be produced, at the end we have a heavy object in memory only for getting a simple string value. In situations like this, you need to specify a certain retrieval approach that just gets only the information you need to be added to the object built and returned for later use. You need to see how to use hibernate to build objects only of certain information.
3- Locking:
Ok, you used a load testing tool and booom.... a locking problem occurs, you find that your application messed up with the records, so, you decided to move to pessimistic locking, but, oops, the application is now having deadlocks. This problem mostly arise from the DBMS, as mentioned before; hibernate manages to use the provided locking mechanisms of the DBMS, no memory locking takes place, a problem like this may need a DBA to rightly configure the DBMS to work smoothly with your application to handle locking situations. From the hibernate side, you need to revisit your queries which needs to handle locking scenarios in your application, you need to pay attention whith writing such queries as those queries may mess up things if not written with caution. (See how to use locking with hibernate)
hint 1: A problem might take place if you lock some object for update and then not doing anything with the hibernate transaction initiated the lock. This can be solved by making sure that under any circumstances the transaction will either commit or rollback, this way, the lock will be released, another solution, is by setting the locking timeout of the DBMS itself, so a lock will be released after some time either the transaction issues any further action or not.
4- Connection Pooling:
As mentioned before, using connection pooling is a very good practice if used properly, beside configuring a pool manager, you need to pay your code a visit to make sure that there is a thread some where holding a connection open, this situation mostly found in a missing or a miss-placed connection close call. Optimizing the usage of a connection pool may need the advice of the DBA.
Tuesday, June 09, 2009
Happy BizTalk to you – part 2
Today I am going to explain the application integration options, by the way there's more than one approach for integrating applications, each approach addresses some of the integration criteria better than others. The variousapproaches can be summed up in four main integration styles: Wait !!!!!!!!! What are the integration criteria? What makes for good application integration? If integration needs were always the same, there would only be one integration style. Yet like any complex technological effort, application integration involves a range of considerations and consequences that should be taken into account for any integration opportunity. DO you want to know more click here ?
Introduction to XML
SGML: (Standard Generalized Markup Language) is Standard in which one can define markup languages for documents.
HTML : Hypertext Mark-up Language.
XML : Extensible Markup Language, is a markup language that you can use to create your own tags.
XML is created to overcome the limitations of the HTML. Although HTML is a very successful markup language, it is used to preview the data without understanding the data or even give the ability to analyze data.
So main advantages of XML is giving the ability to analyze data and search inside XML document. Also XML used for data interchange, organizations can exchange data in XML and then convert this data to database records easily.
XML document rules
1-Root element:
An XML document must be contained in a single element. That single element is called the root element, and it contains all the text and any other elements in the document.
2- Elements cannot overlap:
If you started element and inside this element you must close first then close
3- End tags are required
Each element must have an end tag.
4- Elements are case sensitive
5-Attributes must have quoted values
• Attributes must have values.
• Those values must be enclosed within quotation marks.
You can use a predefined structure using the document type definition (DTD).
DTD defines the elements the can appear in XML file and the order if the elements. Another approach for using predefined structures is XML schemas.
XML Programming Interfaces
This section focus on the programming interfaces to deal with XML document.
There is a lot of programming APIs Available. Here we have the most popular APIs; Document Object Model (DOM), the Simple API for XML (SAX), JDOM, and the Java API for XML Parsing (JAXP).
- Document Object Model (DOM):
Defines a set of interfaces to the parsed version of an XML document. The parser reads in the entire document and builds an in-memory tree, so your code can then use the DOM interfaces to manipulate the tree. You can move through the tree to see what the original document contained, you can delete sections of the tree, you can rearrange the tree, add new branches, and so on.
DOM has some issues, building the whole XML document in the memory consumes time especially with large documents. What if I need a specific part from document? It doesn't make sense to load the entire document.
- Simple API for XML (SAX):
SAX handle a lot of DOM issues, SAX based on events. First you define which event is more important to you and the data type of the data from event, the parser goes throw the document and throw event at the start, end of the element or start , end of document. If you don`t save the data from the event it will be discarded. As you can see SAX doesn`t hold the entire document in the memory, so it saves time. But one of the SAX issues is that SAX is stateless.
- JDOM
Java classes developed to make it easier to use DOM and SAX parser. JDOM handle the DOM and SAX interfaces and gives high level classes to reduce the amount of code. JDOM make most of the parsing functionalities.
- Java API for XML Parsing (JAXP).
Although DOM, SAX, and JDOM provide standard interfaces for most common tasks, there are still several things they don't address. For example, the process of creating a DOMParser object in a Java program differs from one DOM parser to the next. To fix this problem, Sun has released JAXP, the Java API for XML Parsing. This API provides common interfaces for processing XML documents using DOM, SAX, and XSLT. JAXP provides interfaces such as the DocumentBuilderFactory and the DocumentBuilder that provide a standard interface to different parsers. There are also methods that allow you to control whether the underlying parser is namespace-aware and whether it uses a DTD or schema to validate the XML document.
Community Calender
Or in iCal format that can be feed to Outlook or Apple iCal, etc :
Also, as XML feed:
The calendar will include offline IT community Events held around Egypt. Also, online events both from Egypt (hopefully there will be, someday :)) & around the world.
Monday, June 08, 2009
Handling Hibernate Session
Handling hibernate session is so important, and the way of handling the session reflects with the performance of the application.
You can handle the hibernate session per service. It means with each request for each service you will open new session, at the end of the service, you will close the session. In this approach you have to be sure that you don`t need the session again (lazy fetching for example ).
p.s) if lazy fetching is false it will affect the performance.
Another approach of handling session is session per view. When an HTTP request has to be handled, a new Session and database transaction will begin. Right before the response is send to the client, and after all the work has been done, the transaction will be committed, and the Session will be closed. In this approach you can user the Filter in servlets APIs . this approach is called session-per-conversation and used while implementing long conversations.
The third technique and the most recommended technique is using java transaction APIs. Hibernate can automatically bind the "current" Session to the current JTA transaction. This enables an easy implementation of the session-per-request strategy with the getCurrentSession() method on your SessionFactory:
try { UserTransaction tx = (UserTransaction)new InitialContext() .lookup("java:comp/UserTransaction"); tx.begin(); // Do some work factory.getCurrentSession().load(...); factory.getCurrentSession().persist(...); tx.commit();}catch (RuntimeException e) { tx.rollback(); throw e; // or display error message}Finally If you don't have JTA and don't want to deploy it along with your application, you will usually have to fall back to JDBC transaction. Instead of calling the JDBC API you better use Hibernate's Transaction and the built-in session-per-request functionality:
factory.getCurrentSession().beginTransaction();Tuesday, June 02, 2009
Happy BizTalk to you – Part 1
Welcome To machine! Today, I would like to introduce the series of Happy BizTalk to you; the idea behind these articles is to familiarize you with a set of design patterns in BizTalk orchestrations to simplify the programming process automatically. The plan is to get you some overview automatically, no additional effort required. When you're familiar with the design patterns of BizTalk, you can face a programming issue and — Bam! — A solution will come to you more quickly. Instead of banging your head against the wall in desperation, you'll say, "What I need here is the Splitter pattern Or the Aggregator pattern". Let's go
Monday, June 01, 2009
.NET Framework Posters (4 and 3.5)
While I am google for .NET Framework 3.5 Poster to see some new namespaces , I got .NET Framework 4 Poster so I want to share the both with you here.
.NET Framework 3.5 :
DotNet_poster_xps_large.xps 1.5 MB
DotNt_poster_xps_split.xps 1.8 MB
NET_35_Namespaces_Poster_JAN08.pdf 849 KB
NET35_Namespaces_Poster_Tiled_JAN08.pdf 25MB
All of them are available in this link
.NET Framework 4:
You can find in the next link two version for framework 4, the first is silverlight with deep zoom and the second is PDF high resolution version.
They are available in this link
