> Whoooo hoooo... indents....
Use emacs. Just do "c-x ." (set-fill-prefix) with the cursor just
after the leading two characters... "> " Then "m-q"
(fill-paragraph-or-region) will do indents for you.
What? You don't use emacs? 8^)
> I'm really not seeing this at the architectural level, if I have 30
> services which each have 4 capabilities then I have 30 services with
> 4 capabilities at the architectural level. The implementation
> technology should be the most appropriate and simple, but the LEAST
> important question is how to implement the execution context, that
> is just how the consumer access the service, and in 2006 we should
> stop pretending that this actually matters.
I am not sure what you mean by "execution context".
> Javaspaces act (lynch me Dan when I get it wrong) as a co-ordination
> point for systems, they don't actually provide function themselves
> but the mechanism for exchange.
Javaspaces is a mechanism for transfering things around. HTTP is more
like that than it is like defining procedures with SOAP/WSDL.
> From a consumer and producer perspective that again is about the
> execution context which is the piece that provides no actual value
> in itself.
The web provides no value to you? I think that is rare.
> Really not seeing this. Maybe I'm old school but I'd really quite
> like people to understand how to define an interface and to
> understand the architectural impacts of choices that are made. HTTP
> removes none of that architectural thinking (you still need to know
> the service has X capabilities and what they do) and just gives you
> a different way to build the execution context.
The other messages over the last day provide a better example than I
could. The lightbulb one is nice and simple...
You have some number of lightbulbs that can be "on", "off", or
"dimmed x percent"
The HTTP interface is...
GET [uri-for-a-lightbulb]
which returns some representation of the current state of the
lightbulb with that uri, e.g.
<lightbulb state="dimmed 50 percent"/>
And...
PUT [uri-for-a-lightbulb]
Content-Type: application/lightbulb+xml
<lightbulb state="on"/>
which changes the state to "on".
And...
DELETE [uri-for-a-lightbulb]
which deletes the lightbulb.
> REST is an IMPLEMENTATION pattern, not an architectural pattern. Its
> part of the Development and Deployment choices not part of the
> architectural approach. The problem with SOA is that no-one likes to
> admit when something is just part of SOD.
However you categorize it, there are big implications for your world
based on when you implement HTTP and when you do not.
Choosing HTTP or not is not the same as choosing Java, C#, or Ruby.
-Patrick
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
