This post originated from an RSS feed registered with Agile Buzz by Steven E. Newton. Original Post: Why Web Services Matter Feed Title: Crater Moon Buzz Feed URL: http://www.cmdev.com/buzz/blosxom.cgi?flav=rss Feed Description: Views and experiences from the software world. Latest Agile Buzz Posts Latest Agile Buzz Posts by Steven E. Newton Latest Posts From Crater Moon Buzz

COM(+)

• Good technology conceptually
• Lots of market
• Tied to Windows platform
• C/C++ glue
• soon to be obsolete?
• No vendor-neutral standard

CORBA

• OK technology, not great
• platform-neutral
• OMG Standard
• complex
• expensive?
• so-so language support
• Expensive(?), so-so tools

EJB

• Java-only
• vendor-neutral
• heavyweight, overblown
• OK for session beans -- services

Web Services

• Language-neutral
• Vendor-neutral
• Platform-neutral
• W3C Standard
• As light or as heavy as you need
• Lots of tool support

Words of Wisdom

Distinguish between the public interface of a module, which can change as long as it's a within-team usage, and the published interface, which must be immutable and adhere to the contract.

"reuse [is] undervalued and insufficiently rewarded by the sponsoring organizations."

"Services are grouped into coherent, contractual units called ''interfaces''."

"By focusing on the notion of a contract, the service perspective introduces an important distinction between the specification of a component (what it does) and its implementation and executable forms (how it does it). This distinction is fundamental to the management of dependencies between components and begins to address the important requirement to be able to replace a component with minimal impact on the consumer, often referred to as "plug-and-play". "

Create detailed, well-defined interfaces. Java supports the interface explicitly.

Design-by-contract

Prevention steps for clients (callers)

1. Make method preconditions as strong as possible
2. Make method postconditions as weak as possible.
3. Ensure correct field invariants.
4. Settle on and do not change class/interface "gender"
5. Prefer creating a new interface to changing an existing one, even if the change does not break compatibility.
6. Define checked exception semantics carefully.
7. Publish (outside the team) APIs parsimoniously.

1. Deprecate and Forward
2. Create a new package
3. Any new methods that add/remove params, overload and call the old methods.

1. Clarify how APIs work when the spec is imprecise
2. Fix Broken Windows
3. Fix '''only''' Broken Windows
4. Note incompatible changes in the Release Notes

Component Infrastructure

• Packaging
• services-core jar file
• Physical delivery m 1000 echanism? Dev Library
• Version numbers on jar file or in manifest?
• Distribution
• Description of component
• Web site
• Browsable docs?
• What sort of UML Diagrams?
• What other StandUP artifacts, eg. Use Cases, should we have?
• Integrity
• Independent deliverable (high cohesion, low coupling)
• Document version dependences

Articles

• Building Systems from Pieces: Principles and Practice of Component-based Software Engineering by Alan W. Brown http://www.alanbrown.net/files/AWBChapter.zip
• Public versus Published Interfaces http://www.martinfowler.com/articles/published.pdf, by Martin Fowler
• Design By Contract http://archive.eiffel.com/doc/manuals/technology/contract/

Evolving Java APIs

• http://eclipse.org/eclipse/development/java-api-evolution.html
• http://java.sun.com/j2se/1.4.2/compatibility.html
• http://jakarta.apache.org/commons/versioning.html

Component Technologies

COM

• From CPP to COM http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncomg/html/msdn_cpptocom.asp?frame=false&hidetoc=true
• Dr GUI's Gentle Guide to COM http://www.microsoft.com/Com/news/drgui.asp

CORBA

• Introduction to CORBA http://developer.java.sun.com/developer/onlineTraining/corba/

EJB

XPCOM

• The Mozilla Project's XPCOM home http://www.mozilla.org/projects/xpcom/