|
|
| Service Oriented Enterprise |
|
|
Wednesday, January 14, 2004 Features of a Service Oriented 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. Services - 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 Messages - 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. posted by jeff | 6:45 AM Sunday, January 11, 2004 Clarification on Orchestration In a recent ZapThink article, which has an amazingly similar name as my blog.... ;-) I found this:  Ok. Pretty close... but I just want to clarify a bit. First generation orchestrations are typically used as a process-integration or a system-to-system integration mechanism. This means that the orchestrations are VERY message oriented and the granularity between the operations are almost always coarse-grained. In addition, there is a logical difference between "service orchestration" and "process orchestration". Typically, service integration is lower level. It involves the many calls to "technical services" and attempts to hide higher layer calls from the ugly technical details and are often exposed as a single business service. "Process orchestrations" are orchestrations that occur at a higher level. In these cases, virtually all of the calls are to other 'processes' and tie together a digital business process. Now - in the future (2005+), I expect to see more fine-grained web services being used in 'composition' tools (a close cousin to orchestration). In this setting, more emphasis will be placed on in-lined services and performant service compositions. But for now, this is outside of the scope of what we typically classify as 'orchestration' or 'choreography'. posted by jeff | 11:03 AM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
