Server TF Minutes 2007-01-31

From MemberWiki

Jump to: navigation, search

Minutes stored at url: /member/wiki/Server_TF_Minutes_2007-01-31

Attendees

  • Ric Smith <richard.allen.smith(at)oracle.com>
  • Christophe Jolif <cjolif (at) ilog.fr>
  • Jon Ferraiolo <jferrai (at) us.ibm.com>
  • Ken Tam <kentam(at)bea.com>
  • Shel Finkelstein <shel.finkelstein (at) sap.com>
  • Ted Goddard <ted.goddard(at)icesoft.com>

Original Agenda

  • Agenda
    • GOAL:Attempt to define the problem(s) we intend to solve
      • Make another go at defining use-cases
    • Review of contributed use-cases (brief)
    • Understand commonality between IDE task force use-cases
    • Wrap up

Minutes

Initial discussion was about how most of the contributors have JSF products, so won't it be difficult to create a platform-independent architecture? Jon expressed some confidence, mentioned that there might be new members from outside the Java world (wink, wink), that some members such as ILOG and Nexaweb already have to support .NET, that IBM will probably represent PHP if no else does, and that jMaki is an example of technology that at least attempts to abstract out JSF dependencies.

Jon highlighted overlap with IDE TF efforts and suggested that the end result might be an "OpenAjax Components" specification which covers how to define metadata and other wrapper things such that arbitrary components can be integrated with arbitrary IDEs and arbitrary server frameworks. Jon mentioned that jMaki has a single JSP tag for all Ajax components within the jMaki framework, which means all Ajax components within multiple popular Ajax libraries. Therefore, one bit of JSP and JSF glue works against with Ajax components.

Discussion about whether this group needs to standardize on a single transport mechanism, such as SOAP. Subsequent discussion was about how most of the Ajax community does lightweight things via XHR and that SOAP is only the preferred mechanism for a fraction of the world. It seemed like there was consensus on this issue and others that we need to embrace diversity and help diversity interoperate rather than legislate a single approach. Someone asked about whether it makes sense to work on a common marshalling approach across multiple technologies, but no subsequent discussion.

Discussion about "AJAX" complexities in composite applications because different toolkits (prototype, dojo, etc) use different approaches to communications. Jon brought up the efforts of the Communications Hub, which is focusing on defining a common client-side communications mediator that supports both request/response and server-push (publish/subscribe).

Shel asked about whether this group needs to exist given overlaps with IDE TF and Comm Hub task force. Jon responded that neither task force is addressing the glue piece that integrates with server frameworks such as JSF, so this group does need to exist, but has to coordinate with the other task forces.

Multiple people expressed uncertainty about OpenAjax Alliance pursuing server-side standard APIs for communications in general and push in particular, but the consensus was that we should take a shot at it and see where we end up.

Discussion about how each server technology seems to be addressing Ajax communications requirements, except everyone is doing it differently. (Jeti, Oracle, BEA, Lightstreamer, ICEfaces, etc.) General agreement that we should see if there is a way we can help the industry by defining common approaches. Jon mentioned that there might be a 90/10 solution where we can define a standard for common things that cover the 90% scenario but don't attempt to address the complexities of the 100% scenario.

Ken said that BEA has discovered that the hard thing to figure out with server-side communications is the programming model.

Ken said that API requirements for Ajax developers is different than API requirements for push developers. Push tends to be machine-to-machine.

Shel said that its definitely in the mandate to look at server-side issues, but warns that: (1) apis take time to develop, (2) not clear how valuable it will be. Ken says he tends to agree. But maybe we can try to come up with something that can sit on top of the things that exist today or are being created today.

Ric said that one possible plan of attack is to figure out if the JCP is working on something and then attempt to abstract out the Java dependencies so that it could work with PHP for example.

Ted suggested that we might try to solve the client-side communications problem first, and later move to the server. Then approach various technologies and try to get uniform approach to messaging Apis. Ken said but now there is about a 50/50 split between open request vs. polling. Ted asked if we could make the APIs pluggable. The APIs could present an interface that looked like either, and the implementation would make things work with the technology that happened to be used under the hood. Shel speculated that we need to support all, not focus on just one.

Jon explained that the CommHub TF has tentatively concluded that in order to mediate communications and prevent channels from getting used up, all client-side communications must go through the Hub. Shel said this is fine so long as it is ok to use different transport technologies along different channels. Jon said that's the intent.

Ric mentioned that Oracle has an initiative called Active Data Channels that represents yet another approach.

Ken said that even if OpenAjax doesn't do anything with push standards, there might be an interesting opportunity for standards around everything else.

Jon suggested that the Server TF join the Comm Hub TF phone call that will happen in 3 weeks, and everyone agreed. Jon promised to send email to Coach to make this request.

We agreed to have a more in-depth look at jMaki at the next phone call. Ric promised to send email to Greg Murray to try to get him to join that call. In 2 weeks.