January 29, 2004

Features of a Service Oriented Language

Jeff Schneider posts some interesting ideas on his desirable features in a Service Oriented programming language:

Service Oriented, Protocol Connected, Message Based

Here are some casual thoughts on what I would like to see in a service oriented language. This is my first attempt at this... I'm sure I'll get some feedback ;-) and will update it.


  • The service is a first order concept, both sending and receiving
  • Support for the strong interface (think WSDL)
  • Mandatory support for Long Running Transactions
  • Faults and Compensation are first order
  • Protocols for transport and fulfillment of NFR are intentionally left out of scope


  • Message is a first order concept
  • Message is defined using a platform independent markup
  • Support for message correlation properties; helpers for distributed state mgmt
  • Universal addressing scheme (assumes router)

Types / Vars

  • Typing & vars are consistent with message system
  • Remote variables (think REST)

Functional Containment

  • The 'service' is a container (and managed)
  • The 'object' continues to live. Objects are contained in services.

Invocation and Service Hosting

  • WSDL's can be imported directly into the runtime. Operations and messages become first order citizens.
  • Access & manipulation of binding / listener is first class.
  • Language assumes that all systems are peer (both client and server)

Schema Manipulation

  • DDL: Import / export / create / modify (consistent with type system)

Data Manipulation

  • DML: transform (consistent with type system)

Flow Control

  • Usual branching & looping
  • Parallel execution; parallel joins (first order)
  • Forced sequential processing

Event Based

  • Events are a first order concept
  • Time & activity based events

Metadata Ready

  • Declarative metadata becomes a first order item (see jdk1.5)
  • Service oriented loading / unloading of metadata / models / gen'd code at runtime
  • Reflective knowledge of declarative non-functional polices (think ws-policy access)

Base Service & Extensions

  • Concept of an extendable base service
  • Service may have multiple interfaces
  • Aspects may easily be applied to service
  • Language is extended via "more services" not "more syntax"

Service Network Awareness

  • Service is aware of the network that it lives in (topology, routers, etc.)
  • Service is aware of service-enabled remedies to non functional requirements (Virtualization, etc.)
  • Service has the ability to modify the service network at runtime

OK. So a good question is, "which of these are part of the 'language', which are 'service libraries' or other?" I'm in favor of the *least* amount of required syntax possible. But, I like the idea of having *mandatory* service library extensions.

[ Service Oriented Enterprise - Features of a Service Oriented Language ]

There's definitely some food for thought for language / programming tool designers in that list!

Entry categories: Programming
Posted by Jorgen Thelin at January 29, 2004 11:00 PM - [PermaLink]
Traceback List