> (in our case ACK/NACK messages) were made, but how far do you go
> with reliability and at how many layers? At the moment, I think we
> should be gravitating more towards a [SMTP] style of asynchronous
> messaging with reliable transfer protocols between each step as is
> reflected in the current documents, but then if you ever want to
> leverage unreliable transfer protocols, you're in trouble.
> Fortunately, RRMTP seems to be looking good so far as a lightweight,
> reliable transfer protocol that's easy to implement, but our "real"
> implementation is currently in the final rounds of testing and not
> yet deployed.
Have you looked at the Erlang OTP system? That is the best SOA
framework in production that I am aware of. They seem to have done all
kinds of things well, the core of which is an unreliable message
passing capability. All kinds of patterns can be built on top of that,
and a number of them have been captured the OTP system itself as
reuable "behavior" modules. That is something to emulate I think, if
not use directly.
> We are fairly unique in the approach we've taken based on what I see
> when I talk to other people trying to get their heads around SOA or
> who are currently implementing it, and I think a lot of what we're
> doing is ahead of some of the thinking out there.
Not only is it ahead of a lot of thinking, it is ahead of even more
"non-thinking". One big problem of premature specification is that
psychology has pretty much proven that our subliminal selves kick in
and subtly drive our future behaviors in ways to appear consistent
with past commitments. In several ways we literally stop thinking and
have to fight deliberately at the conscious level to think through
subliminal forces.
> However, it doesn't apply in all cases. Change any one of the
> fundamental assumptions within the environment and all bets are off.
Well, you have an architecture that can be reasonably comprehended and
evaluated. At least I think I can comprehend it, while I have trouble
seeing a truly usable architecture in most of what passes for SOA
definitions elsewhere.
> As a bit of an exercise to try and apply what I've learned so far,
> I'm trying to figure out the best hybrid approach between what I
> would consider the two extremes I've seen, ours and the SOAP-centric
> WSA, might be. There's also WOA or "pure REST" to consider as well,
> and I have some ideas on bringing them all together. However, I
> haven't been thinking seriously about it enough yet to have any
> concrete thoughts.
Looking forward to that.
-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.
