Wednesday, June 29, 2005

JavaOne: Coding across continents - Technologies for remote, real-time, collaborative software development

Notes from JavaOne 2005...

Todd Fast, Sun Microsystems

Developer collaboration goal: location independent "bullpen", substitute for face-to-face interactions. Focus specifically on developer tasks - sharing of programming artifacts, code review, pair programming. Focus on ad-hoc, instant interactions. Not a substitute for other collaboration tools like email or simple IM. Everyone using an IDE is a potential development collaboration user.

Use cases: Maintain a list of colleagues and know when they're available. Chat with colleagues while avoiding common IM issues. Share files and diagrams with colleagues within IDE. Edit shared files and diagrams collaboratively. Share drawings and screenshots. Remote assistance. Remotely compile and deploy projects. Pair debugging. Synchronize files between version control points. Project coordination - TODOs, documentation, author tracking.

Case study - Developer collaboration in Sun JavaStudio Enterprise. Support arbitrary types of information sharing. Start with use cases from within team. Highly extensible - allow other colleagues, teams, groups to add built-in collaboration capabilities. Define APIS to be shared by multiple products. Interoperable - not specific to Java code or specific IDE.

Began productization in early 2004, released in JSE7 (Q4/2004).

Architecture: Server-based collaboration with shared collaboration server acting as message router. No collaboration state saved on server. Multiple collaboration clients (IDEs) can connect to multiple servers using XML messages over XMPP.

Chose XMPP because it's open, high-capability, and readily available server and client implementations. Collaboration server made from "light" version of Sun Instant Messaging Server.

Learning points: This hadn't really been done before. other types of collaboration had been done, but not developer collaboration. Required constant design decisions and tradeoffs. Technology alone was the wrong target. Everyone has collaboration technology, but it's really just a means to an end. Interoperability quickly became important.

For interoperability, protocols are most important (not APIs, not platform). Messaging vs. streaming is much more scalable (packetized, routable). Transport is basically irrelevant. XML-based has too many advantages to list.

Announcement - all this is being open-sourced at http://collab.netbeans.org. Released under Sun Public License (SPL - variant of Mozilla Public License). Not limited to NetBeans. APIs are independent of NetBeans - some APIs may move to java.net eventually. What they're open-sourcing: Collaboration APIs, NetBeans collaboration user interface, file-sharing collablet, code-aware IM chat collablet. CodePal - standalone collaboration client, built using NetBeans platform edition.

share.java.net is a internet-accessible public developer collaboration server. Works with JSE7 and 8, NetBeans 4.x, CodePal.

Collaboration technologies - CollabBeans, Collablets, and MOXC.

Concepts and terms: Collaboration occurs within conversations, akin to a virtual conference room. Unlimited participants, all messages routed to all participants. Multiple conversations per user session. Conversations include multiple channels, abstractions for types of collaboration (e.g., chat, file-sharing, whiteboard, voice). Conversations can contain any number of channels. Collablets provide channel functionality.

MOXC protocol is technology-neutral XML-based collaboration protocol.

CollabBeans used to build collaborative applications. Non-visual components, no UI elements, but includes abstraction for coarse-grained user interactions. Presentation is up to host application UI. Provides both API for presentation and collablets and SPI for transport providers like XMPP and JXTA. Covers presence, session, message, conversation.

Collablet is software component to perform a specific type of collaboration. Collablet instances are scoped to particular conversation, and are stateful within the scope of that conversation. Embodiment of a channel, responsible for sending and responding to messages. Self-contained - care about peers but don't care about other collablets. Can be interactive (provide UI) or non-visual. May or may not be specific to a host application. Interoperability might not always be appropriate.

API overview - today is Sun Java Studio Enterprise private API, moving to public API (still in progress).

MOXC = message oriented XML collaboration. A web services approach with XML messages using SOAP. Benefits - transport agnostic, can be encapsulated in JMS, XMPP, SOAP, TCP/IP, CORBA, RMI, etc. Maximum interoperability, technology neutral, easily validated, transparently routable. Portable - clients can be written in any language, any API. Channels and messages become describable via WSDL. Extensible in a predictable fashion. Easy - related specs are well-documented. Next JDK will include web services built-in.

Why MOXC and web services? Use web services specs where they make sense: SOAP for overall message structure, extensibility via headers. WS-Addressing conversation, sender, recipient, channel. Create XML messages for common profiles like discovery & coordination, client capabilities, file-sharing. Document-centric, not RPC approach.

No direct SOAP or WS-* dependencies in Collablet code. Collablets construct and interpret channel-specific XML messages - these appear as the only child in the SOAP body element. Collablets can be extended to support their own messaging protocol too (don't have to use MOXC), but it's there if you want it.

Demo using NetBeans 4.1 IDE.

No comments:

www.flickr.com