|
|
| Service Oriented Enterprise |
|
|
Saturday, July 24, 2004 Distributed Noun Processing Lately, I've been very concerned about the state of Service Network designs. The service oriented world puts an emphasis on verbs (authenticate, format, translate, etc.) This forces the knowledge about nouns to be distributed across a set of services. Service oriented programming usually looks like a pipelined or staged computing model. Often the messages that are being processed refer to the same schema. However, the processing instructions vary according to the specifics of the schema. Let's say that we have a four stage service plan: Step 1 - pull message off of bus and authenticate Step 2 - transform message according to local needs Step 3 - process business service Step 4 - business services encapsulates a call to a data service Each service focuses on one stage and will typically have a control language (DSL) for performing functions on the nouns (business schemas) that are passed to it. What seems to be missing from most commercial and homegrown services is the ability for a service to easily add or modify the nouns that it is aware of or modify the routines that perform the functions on those nouns. This is a huge issue. For some reason, people continue to focus on the virtues of SOA/WS-*; loose coupling, reusability, etc. However, they are not talking about the new problem: Distributed Noun Processing. The realization of a use case is now spread across multiple services. Changes to nouns will likely result in changes to all services in the plan. It is likely that the DB schema changes, the O/R plan changes, the XSLT changes, the message type in the WSDL changes, the evaluation logic in the business class changes. The impact of noun changes must be measured (part of the agility/fragility index). Now a seasoned person might say, "but that is the current state of art as well". Yes - this is true. Generally speaking J2ee and .Net fail to provide facilities for cross-cutting functional concerns across their tiers. So, the good news is that we're only failing as bad as we did last time. However, I think we failed pretty hard last time. As we look at services, we must identify the best programming model associated with the functionality. Generally speaking, this means that services rely on specialized verb engines. These verb engines usually rely on their own DSL (think DML and DDL for relational databases, axiom languages for business rules, transformation languages, etc.) As the number of DSL's increases, so does the importance of coordinating changes across them. At Momentum, we have been spending a significant amount of time looking at this issue. We have not found the magic "DSL propagation language" yet, nor do we expect to anytime soon. The MDA world has made progress but is still very disconnected from the service oriented world. For now, the effort is either done by hand or with some tooling that helps to automate impact and change management across a set of predetermined DSL's. Failure to manage the service network from a functional perspective will likely lead to excessive costs for new application introduction and change management. Trust me - get it under control now. posted by jeff | 7:11 AM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
