Of the handful of Program Committees I’m on each year, this one is almost always the highest quality of the bunch. Please consider submitting a paper.
ACM/IFIP/USENIX 7th International Middleware Conference Melbourne, Australia November 27 - December 1, 2006 http://2006.middleware-conference.org/ The Middleware conference is a forum for the discussion of important innovations and recent advances in the design and construction of middleware. Middleware is distributed-systems software that resides between the applications and the underlying operating systems, network protocol stacks, and hardware. Its primary role is to functionally bridge the gap between application programs and the lower-level hardware and software infrastructure in order to coordinate how application components are connected and how they interoperate. Following the success of past conferences in this series, the 7th International Middleware Conference will be the premier event for middleware research and technology in 2006. The scope of the conference is the design, implementation, deployment, and evaluation of distributed system platforms and architectures for future computing and communication environments. Highlights of the conference will include a high quality technical program, tutorials, invited speakers, poster presentations, and workshops. Submissions on a diversity of topics are sought, particularly ones that identify new research directions. Middleware 2006 is not limited to topics discussed in previous Middleware conferences. Authors concerned about the appropriateness of a topic may communicate by electronic mail with the program chairs prior to submission. The proceedings of Middleware 2006 will be published as a Springer-Verlag volume in the Lecture Notes in Computer Science Series. Topics: The topics of the conference include, but are not limited to: Platforms and Architectures: * Middleware for Web services and Web-service composition * Middleware for cluster and grid computing * Peer-to-peer middleware solutions * Event-based, publish/subscribe, and message-oriented middleware * Communication protocols and architectures * Middleware for ubiquitous and mobile computing * Middleware for embedded systems and sensor networks * Service-oriented architectures * Reconfigurable, adaptable, and reflective middleware approaches Systems issues: * Reliability, fault tolerance, and quality-of-service in general * Scalability of middleware: replication and caching * Systems management, including solutions for autonomic and self-managing middleware * Middleware feedback control solutions for self-regulation * Real-time solutions for middleware platforms * Information assurance and security * Evaluation techniques for middleware solutions * Middleware support for multimedia streaming * Middleware solutions for (large scale) distributed databases Design principles and tools: * Formal methods and tools for designing, verifying, and evaluating middleware * Model-driven architectures * Software engineering for middleware * Engineering principles and approaches for middleware * Novel development paradigms, APIs, and languages * Existing paradigms revisited: object models, aspect orientation, etc. * On-the-fly management and configuration of middleware Organization: General Chairs: Joe Sventek (Glasgow University, UK) Shanika Karunasekera (University of Melbourne, Australia) Program Chairs: Michi Henning (ZeroC, USA) Maarten van Steen (Vrije Universiteit Amsterdam, Netherlands) Local Arrangements Chairs: Aaron Harwood and Lars Kulik (University of Melbourne, Australia) Workshops Chair: Antony Rowstron (Microsoft Research Cambridge, UK) Doctoral Symposium Chair: Karen Henricksen (University of Queensland, Australia) Publicity Chair: Egemen Tanin (University of Melbourne, Australia) Program Committee: * Christiana Amza (Toronto University, Canada) * Ozalp Babaoglu (University of Bologna, Italy) * Mark Baker (independent consultant) * Alberto Bartoli (University of Trieste, Italy) * Yolande Berbers (Leuven University, Belgium) * Gordon Blair (Lancaster University, UK) * Michele Colajanni (University of Modena, Italy) * Geoff Coulson (Lancaster University, UK) * Fred Douglis (IBM Watson, USA) * Pascal Felber (University of Neufchatel, Switzerland) * Indranil Gupta (University of Illinois, Urbana-Champaign, USA) * Franz Hauck (Ulm University, Germany) * Bettina Kemme (McGill University, Canada) * Anne-Marie Kermarrec (INRIA Rennes, France) * Fabio Kon (IME/USP, Brazil) * Ihor Kuz (NICTA, Australia) * Doug Lea (Oswego State University, USA) * Mark Little (Arjuna Technologies, UK) * Ted McFadden (Latent Ventures, USA) * Philip McKinley (Michigan State University, USA) * Jishnu Mukerji (HP, USA) * Bernard Normier (ZeroC, USA) * Tamer Ozsu (University Waterloo, Canada) * Gian Pietro Picco (Politecnico di Milano, Italy) * Frank Pilhofer (Mercury Computer Systems, USA) * Misha Rabinovich (Case Western University, USA) * Alexander Reinefeld (ZIB, Berlin) * Luis Rodrigues (University of Lisbon, Portugal) * Peter Steenkiste (CMU, USA) * Stefan Tai (IBM Watson, USA) * Amin Vahdat (UCSD, USA) * Aad van Moorsel (Newcastle University, UK) * Steve Vinoski (IONA, USA) * Craig Wills (Worchester Polytechnic Institute, USA) Important dates: Submission deadline: April 3 Notification of acceptance: July 10 Camera-ready copies: September 1 Submission guidelines: Research papers: Research papers are to be submitted electronically via the online submission system: http://subm2006.middleware-conference.org/ Through this system, you will be requested to upload the file of your paper (PDF format) to the conference server (please avoid bitmaps!) Papers must not exceed 20 pages, including abstract, all figures, all tables, and references. Papers should include a short abstract and up to 6 keywords. Please also fill in the appropriate information in the online form. Submitted papers should follow the formating instructions of the Springer LNCS Style (please check the Information for Authors page at Springer at http://www.springer.de/comp/lncs for style and formatting guidelines). Submitted papers may not be submitted for conference publication, journal publication, or be under review for any other conference or journal.
From Bobby Woolf’s latest;
The beauty of interoperability is that two systems developed completely independently can still work together. Magic? No, standards (or at least specifications, open or otherwise); see Open Standards in Everyday Life. Consider a Web services consumer that wants to invoke a particular WSDL, and a provider that implements the same WSDL; they’ll work together, even if they were implemented independently. Why? Because they agree on the same WSDL (which may have come from a third party) and a protocol (such as SOAP over HTTP) discovered in the binding.
So what about the services that expose WSDL that the client doesn’t know about? What’s the possibility of those components ever interoperating without software upgrades? Zero, of course. That situation is called a silo, and I thought one of the main objectives of this whole SOA thing was to avoid them … wasn’t it?
Sigh … how many ways do I have to keep saying the same thing?!?!
I started writing this before Jeff’s hilarious Lego piece (that must have been fun to put together 8-), but if anything, it just re-emphasized the need for me to write this, because Jeff makes the same mistake that most of the rest of the industry is making; believing that the SOAP processing model is the analogue of the Lego brick.
For an apples-to-apples comparison of SOA and Lego, one needs to realize that the analogue of the Lego brick is actually the WSDL document that describes the service. Lego works as it does because each brick exposes the same application interface, not just because each brick is made from the same plastic (which makes a better SOAP analogue, IMO).
Just check out his example of a non-recombinant system here; it’s not recombinant because it’s topped off with a piece which exposes a different “WSDL” than other “services”.
Jeff says a lot of valuable things in his piece that resonate with me, including;
The fundamental notion is that the true uses of the functions/data will not be known until after the system is put into production.
The future of software is about the creation and utilization of building blocks. It is about letting our users play with their Lego’s.
(modulo the fact that the plural of Lego is not “Legos” 8-)
… it’s just unfortunate that they all resonate with me from a Web/REST POV, not from an SOA POV.
