Wrap a Java Applet as a custom LightSwitch control

Here is a brief video tutorial of how to write a custom LightSwitch control, that supports data binding and displays a chemical structure.

Microsoft Lightswitch and non-Microsoft database

I have been playing around with LightSwitch recently. It works well with ad-hoc database or Microsoft SQL Server. Because we have mostly Oracle as DBMS, that was the first question that I was occupied with, how do I connect it with some other than Microsoft DB?
Well, theoretically there should be two ways to connect to non-MS databases:

• build a WCF RIA services interface. This approach brings a bit more complexity in the system landscape and weakens the RAD benefits
• the second one - LightSwitch supports db providers compatible with the entity framework.

I knew three entity framework providers for Oracle:

• DevArt dotConnect for Oracle
• Progress ADO.NET Data Provider
• and Oracle ADO.NET for entity framework that is still in beta

Progress Software product failed during runtime on showing data. Even after several contact with the customer support and advices from developer team no success on getting it running.

With DevArt dotConnect data could be displayed, but there is no possibility to edit it, so the access is read-only. It must have something to do with transactions handled by the LightSwitch. Digging deeper and trying to customize transaction handling did not bring any positive results.

Recently came out the second beta of Oracle ADO.NET for entity framework, which would actually have been my first test candidate, but the first beta caused my Visual Studio to crash. Nevertheless after successful installation of the ODP.NET beta 2, which is now compatible with the Visual Studio 2010 SP1, the edit buttons in my test LightSwitch application got enabled. A minor tweak is required on the transaction handling and it works as it should! These are the changes required on the data class:

using System.Transactions;  
//  ...  
public partial class MyData_ODPNETService  
{  
     private TransactionScope _tscope;  
     partial void SaveChanges_Executing()  
     {  
          _tscope = new TransactionScope(TransactionScopeOption.Required,  
          new TransactionOptions { IsolationLevel = System.Transactions.IsolationLevel.ReadCommitted });  
     }  
     partial void SaveChanges_Executed()  
     {  
          _tscope.Complete();  
          _tscope.Dispose();  
     }  
}  

Microsoft LightSwitch: back to RAD?

After an announcement about availability of the beta 2 of Microsoft LightSwitch Addon for Visual Studio, I decided to take a closer look at this new approach.

Microsoft goes for RAD? But yes, why not. The MS guys are obviously try to follow the trend, that software developing is with years becoming less about just writing code. After watching a 1,5 minutes video about LightSwtich on YouTube, where a ready application evolves: small, with database behind, data binding, table relations and simple, but cute UI, I was very intrigued.

I found 2 things also very interesting: the 1st, is that deployment model can be selected on compiling: desktop or web, the 2nd is that a clicked together application can be extended with C# code.

I think I'll give it a chance and try to find out, in which business scenarios this approach might be appropriate in terms of time-to-market, flexibility and maintainability of such applications.

The video, where the application is being clicked together within 1,5 min can be watched here:

Use .NET Controls in Delphi VCL Application

In the last couple of days I was occupied with a at the fist glance trivial task. I had to evaluate a possibility of using a .NET control for presentation of chemical formulas in Delphi. "So what's the matter, there is a .NET import wizard in Delphi" was my first thought. That would have been very easy, almost unbelievable, if worked at first attempt. The problem was, that the assembly was not compiled COM visible and thus not usable in Delphi. So here are the steps I had to make to achieve the desired result:

• Wrap the assembly to make it COM visible. Create a new Windows Forms Control LibraryVisual Studio. You get a default UserControl1 class automatically created. Inherit in this class from the control you have to wrap. Now add following attributes to your class (guid and progid are your custom values):

[ComVisible(true)]
[Guid("f5df04c4-2bdf-4e5c-ba0d-c3464eabf9be")]
[ProgId("WindowsFormsControlLibrary1.UserControl1")]

• Add register / unregister functions. Here comes a bit of magic. You have to expose your controls to COM and register them. Otherwise you'll get a Component in Delphi and not a visual Control you expect. Add these two methods RegisterClass and UnregisterClass to your class:

/// 

/// Register the class as a control and set it's CodeBase entry
/// 
///
/// The registry key of the control

[ComRegisterFunction()]
public static void RegisterClass(string key)
{
     // Strip off HKEY_CLASSES_ROOT\ from the passed key as I don't need it
     StringBuilder sb = new StringBuilder(key);
     sb.Replace(@"HKEY_CLASSES_ROOT\", "");

     // Open the CLSID{guid} key for write access
     RegistryKey k = Registry.ClassesRoot.OpenSubKey(sb.ToString(), true);

     // And create the 'Control' key - this allows it to show up in
     // the ActiveX control container
     RegistryKey ctrl = k.CreateSubKey("Control");
     ctrl.Close();

     // Next create the CodeBase entry - needed if not string named and GACced.
     RegistryKey inprocServer32 = k.OpenSubKey("InprocServer32", true);
     inprocServer32.SetValue("CodeBase", Assembly.GetExecutingAssembly().CodeBase);
     inprocServer32.Close();

     // Finally close the main key
     k.Close();
}

/// 
/// 

/// Called to unregister the control
/// 
///
/// Tke registry key        

[ComUnregisterFunction()]
public static void UnregisterClass(string key)
{
     StringBuilder sb = new StringBuilder(key);
     sb.Replace(@"HKEY_CLASSES_ROOT\", "");

     // Open HKCR\CLSID{guid} for write access
     RegistryKey k = Registry.ClassesRoot.OpenSubKey(sb.ToString(), true);

     // Delete the 'Control' key, but don't throw an exception if it does not exist
     k.DeleteSubKey("Control", false);

     // Next open up InprocServer32
     RegistryKey inprocServer32 = k.OpenSubKey("InprocServer32", true);

     // And delete the CodeBase key, again not throwing if missing
     k.DeleteSubKey("CodeBase", false);

     // Finally close the main key
     k.Close();
}

I found these methods in Embarcadero forum: https://forums.embarcadero.com/thread.jspa?threadID=14363

• Do not forget to set the COM visibility for your assembly in the project properties:

• Compile... Now you can Import the Assembly via the Delphi Import Wizard and install the Components in a Delphi package.

Events were exposed automatically. To expose the properties additional work is required, like defining an interface and set the DispId attributes (s. the Embarcadero forum link above for more details)

Build MSDN Help with FinalBuilder and Sandcastle

We are using FinalBuilder as continuous integration platform developing our in-house application framework. Documentation was built with Sandcastle. A Sandcastle Help File Builder project was executed in FinalBuilder as "Run DOC Command / Batch File" action with specific parameters defining build options.
But that was not very nice in regard to that FinalBuilder has specially designed actions to support Sandcastle, BuildAssembler, MRefBuilder, XslTransform:

So far so good, but believe me, that is not what you want. First you have to know how Sandcastle ticks internally, what xslt transformations are necessary for what help types and so on. Secondly, the whole procedure is complex and very error prone. There several xslt transformations are necessary to achieve the desired result. Take a look at this tutorial and you'll know what I mean.
Recently I discovered that GUI client for Sandcastle, which is Sandcastle Help File Builder, also available on the Codeplex, moved to a standard MSBuild format project file. That means to us developers, we can use it in a standard MSBuild action provided in the FinalBuilder. The benefits are obvious:

• you can use Sandcastle Help File Builder to define and manage your project

• use only one action to build your MSDN 1 or 2 or HTML help

• easily forward FinalBuilder properties like help file format or output path to SCHB

I'm not eager to tell here how I'm impressed by the FinalBuilder. Being long time a devoted user of Ant, now I know what a build tool must look like. It's very comfortable to handle, has plenty of actions for almost every imaginable developer task and if not enables you to extend it with your own actions and it just works as it should.
The only drawback of building help in the FinalBuilder, it takes much longer then to get the project built directly in the SCHB, but on the other hand you get a couple more minutes for a cup of good coffee.

Upgrading our framework from JSF 1.1 to JSF 1.2

It's been a while since the last post. I'm currently working on upgrading our in-house JSF framework to support JSF specification 1.2

The basic plan was to update the project and freeze the old branch based on JSF 1.1

In course of adaptation the difference between JSF 1.1 and 1.2 turned out to be not as immense as we expected it to be. So the solution is as simple as that.

• On initialization we check what JSF version is used in a project
• According to the currently used JSF version specific classes are loaded via reflection
• As a result our JSF Framework supports both 1.1 and 1.2, so there is no need to make adaptations to applications using it (and everybody is happy)
  

The major differences between 1.1 and 1.2 that we had to confront with:

• JSF 1.2 is based on JSP 2.0 whereas JSF 1.1 uses JSP 1.2
• Migrating to JSF 1.2 means, one has to move the application to the newer Tomcat 6.0 (if e.g. currently using Tomcat 5.5)
• JSF 1.2 uses EL Resolver to resolve variables binding

Now we are planning an extended integration test to be sure the running applications will survive this upgrade. But I have a good feeling about it.

... migrating from ACEGI to Spring Security

this piece of work is done by now. Here are my experiences so far. In most cases one can take Spring Security and use it as given. There are plenty of providers and mechanisms, that are supported (like LDAP, JAAS, CAS, digest, form authentication etc.) and would fulfil one's needs in 90% of cases. When it gets tough? Like in our case, when you e.g. would like to use some custom security providers or load access definitions from a file, describing your access rules in some other way.

Back again to a normal case... The new feature presented in Spring Security is a new configuration syntax, which allows you to skip defining all the beans in a Spring manner. A minimal configuration looks like:

Code...

<http config="true">
<intercept-url pattern="/**" access="ROLE_USER"/>
</http>

Looks fine doesn't it? Than you have to specify an authentication provider to map a user with a valid password to the roles. And that's it. So what is when you'd like to override some filter in the filter chain? Or to define a custom ports mapping for HTTP and HTTPS? Or would like to use a custom JSF login page? I'll tell you. You end very soon by good old ACEGI Security configuration syntax with beans.

There was one issues that posed special degree of difficulty: how do I configure a custom JSF login page using Spring Security authentication mechanism without having to reimplement the whole authentication logic? The solution is to use Spring Security j_spring_security_check.jsp as a filter process URL and correctly map the username and password fields to be forwarded as request parameters. It looks something like this:

Code...

<beans:bean id="authenticationProcessingFilter" class="org.springframework.security.ui.webapp.AuthenticationProcessingFilter">
<beans:property name="filterProcessesUrl">
<beans:value>/j_spring_security_check.jsp</beans:value>
<beans:property>
<!-- very important: use here the ids of your login form as values to get the credentials passed to spring securty authentication processing servlet -->
<beans:property name="usernameParameter">
<beans:value>login_form:username</beans:value>
</beans:property>
<beans:property name="passwordParameter">
<beans:value>login_form:password</beans:value>
</beans:property>
<beans:property name="authenticationFailureUrl">
<beans:value>/login.jsf</beans:value>
</beans:property>
<beans:property name="defaultTargetUrl">
<beans:value>/home.jsf</beans:value>
</beans:property>
<beans:property name="authenticationManager">
<beans:ref bean="authenticationManager"/>
</beans:property>
</beans:bean>

It will only work in connection with the login JSF designed as follows:
Code...

<h:form id="login_form">
...
<h:inputText value="#{loginView.userName}" id="username" required="true"/>
<h:inputSecret value="#{loginView.password}" id="password" required="true"/>
...

and not to forget the navigation rule in the faces config:
Code...

<navigation-rule>
<from-view-id>/login.jsp</from-view-id>
<navigation-case>
<from-outcome>login</from-outcome>
<to-view-id>/j_spring_security_check.jsp</to-view-id>
</navigation-case>
</navigation-rule>

and the last point - the JSF backing bean to map username and password input from the login page, which is defined as a managed bean in faces config:

Code...

<managed-bean>
<managed-bean-name>loginView</managed-bean-name>
<managed-bean-class>
myapp.beans.view.LoginView
</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>

The java class LoginView contains only getter and setter for username and password and an exception handler to forward a failed login message from JSF to Spring:

Code...

import javax.faces.application.FacesMessage;
import javax.faces.context.FacesContext;
import org.springframework.security.ui.AbstractProcessingFilter;

public class LoginView {
private String userName;
private String password;

public LoginView() {

try {
Exception ex = (Exception) FacesContext
.getCurrentInstance()
.getExternalContext()
.getSessionMap()
.get(AbstractProcessingFilter.SPRING_SECURITY_LAST_EXCEPTION_KEY);
if (ex != null) {
FacesContext.getCurrentInstance().addMessage(null,
new FacesMessage(FacesMessage.SEVERITY_ERROR,
ex.getMessage(),
ex.getMessage()));
}
} catch (NullPointerException ex) {
// if no faces context present, e.g. when called from a unit test
}
}

public String getPassword() {
return password;
}

public void setPassword(String aPassword) {
password = aPassword;
}

public String getUserName() {
return userName;
}

public void setUserName(String aUserName) {
userName = aUserName;
}
}

Another interesting topic is localization. How to get localized login error messages displayed if locale is managed in JSF. I'll write on it some other time...

Still working on...

migrating to Spring Security in a JSF application. There seems to be a way. Going deep into Spring code and debug crazily helps to get understanding what's going on there. I'll post some more info, tricks and important details as soon as I have the complete solution. But I'm very optimistic now !

Currently working on...

migrating our application framework from Acegi to Spring Security. It sounds like a pretty easy task. It is really so as long as you go along with the standard set of security features contained in Spring Security, which is very extensive. So that in 90% of cases you would take it out of the box, configure & use. But if you have some existing peculiarities in your software landscape, that you would like to integrate, that's where it gets tough.

We for example use a web service for user authentication and authorization and had to implement our specific provider to plug it into the framework. Moreover it surprised me that there is still no reasonable JSF support in Spring Security. My idea was to use it in a JSF application and possibly write no authentication specific code. What I was hoping on, was to supply my own WS authentication provider, configure the Spring and/or JSF beans and it should work. But the truth is, actually there is no way around as to use a backing bean with authentication logic. This solution is presented here in Java World Magazine. It is a good and working one, but I wish it were simplier.

What Spring guys actually promise and underline as a highlight of Spring Security comparing with Acegi is less configuration and easy understanding. As matter of fact the main issue here is interaction between Spring Security and JSF and a question how to configure it without need to write the whole authentication / authorization logic in Java, but just to get it configured somehow.

So should you've run into an appropriate solution, please be so kind and drop a line here ...

OOP 2008 lectures

As I promised recently, I'm going to share a couple of thoughts concerning the lectures I had pleasure (mostly) to attended during OOP 2008.

• Model driven development for embedded systems with Eclipse

It was a whole day workshop, where we tried MDSD principles with Eclipse for embedded devices. It had a lot of fun, but it had no real relevancy to my daily work.

• SOA@T-Mobile

4 guys from T-Mobile spoke about implementing a world-wide SOA solution at T-Mobile. Here are some interesting facts. Technically, they took TIBCO products as ESB. Web Services developed in Java and used Oracle BPEL Process Manager from the Oracle Fusion Middleware as a BPEL engine (an were very impressed by it). Unfortunately they told very little about Governance, which is a crucial topic in SOA. After my questions I have learned that the decision to switch to SOA was adopted by top management and pure guys had first to struggle about it. But my personal feeling is it is a happy story and they are on the good way (with top management support I would not expect other result).

• Common Sense over Conservatism – is Ruby on Rails ready for the enterprise?

The speaker (pretty smart) tried for 3/4 h to answer this question without slides. It was tough. He rephrased the question like "is an enterprise ready for Ruby?". And answered both questions in the affirmative. My personal opinion, I won't use it. The pros to adopt another programming language are not persuasive enough to me. Maybe it's a good (even the best) scripting language, but it's still a scripting language - nothing for real enterprise developers.

• MDSD und SOA und BPM – how does it match?

For me it does not match even after attending this lecture. It was not really enjoyable.

• Model driven product line engineering
• Spring or EJB 3.0 - two light weights in comparison
• REST: the architecture of the Web as a basis for SOA

REST is in any case worth a glance. I think it's a very interesting technology, well not really a technology, but rather a way to organize information resources. What REST is can be found in Wikipedia: http://en.wikipedia.org/wiki/REST. The speaker tried the whole time to oppose REST to Web Services. Throw away the WS and take REST and the world will get better. I have to disagree at this point. As for me REST has some real handicaps in comparison with WS. Speaking of WS as pure RPC calls, maybe yes, there is too much overhead like WSDL, UDDI, etc. But all emerging supplementary WS-* technologies like transactions, security, reliability, collaboration, etc. is something, that REST does not provide. And there is no clear contract between provider and consumer like with WS. REST simplicity and transparency, that even a child could understand its principles is very impressive. But I think technologically SOA with WS much more progressive and seminal.

• Case Study: The New Guardian.co.uk

For those who want to know - yes it's Java with a broad open source software stack, like Spring, Hibernate and Velocity. It was developed in Jetty and deployed in Resin.

• Panel: what comes after SOA?
• OSGi: Universal Middleware
• Building and consuming RESTful JSON services with Apache CXF and Google Web Toolkit

It was a basic tutorial how to build WS, that can be consumed by Google gadgets - not something really interesting for the enterprise, but rather for hobby developers. (what I also do :-)

• Better software due to AOP
• Java multi threading with multi core CPUs

The core of this lecture are new features in Java 1.5, which were forced in background by generics and co. It's worth to take a look at it for those, who want to benefit from multi core functionality of the new CPUs. Here just a couple of keywords to this topic: JSR 166, java.util.concurrency package.