Thursday, January 31, 2008

Silverlight 2.0 is coming


Silverlight 2.0 is coming. It' s originally called Silverlight 1.1. I don't why they changed the name into 2.0. rrr....


The cool thing in Silverlight 2.0 is :
  • Include CLR as .Net Framework 3.0 (so you can use code behind in Vb.net / C#
    Base Class Library (BCL) provides classes for collections, reflection, regex, string handling, data access

  • Dynamic Language runtime in media files
    The first available languages written for the DLR are Iron Python 2.0 and Managed JScript.
    Microsoft is also building Iron Ruby and Dynamic Visual Basic (VBx) languages.

    Conversely, other .NET languages must be compiled ahead of time and delivered to Silverlight as .NET assemblies. The implementation of Managed JScript conforms to the ECMA Script 3.0 specification, and Microsoft claims that it is 250 times faster than interpreted JScript.
    http://weblogs.asp.net/scottgu/archive/2007/05/07/silverlight.

  • Extensible controls
  • XML Web Services - Data access over XML-based Web Service and WCF ( POX, REST, JSON )
  • Networking
  • LINQ API ( full support for LINQ to Objects and Expression Trees)
  • WPF model (Shapes, document, media and animation objects)
Limitation:

The current release, the UI controls do not have support for databinding to any data source. But, Microsoft has clarified that the limitations are due to this being an early preview release. Future releases will add more than 20 UI controls add two-way databinding support, and automated layout management as well as data manipulation controls such as data grid.
http://blogs.msdn.com/somasegar/archive/2007/11/29/quick-update-on-silverlight.aspx

Wednesday, January 30, 2008

Deferred Execution in LINQ

To boost the performance in Linq deferred execution, Linq has provided a nice method
called ToArray() and ToList()

By using those method, you just need to execute query into database once and iterate locally through your array or list.

Hibrenate - Lazy Initialization (could not initialize proxy - the owning session was closed)

Hibernate object relational mapping offers both lazy and non-lazy modes of object initialization. Non-lazy initialization retrieves an object and all of its related objects at load time. This can result in hundreds if not thousands of select statements when retrieving one entity. The problem is compounded when bi-directional relationships are used, often causing entire databases to be loaded during the initial request. Of course one could tediously examine each object relationship and manually remove those most costly, but in the end, we may be losing the ease of use benefit sought in using the ORM tool.


Hibernate proxies can be very handy if you have performance concerns, the idea is to load the objects lazily as proxies and never hit the database. The proxies are initialized meaning fetched from the database when they are first accessed, however life is not so easy:) Whether there is a configured filter-interceptor of spring to manage hibernate sessions or you manually take care of the session’s life cycle, once the session was closed, the proxies attached to that will lead to a proxy initialization error if they are accessed later.

The reason is tricky, a hibernate session is created and some data is loaded to the session as a proxy, later the session is closed without an access to the proxy occurred. Then proxy is decided to be used and accessed, at this point one may get the error “no session or session was closed” since the session which the proxy is attached is “closed”. In order to deal with this situation there are some solutions.

1) Reloading the proxy “before” using it in the new session, this will attach the new proxy to the new session.

2) Using static method Hibernate.initialize(obj) before the owning session was closed, this will hit the db and replace the proxy with the actual data.

3) Using a Session lock via Session.lock(obj,lockmode), this will reattach the proxy to the new session.

4) Or you just disable lazy initialization mode by mark the flag into false (lazy=false)

As you see this proxy business isn’t simple as it seems but I belive once you learn how to use them they are the best way to optimize the performance.In the end who has not the need for speed?

Monday, January 7, 2008

Abstract VS Interface

multiple inheritance
INTERFACE-A class may implement several interfaces.
ABSTRACT-A class may extend only one abstract class.

default implementation
INTERFACE- cannot provide any code at all, much less default code.
ABSTRACT- can provide complete code, default code, and/or just stubs that have to be overridden.

is-a vs -able or can-do
INTERFACE- are often used to describe the peripheral abilities of a class, not its central identity, e.g. an Automobile class might implement the Recyclable interface, which could apply to many otherwise totally unrelated objects.
ABSTRACT-defines the core identity of its descendants. If you defined a Dog abstract class then Datamation descendants are Dogs, they are not merely dog able. Implemented interfaces enumerate the general things a class can do, not the things a class is.

plug-in
INTERFACE- You can write a new replacement module for an interface that contains not one stick of code in common with the existing implementations. When you implement the interface, you start from scratch without any default implementation. You have to obtain your tools from other classes; nothing comes with the interface other than a few constants. This gives you freedom to implement a radically different internal design.
ABSTRACT-You must use the abstract class as-is for the code base, with all its attendant baggage, good or bad. The abstract class author has imposed structure on you. Depending on the cleverness of the author of the abstract class, this may be good or bad.

homogeneity
INTERFACE- If all the various implementations share is the method signatures, then an interface works best.
ABSTRACT-If the various implementations are all of a kind and share a common status and behaviour, usually an abstract class works best. Another issue that’s important is what I call "heterogeneous vs. homogeneous." If implementors/subclasses are homogeneous, tend towards an abstract base class. If they are heterogeneous, use an interface. (Now all I have to do is come up with a good definition of hetero/homo-generous in this context.) If the various objects are all of-a-kind, and share a common state and behavior, then tend towards a common base class. If all they share is a set of method signatures, then tend towards an interface.

maintenance
INTERFACE- If your client code talks only in terms of an interface, you can easily change the concrete implementation behind it, using a factory method.
ABSTRACT- Just like an interface, if your client code talks only in terms of an abstract class, you can easily change the concrete implementation behind it, using a factory method.

adding functionality
INTERFACE- If you add a new method to an interface, you must track down all implementations of that interface in the universe and provide them with a concrete implementation of that method.
ABSTRACT- If you add a new method to an abstract class, you have the option of providing a default implementation of it. Then all existing code will continue to work without change.

Thursday, January 3, 2008

JBOSS for .Net Issue (505)

JBOSS has known issue when talking to .NET Client.

You will receive this error.
The request failed with HTTP status 505: HTTP Version Not Supported.


This error happened because .NET does not implement HTTP 1.1 properly (specifically contiuations), therefore the only way you can fix this is to force the client to use HTTP 1.0.

You can enable in on Server Side / Client side.

On Server Side:
adding the following option (in bold) to your http connector tag in your tomcat server.xml file.
Connector port="8080" address="${jboss.bind.address}"
maxThreads="250" strategy="ms" maxHttpHeaderSize="8192"
emptySessionPath="true"
enableLookups="false" redirectPort="8443" acceptCount="100"
restrictedUserAgents="^.*MS Web Services Client Protocol.*$"
connectionTimeout="20000" disableUploadTimeout="true"

On Client Side:
Change .NET webservice to use HTTP 1.0 by adding the following code to your proxy class.
 protected override System.Net.WebRequest GetWebRequest(Uri uri)
{
HttpWebRequest httpReq = (HttpWebRequest)base.GetWebRequest(uri);
httpReq.ProtocolVersion = System.Net.HttpVersion.Version10;
return httpReq;
}


Debugging into System Code

I just find that we can not debug into system generated code because by default "Just My Code" is enabled.....

To be able to debug a system generated code such as proxy/wsdl... you need to disable "Just My Code" inside debugging options.

Steps:
* Tool>Options>Debugging>General
* Untick Enable Just My Code (Managed Only)....