Adam Bien Java Blog

There is a common prejudice that JCA connectors have to be too complicated for day to day use. "Custom & lightweight" solutions are built instead, which are usually orders of magnitudes more complex, than a pragmatic JCA implementation. So, how to built one:

• JCA connectors are deployed as .rar archives with internal structure similar to ejb-jar archives. You can reuse your existing packaging and just change the ending from .jar to .rar
• Start with the ra.xml deployment descriptor. You "only" have to implement the elements listed in this deployment descriptor:

<connector xmlns="http://java.sun.com/xml/ns/j2ee"

           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

           xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee

           http://java.sun.com/xml/ns/j2ee/connector_1_5.xsd"

           version="1.5">

    <display-name>Generic JCA</display-name>

    <vendor-name>adam-bien.com</vendor-name>

    <eis-type>Generic JCA</eis-type>

    <resourceadapter-version>1.0</resourceadapter-version>

    <resourceadapter>

        <outbound-resourceadapter>

            <connection-definition>

                <managedconnectionfactory-class>...genericjca.GenericManagedConnectionFactory</managedconnectionfactory-class>

                <connectionfactory-interface>...genericjca.DataSource</connectionfactory-interface>

                <connectionfactory-impl-class>...genericjca.FileDataSource</connectionfactory-impl-class>

                <connection-interface>...genericjca.Connection</connection-interface>

                <connection-impl-class>...genericjca.FileConnection</connection-impl-class>

            </connection-definition>

            <transaction-support>LocalTransaction</transaction-support>

            <authentication-mechanism>

                <authentication-mechanism-type>BasicPassword</authentication-mechanism-type>

                <credential-interface>javax.resource.spi.security.PasswordCredential</credential-interface>

            </authentication-mechanism>

            <reauthentication-support>false</reauthentication-support>

        </outbound-resourceadapter>

    </resourceadapter>

</connector>

 

•  GenericManagedConnectionFactory and GenericManagedConnection are mostly reusable. These classes care about connection management. You will be able to manage a connector through e.g. the Glassfish admin console. The code is surprisingly simple - its mainly book keeping and logging. See  http://kenai.com/projects/javaee-patterns/, project GenericJCA.
• The "core" business logic resides in the FileConnection:
  

public class FileConnection implements Connection, LocalTransaction{

    private String buffer;

    private FileOutputStream fileOutputStream;

    private ConnectionRequestInfo connectionRequestInfo;

    public final static String FILE_NAME = "/temp/jcafile.txt";

    private GenericManagedConnection genericManagedConnection;

    private PrintWriter out;

    public FileConnection(PrintWriter out,GenericManagedConnection genericManagedConnection,ConnectionRequestInfo connectionRequestInfo) {

        this.out = out;

        this.genericManagedConnection = genericManagedConnection;

        this.connectionRequestInfo = connectionRequestInfo;

        this.initialize();

    }

    private void initialize(){

        try {

            this.buffer = null;

            this.fileOutputStream = new FileOutputStream(FILE_NAME,true);

        } catch (FileNotFoundException ex) {

            Logger.getLogger(FileConnection.class.getName()).log(Level.SEVERE, null, ex);

            throw new IllegalStateException("Cannot initialize OutputStream: " + FILE_NAME);

        }

    }

    public void write(String content) {

        this.buffer = content;

    }

    public void close() {

            this.genericManagedConnection.close();

    }

    public void destroy(){

        try {

            if(this.fileOutputStream != null)

                this.fileOutputStream.close();

          this.fileOutputStream = null;

          this.buffer = null;

         } catch (IOException ex) {

            Logger.getLogger(FileConnection.class.getName()).log(Level.SEVERE, null, ex);

            throw new IllegalStateException("Cannot close stream: " +ex,ex);

        }

    }

    public void begin() throws ResourceException {

        this.initialize();

    }

    public void commit() throws ResourceException {

        out.println("#FileConnection.commit "  +toString());

        try {

         this.fileOutputStream.write(this.buffer.getBytes());

         this.fileOutputStream.flush();

         this.fileOutputStream.close();

        } catch (IOException ex) {

            Logger.getLogger(FileConnection.class.getName()).log(Level.SEVERE, null, ex);

            throw new ResourceException(ex);

        }

    }

    public void rollback() throws ResourceException {

        out.println("#FileConnection.rollback  " +toString());

        this.buffer = null;

        try {

            this.fileOutputStream.close();

        } catch (IOException ex) {

            Logger.getLogger(FileConnection.class.getName()).log(Level.SEVERE, null, ex);

            throw new ResourceException(ex);

        }

The nice thing are transaction callbacks. You will be notified about the transaction progress by the container. At commit time, you just write the buffer to the file - in case of a rollback you have to clear the buffer. This sample is not fully transactional - because in general you will have to deal with corrupted files etc. - but it should be clear how it works.

After installation, you will be able to inject the interface (and so the FileConnection) to your business logic.

@Stateless

public class JCAClientBean implements JCAClientRemote {

    @Resource(mappedName="jca/FileFactory")

    private DataSource dataSource;

 ...and the transactions will be propagated transparently for you.

JCA connectors are not as lean as simple as EJB 3.1 or CDI,  but orders of magnitude more robust and more maintainable, than solutions and workarounds which are usually built instead.

You will find a working example (tested with Glassfish v2) in http://kenai.com/projects/javaee-patterns/. See GenericJCA, GenericJCAAPI and JCAClient projects. I described this solution in dedicated chapter "Generic JCA", page 181 in Real World Java EE Patterns - Rethinking Best Practices".

The example presented here is based on the ancient Java EE 5 technology. JCA 1.6 connectors are lot simpler and more elegant - stay tuned. 

Last week I managed to schedule sessions I would like to attend. The topics are interesting and technical - really looking forward to it. Product pitches are not existent - at least I didn't found any. From the topic / session perspective - I really looking forward to this conference. From the content perspective it should be at least as good as the previous ones. (I will miss, however, the "Xtreme GUI Makeover")

The schedule builder software isn't a usability show case:

1. The window in the left lower corner is way to small. Even on high resolution it was hard to see all sessions at a glance
2. There is no clean separation between the conferences - so you get overwhelmed with sessions. There should be a clear separations between JavaOne and Oracle Develop. I would like to be able to explicitly choose between conferences. It was not only hard to find the JavaOne talks, but also Oracle Develop like e.g MySQL and virtualization because of this interference as well.
3. Its really hard to find the time slots. I used the try-and-error strategy, but was time intensive
4. I didn't managed to find a direct link to the talks. I always have to use the advance search to find my own talks. (a bit REST could be a solution for this problem)
5. Why nothing happens on Wednesday after 5 p.m.? I miss the BoFs

See you, however, at JavaOne. If you think Java EE 6 is complicated, slow or whatever - prepare your questions and attend my talk: S319369 The Feel of Java EE 6: Interactive Onstage Hacking (Wednesday). I will spend 30 seconds with slides and 55 minutes in the IDE and implement functional Java EE application with CDI, JPA, Servlets 3, JSF 2, REST, EJB 3.1, some mocks and units test without using any generators, prepared templates, wizards or other unfair stuff :-).
I will probably deploy it ~100 times - and you will not even noticed that. I'm seriously thinking about implementing a Schedule Builder during this session :-).

Already looking forward to the JUG session in Hamburg. This time I will try to implement interactively a bookshop with Java EE 6, without any wizards, code generations, templates and other unfair stuff :-).
Because JUGs are fun - I will try to show as many Java EE 6 features as possible, and so probably over-engineer the application a bit. I promised that several times already - but now its time to proof the "lightweightness" of Java EE 6 in the IDE and not only on slides. I would introduce at least REST, JSF 2, CDI (JSR-330 and JSR-299), JPA, Bean Validation, EJB 3.1, Mocks, Unit Tests probably Maven (depends on the internet connection). Please prepare some heretical questions, or ideas.

See you at the bookstore "Lehmanns", 8 pm. They should also have some of "Real World Java EE Patterns - Rethinking Best Practices" books.

Got an interesting email with questions regarding Java EE restrictions. Some answers:

>"I have installed Glassfish 3.0.1 and am using NetBeans 6.9.1 for implementing stuff"
Congrats - you saved about 5h :-).

1. I have a web service running on Glassfish. What can I do now to access an RMI based server? Can I do this: HelloWorldRMI hdl = (HelloWorldRMI) Naming.lookup("rmi://localhost:2000/HelloWorldRMI"); String helloString = hdl.sayHello("WS");
   Yes you can. It works perfectly with all servers I know. This is what I do with greenfire.dev.java.net to access the native driver.
2. Can I also open a socket from the same web service to another C++ based server?
   You can open client sockets, but not server sockets. I did it in the past with JBoss, Glassfish and WLS. The spec is a bit fluffy here.
3. Can I write something to a file?
   It will work on most application servers, but it isn't compliant. It is also problematic regarding consistency and concurrency.
   You could write a JCA connector for transactional file access. It is easier, than you may think. I wrote a JCA-File connector in my book Real World Java EE Patterns - Rethinking Best Practices See page 181 - Generic JCA connector. My transactional example is comprised of ...4 classes and one XML file.
4. Can I create my own classloader and load classes through there?
   It will mostly work, but is not compliant."...Allowing the enterprise bean to access information about other classes and to access the classes in a manner that is normally disallowed by the Java programming language could compromise security..."
5. Can I dynamically create classes like this: MyClass myClass = (MyClass) Class.forName("...my.MyClass").newInstance(); String returnString = myClass.sayHello(className);
   This is perfect - except obtaining EJBs and CDI managed beans that way :-)

(My) definition of the architect's role: "Software Architect is someone who is able to break down customers (=product owners, sponsors etc.) vision in more or less fine grained software artifacts"
I prefer the term "vision" over requirements, because most of the time requirements happen to be unstable and the customer actually unsure.
An architect should also immediately inform the customer about the impacts of his functional and non-functional requirements. Pro-active consulting in the definition phase about the consequences of high availability, modularization, distribution, security etc. is crucial and safes real money. The architect should be especially well experienced with possible problems and side-effects.

To provide a real value to the company, the architect should not only sell his ideas to the developers, but also convince them with hard facts and be open for feedback (a single architect just cannot be smarter, than a whole developer team). The problem here: it is very hard to convince developers with PowerPoint, Visio or plain UML-diagrams. A better idea is to verify the high level ideas with Proof Of Concepts - small applications or code snippets, and some test results (memory consumption, scalability, performance, testability). This easiest the communication a lot. Developers feedback will be a lot better, and there is no better concept explanation, as high level and clean Java, Ruby, Scala etc. code. Furthermore the PoC could evolve to a concept prototype and the could be used as a sample for a tutorial for new developers.

...my definition of developer's is: "Developer is an architect, who just don't want or is not able to deal with the translation of high level requirements into low level code, and enjoys to code more". Therefore an architect is a developer, who enjoys the translation and likes communication, meetings and everything else what is needed to extract the requirements from the customer.

An architect should be only a temporary role. Otherwise it will be harder to keep up with the technology and you will end up in an "ivory tower": "...From the 19th century it has been used to designate a world or atmosphere where intellectuals engage in pursuits that are disconnected from the practical concerns of everyday life. As such, it usually carries pejorative connotations of a wilful disconnect from the everyday world; esoteric, over-specialized, or even useless research; and academic elitism, if not outright condescension..." [from wikipedia]

1. JUG Darmstadt: Stop Talking, Start Hacking "Session" in Darmstadt (24.08.2010)
2. Java EE 6 Patterns, or one week Real World Java EE 6 in Hamburg (30.08-03.09.2010) - some places left - will take place
3. I promised a talk at the JUG HH in between 30.08.-02.09.2010 - but the JUG guys seems to be on vacations. If you have another ideas for a JUG freestyle session in Hamburg in this period - let me know. In worst case we could occupy StarBucks :-)
4. ch-open Workshop:Its Not A Trick - It's Java EE 6. Live - from installation to deployment There were > 24 registrations several weeks back. Looking forward to this one. I will use only few slides and a lot my keyboard. It will be an interactive hacking workshop.
5. SIG Java: Java EE 6 from the IDE perspective, 09.09 in Munich
6. JBoss OneDayTalk:Lightweight, Lean and Productive with Java EE 6, 01.10.2010 in Munich
7. JavaOne in San Francisco, 19.09-23.09.2010: S313248 Creating Lightweight Applications with Nothing but Vanilla Java EE 6, S313250 JavaFX Script: The Java Patterns Killer, S313278 Java EE 6 Panel: What Do We Do Now?, S314243 Hacking Heating Systems with Java EE 6, JavaFX, and Scripting
8. End 2 End Java EE 6 in Munich (20.10-22.10.2010) - we will build together a fullstack application. Furthermore I will try to answer as many questions, and solve as many problems as possible. In the last workshops we eliminated several millions lines of J2EE code, just during the breaks :-)
9. Workshop: Xtreme Productivity with Java EE 6 in Munich, 04.11-05.11.2010 We will concentrate on productivity and "clean code" with Java EE 6. The aim of the workshop is rethinking of existing patterns and best practices and align them with Java EE 6

The Gateway exposes rich and persistent domain objects directly to the presentation logic. Because the domain objects are well encapsulated already - it is rather an advantage, than a shortcoming. Because of simplicity and built-in aspects, an EJB 3.1 happens to be the simplest and leanest candidate for a Gateway implementation.

Why local (to JSF 2, Wicket or a Fat Client)?

1. Rich domain objects (JPA 2) contain business logic per definition. A call to method can change the state not only of the target entity, but of the whole connected graph. In the local case the EntityManager will correctly recognize the changes and compute deltas (change sets) and persist all changes at the end of the transaction. In remote case you will have to implement the same functionality - what is actually duplication.
2. In local case you don't have to care about lazy loading. The entities gets just loaded on demand.

Why stateful (means: keeping the entities attached between requests)?

1. In complex scenarios the data synchronization between layers becomes a challenge. If you keep you entities managed between requests, there is nothing left to do. You can even bind them directly to the UI - and it will still work.
2. For every request you will have to build the domain graph again and again. This is not only complex, but it does not necessarily scale better, than a stateful solution

Local, stateful facades are not necessary the silver bullet, but the resulting architecture is very lean. It mainly consists of only domain objects, with a few Gateways.
Before you start prematurely "improving" the scalability and start with bloated applications, it is more reasonable to concentrate on the core business logic and stress test continually the application. In some cases a stateful architecture wont't scale. In this case you will have to provide the synchronization, delta-computation afterwards - with demand documented with stress test results.

[See Gateway, page 101 in "Real World Java EE Patterns Rethinking Best Practices" book for more in-depth discussion]

Back from JUG Paris. It was almost a conference (~200 attendees). It was my first time in Paris -> I really like the city. Although I was said to got some competition by the football world championships, the room was packed.I predicted France to become the football world champion (I'm a true football expert :-)) - the attendees liked my expertise in this area.

I started with slides and ended in the IDE. What I really enjoyed - was the amount of good questions (from AOP, to SmallTalk). The situation escalated in the breaks, where some attendees asked me several questions at the same time concurrently. These questions were the best.

In the last part I build a JUG Management System with CDI, EJB 3, JPA, REST (JSON+XML), a bit security, Servlets and in the last two minutes I introduced JSF 2. Because of time, I started to answer questions in the IDE :-).
After the session we spend about 2 hours in restaurant and another 2 hours in a bar - still discussing Java EE, Clustering, Failover, scalability, private / public Clouds Java, even JINI. We discussed 98% Java and 2% private stuff (like the relation of a freelancer to vacations :-)).

Paris JUG is really well organized - and all participant seem to have lots of fun. Really enjoyed that. Already looking forward to SophiaConf in Nice. What also interesting - there is a female group of Java Hackers in Paris. This could be the beginning of a female Java Champions division as well.

The appearance of UI-Controls in Java FX can be either configured programmatically, or with CSS. See this comprehensive CSS reference. Hopefully it will be distributed with the official SDK doc in the next release...
Its a kind of "Convention Over Configuration" again :-).

EJB 3.1 + REST are perfect combo for HTTP and resource style programming. REST is not very well suited for the exposure of already existing interfaces. The RPC-misuse of REST will result in hard to understand and so to maintain code.
With hessian it is very easy to expose existing Java-interfaces with almost no overhead. Hessian is also extremely (better than IIOP and far better than SOAP) fast and scalable. The size of the whole hessian library (hessian-4.0.7.jar) is smaller than 400 kB and so compatible with the "Kilobyte Deployment" style of Java EE 6 programming and deployment.

To expose an existing EJB 3.1 with hessian:

@Stateless public class CurrentTime { public long nanos(){ return System.nanoTime(); } } You will need an interface:
public interface TimeService { public long nanos(); }
...and hessian-specific implementation of the endpoint:

public class HessianTimeEndpoint extends HessianServlet implements TimeService{ @EJB CurrentTime currentTime; @Override public long nanos() { return currentTime.nanos(); } }
The hessian enpoint is an servlet - so the dependency injection works here without any XML configuration. You can just inject your no-interface EJB 3.1 view bean into the servlet.
The client side is also very lean. You only need a two lines of code to get a reference tot he proxy: public class HessianTimeEndpointTest { private TimeService timeService; @Before public void initProxy() throws MalformedURLException { String url = "http://localhost:8080/EJB31AndHessian/TimeService"; HessianProxyFactory factory = new HessianProxyFactory(); this.timeService = (TimeService) factory.create(TimeService.class,url); assertNotNull(timeService); } @Test public void nanos() { long nanos = this.timeService.nanos(); assertTrue(nanos>0); System.out.println("Nanos: " + nanos); } } HessianServlet inherits from GenericServlet and not from HttpServlet. This is a shame, because you will have to use a web.xml deployment descriptor, instead of a single annotation @WebServlet:
<web-app > <servlet> <servlet-name>TimeService</servlet-name> <servlet-class>com.abien.patterns.business.sf.hessian.HessianTimeEndpoint</servlet-class> </servlet> <servlet-mapping> <servlet-name>TimeService</servlet-name> <url-pattern>/TimeService</url-pattern> </servlet-mapping> </web-app>

You will find the executable project (tested with Netbeans 6.9 and Glassfish v3.0.1) in: http://kenai.com/projects/javaee-patterns/ [project name: EJB3AndHessian].
The whole WAR (EJB 3, Servlet, web.xml and the hessian "framework") is 393 kB. 385 kB hessian, and 7 kB EJB + Servlet :-)

The initial deployment of the WAR with EJBs took: INFO: Portable JNDI names for EJB CurrentTime : [java:global/EJB31AndHessian/CurrentTime!com.abien.patterns.business.sf.CurrentTime, java:global/EJB31AndHessian/CurrentTime] INFO: Loading application EJB31AndHessian at /EJB31AndHessian INFO: EJB31AndHessian was successfully deployed in 807 milliseconds.
Don't worry: the subsequent deployments are substantially faster :-): INFO: Portable JNDI names for EJB CurrentTime : [java:global/EJB31AndHessian/CurrentTime!com.abien.patterns.business.sf.CurrentTime, java:global/EJB31AndHessian/CurrentTime] INFO: Loading application EJB31AndHessian at /EJB31AndHessian INFO: EJB31AndHessian was successfully deployed in 568 milliseconds.

[See also Service Facade pattern, page 69"Real World Java EE Patterns - Rethinking Best Practices]

The free Java EE 6 events in the week of 05.07-09.07.2010 will start at July the 6th in Paris. I will give a (hopefully openspace-like / interactive) presentation with the title Lightweight Killer Apps with Nothing But Vanilla Java EE 6.

In the same week I will give a releated presentation Java EE 6 - Leaner Than POJOs in Nice.
Java EE 6 is so lightweight - that it may look overly complicated on slides. For that reason I will spend the majority of the time in the IDE. Hope it is o.k.
Thanks for the invitation (and sorry for the rollbacks in the past)! I guess I'm the only speaker with a truly french last name - but without any capability of speaking french :-).