> companies organized their projects according to expected revenue /
> cost-savings of a service, and also delivered them incrementally,
> there are big financial implications on cash flow and working
> capital. This doesn't really 'require' SOA, though I think it's
> definitely useful that there's an architectural appraoch that
> complements agile delivery methods.
Yes, I have seen this potential benefit fallout of the "services"
discussion where previously more effort was required to bring this
approach to the table for a big program.
> - composing activities (human and/or automated) together with
> scripting languages & services-oriented BPM tools can reduce lead
> times (elminate waste) and also make "continuous improvement" /
> kaizen more of a reality (work standardization through 'standard
> contracts')
I have very little experience with BPM tools, but I have a ton of
experience with "scripting" languages, and can attest to their
benefit. If BPM tools provide similar benefits then that would be
good. Again just bringing better tools and lean development practices
is the benefit. If the SOA discussion helps those tools and practices
get in the door then that would be a significant side benefit of SOA.
> The area that I'm curious about is how to handle continuous (over
> time) changes in service granularity, which would be the real test
> if SOA can help Lean procesess out. There are interesting
> discussions to be had on how to track & tear dependencies, isolate
> others from these changes through extensibility & versioning, etc.
Yes. Here we've put together a continuous integration environment with
a specific progression. As subsystems change and are tested, they get
promoted out to the next level of integration testing. We specify what
to test when, with mock objects and then with real integrated
subsystems, etc. SOA makes this more complex, I don't see how to do an
SOA without this kind of discpline and tool set.
> This challenge is partly why I find REST so fascinating, in building
> robust operations that can withstand evolution fo the data
> representations underneath. The area I'm not quite sure I agree with
> is how to evolve the representations themselves, especially when
> we're dealing with structured data. We've never really had a good
> answer to this (build another view, in the relational world -- add
> another tag, in the XML world).
XML is funny. On the one hand it is a text format on the other hand we
wish it were a data model, and we've got several partially complete
options for defining any number of XML-oriented data models.
The only thing that the HTTP approach to SOA adds to this is that
historically web systems have ben relatively fast and loose with HTML,
etc. The "semi-formal" aspects of web systems have to emphasize a lot
more of the "formal" aspects of "semi-formal". That's more of a
mindset thing than a technology thing.
People can tend to assume that using HTTP implies less formal data
representations, even though their formal SOAP systems are running on
HTTP already. Just take out the SOAP and more or less leave the
formal. A temperate use of XML Scheme seems to work OK, but as you
wrote, it is the *evolution* that counts and I don't have much
experience with significant evolution in this scenario.
> I hear REST advocates discussing the pervasive use of RDF topic
> maps, but in my world they never really were considered, and aren't
> likely to be. XML Schemas seem to be the approach du jour, though
> their versioning and extensibility techniques are awfully
> complicated. I'm curious how and when we as an industry will address
> that.
Yes, for now, less-is-more when it comes to using XML Schemas I
think. We've identified some modest practices to use when defining,
testing, and releasing XML Schemas. e.g. don't generate code, or if
you do, don't place other dependencies on the generated
code. Demonstrate flexibility in the tests. Validate schemas in test,
but not in production.
-Patrick
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
