On 01/07/06, patrickdlogan <[EMAIL PROTECTED]> wrote: > > > > > > > > > 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 used to but it was too lightweight :) Ahh Mayan Calendars > > > > 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". Its something defined in the OASIS RM. The execution context is in effect (and its better to read the formal definition than listen to me after England have just lost) the bit that makes the call from A to B happen. Its the technical infrastructure bit. > > > > 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. Must have missed the eventing bit of HTTP... but what I'm trying to say is that function has to happen somewhere, Javaspaces act as a great co-ordination place, but somebody somewhere still has to write the bit that actually does something. > > > > 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. The Web in itself provides zero value, its the INTERACTIONS that provide the value. > > > > 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. And how do you tell the consumers that? Someone has to document what you've just described so consumers know about it and know how to interpret it. Ease of developer use at this level isn't a major driver (IMO) the WSDL/SOAP equivalent of what you have is a Java/C# call of x = LightBulb.getState(); LightBulb.setState(x); LightBulb.delete(); Because nobody in their right mind should be coding to the WSDL. > > > > 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. Nope, its less important. HTTP is the bit that gets from A to B, the others define the functionality (the value). REST is a long way from having the monopoly on HTTP, even CORBA can be tunnelled over it. HTTP is fine and dandy, but important? I'd have to disagree. > > -Patrick > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Great things are happening at Yahoo! Groups. See the new email design. http://us.click.yahoo.com/TISQkA/hOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> 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/
