Google Apps Web Services Hub

Last Wednesday, I was on the Google Apps Marketplace meetup. There were awesome presentations from Google’s Scott McMullan who gave a clear view about Marketplace business model and its opportunities for developers, and four excellent examples from companies that already offer their applications there. While I was listening about these applications and services offered by Google, I got an idea that there something is missed. Although each product has tight integration with Google Apps, they have no clue about others, so it’s hardly possible to associate sales contract from myERP with manymoon project, or use JIRA Studio for custom software development contract. MyERP has no payroll feature, but such applications are already presented in the Google Marketplace, yet they cannot be easy integrated with myERP accounting. Without such interaction capability, customers get only set of the independent applications, but not a solid corporate system.

Of course, applications may expose their own web services that can be used by others. For example, JIRA studio can use OpenSocial API ( not sure about RPC that is available for its standalone product), and someone can use it in another project. But, it’s hardly possible for any application to know about all possible partners and create connectors for all of them. Also, each application has to provide its own management tool there user can configure what are included into his corporate domain and how to use them. It would be also a nightmare for an administrator who have to use couple of different management tools just to append new application to domain or change user permissions.

The solution is well known in the software development: that is service dispatcher architecture. Any application should connect to the single controller that knows about all services in the domain and transfer request to appropriate endpoints. That can be REST-style service that only perform lookup tor the desired type of services and return response with service description and endpoint address so application can call discovered services directly.

There should be common contract for all services, so different applications can call any endpoint and understand its response. On the other hand, such contract should be extensible to easy introduce new type of service. I see that as some kinf of the Semantic Web ontology ( Semantic Web Services Registry ), there any developer can introduce a new type of service as extension of the existing one and register it on the service dispatcher. Other application can use it as the base type, while another will be able to get extended information. For example, accounting system can export its data in XBRL format, that extends XML+Stylesheet content, and latest may inherit simple file service. In this case, the same service can be used by an application that simple attach its response to the mail message because any file can be used there. Another consumer can display the same report on web page as result of XSLT transformation. Finally, any financial service that recognizes XBRL format may leverage all available information. In the opposite direction, the same ontology should also provide information about content types that can be accepted by the client, so service endpoint will decide proper format according to the request “Accept” header.

It’s not necessary for such REST web service hub to be provided by Google Apps. It can be independent application compatible with Google Apps contract, that uses OpenId and Oauth to authenticate, with its own management system. Any application in the customer domain can register its services and their descriptions, so another client would get it by request for particular type of services. That hub should also maintain user permissions, so domain administrator can use the single management console to configure services and grant or disable particular users to use some services. For applications that does not follow common format, or do not included into the domain there would be converters that seamless translate calls to target. For example, Salesforse clients can use their account from Google applications. Of course, there should be compatibility kit to test services provided by the third party applications, and libraries for most popular computer languages that makes service development easy.

The hardest part of such project will not be a technical implementation, but carefully designed format of services, and encouraging providers to use these standards. Really, the success mostly depends from how many third party developers will support proposed services. But if they do, all parts participated to the Google Apps Marketplace will be winners: Consumers would get more integrated solution that can improve business performance; developers can use already existing services to increase capabilities of their products, and they can faster put applications to market because it is not necessary to implement already existing features. Finally, it will increase Google Apps market and make it more profitable for Google.

Advertisement

About Benchmarking JSF libs

Mert Caliskan recently posted blog article about JSF libraries performance.

I’ve downloaded and run all these examples on my local machine ( That is Intel Core2 Duo 2.4 Mhz, 4GB RAM, Fedora Core Linux 11, Apache Tomcat 6.0.18 with jdk 1.6.0_18 ). Though I got a similar results for RichFaces demo and Trinidad, PrimeFaces performs AJAX requests from 23 up to 80 milliseconds, with median about 40 milliseconds. Firebug results seem adequate because they are close to request processing time shown by the eclipse TCP/IP monitor.

There is FireBug console’s scrinshot:

Because even clean JSF page that contains only one form with one input field and submit button shows similar results that is about 20ms per request on the same environment, I do not see a much performance difference.

JavaOne

My JavaOne schedule:

JSF 2.0 / RichFaces 4.0 talk at the Jboss Mini Theatre on Wednesday June 3rd at 3:30-4:00PM

The JSF 2.0/Ajax BOF section:

ID#: BOF-4869
Title: JavaServerT Faces Platform and Ajax: State of the Union
Date: 03-JUN-09
Time: 06:45 PM-07:35 PM
Venue: Moscone
Room: Esplanade 307-310

JSF component in JavaFX

User-defined components in JavaFX.

Due to pure object-oriented JavaFX nature create custom component is pretty simple:

/* define the new component that contains input text field and
label for it: */
public class Input extends PanelGroup {
               public attribute value
               public attribute label:String
               override var children = [
               OutputLabel {
                    value:  bind label
                    id:"{id}:label"
                    for:"{id}:input"
               },
               InputText {
                  label:"Input"
                  value: bind input
                  id:"{id}:input"
                  valueChanged: Ajax {}
               }

That class may be used anywhere as any other component:

     .........
     Input {
        id: "baz"
        styleClass:"defaultInput"
        value: bind foo.bar
        label: "Input:"
     }
     ........

JavaFS binding and JSF AJAX

Using JavaFX binding for JSF AJAX applications.

JSF 2.0 AJAX features going to the common event-driven GUI model. We could interpret Behavior as EventListener bounded to the event source on the both client and server sides. That hides and simplifies communication process for application developers, but they still have to manually define parts of page that affected by model updates and should be refreshed on the client in the same way as for old Ajax4jsf and RichFaces. But most of the modern GUI libraries, like Java Swing or JavaFX have also backward communication channels there bonded properties or models fires events on model changes which update the user interface transparently. For the JavaFX VDL implementation events from bonded properties may be used to calculate parts of page to update during AJAX request.

The manual approach, developer has to define “out1” component in the render list to update its value by AJAX. Component will be updated regardless was actual value changed or not:

        Output: <h:outputText id="out1" value="#{echo.str}"/>
        
        Input: <h:inputText id="in1" value="#{echo.str}">
            <f:ajax render="out1"/>
        </h:inputText>

Would be converted into:

               OutputText {
                  label:"Output:"
                  value:  bind echo.str
                  id:"out1"
               },
               InputText {
                  label:"Input"
                  value: echo.str
                  id:"in1"
                  valueChanged: Ajax {}
               }

Input text component fires AJAX request that updates “str” attribute on the “echo” object. That update marks outputText component to be rendered by the binding “value” attribute to the same “echo.str” value. If value was not changed, component will not be rendered.

JavaFX as JSF 2.0 VDL

JavaFX as JSF 2.0 view description language.

Preface

The JavaFX language has been developed for Rich Internet Applications. The project FAQ says:

“JavaFX is an expressive rich client platform for creating and delivering rich Internet experiences across all screens of your life. JavaFX 1.0 was released on December 4, 2008. As of February 1st, 2009, there had already been over 100,000 downloads of the tools and SDK. Today, JavaFX is available on over 50 million desktops.” In spite of that is really means applets or Java Web Start applications, I was a curious: Is that would be useful for web applications also ? Take look at the description from the OpenJFX compiler site:

What is JavaFX Script?

1. automatic update (bind)

2. list comprehensions (sequences)

3. easy-to-use

4. runs on JVM

5. interacts smoothly with Java

6. easy natural object graph creation (object literals)

7. graphics centric

8. single threaded

9. focused on small to medium scale applications

10. curly-brace language

Ok, take a look for these features :

1. Bind. This is most attractive for me as capability for the JSF Ajax . Instead of manual definition for ‘dirty’ parts of page; as it implemented in the RichFaces, JSF 2.0 and some other projects, or analyzing differences in the rendered HTML code as the IceFaces project does, application can update these parts of page only where model values was changed. That would simplify application development on the same way as for Swing.

2. Not sure how is that applicable for a web application.

3. That is always necessary.

4. I.e. in the same environment as JSF works.

5. Good for JSF/JEE applications too.

6. Very attractive for JSF application because of the tree-like view structure.

7. Not web advantage.

8. That doesn’t mean real single threaded implementation, I guess, because JavaFX GUI is based on Swing which uses threads, but hides thread manipulation from the application developer. It would be funny for web applications if we could put discrete requests processing behind developer’s concern.

9. Really, that is a main target for JSF applications too.

10. Not sure about that.

So, at least seven from ten JavaFX features are applicable to JSF Web. But additional advantages are pure object-oriented language, type safety …

Implementation idea

The one of the new JSF features is pluggable View Declaration Language. Chapter 7.6 of the Java Server Faces Specification says:”A View Declaration Language (VDL) is a syntax used to declare user interfaces comprised of instances of JSF UIComponents.”. The simplest way to integrate JavaFX with JSF is ViewDeclarationLanguage implementation that creates tree of JSF UIComponents from the JavaFX script. For example, if user requests page “ http://foo.com/bar/baz.fx” that implementation should execute “/bar/baz.fx” script from the web application content or load and execute pre-compiled “bar.baz” class. The script should create the tree of JSF UIComponents in the same way as any other JSF VDL does. Really, in the research prototype VDL implementation expects instance of the special “ JavaFXHandler” interface that creates UIComponent instances in the “ apply” method. That simplifies script content and allows to cache results between requests. Therefore, a simple JavaFX page would seem like this ( that is part of JSF 2.0 version of the guess number example page ):

import org.richfaces.javafx.*;

View {
  children:[
    Head {
      children:[
         Title {
              value: "GuessNumber 2.0&amp"
         },
         StyleSheet {
              value: "css/styles.css"
         }
      ]
    },
    Body {
         bgcolor:WHITE
       children:[
          Form {
              id: "helloForm&amp"
            children:[
               H2 {
                      value: "{userNumberBean.greeting}"
               },
               Image {
                  src:"{resource['images/wave.med.gif']}"
                  alt:"Hello!"
               }
               InputText {
                  label:"User Number",required:true
                  value: bind userNumberBean.userNumber
                  id:"userNo"
                  converter: NumberConverter {integerOnly:true}
                  validators: [
                                 GuessNumberValidator {
                                     min:userNumberBean.minimum
                                     max:userNumberBean.maximum
                                 }                                 

                              ]
               },
               CommandButton {
                  value: bind userNumberBean.userNumber
                  id:"submit"
                  action: Action {viewId:"response",redirect:true}
               }
          }
       ]
    }
  ]
}