I think you've hit the major difference we're having. I'm in an actual project and tailoring my service so they can actually be implemented with the current available technology, development members, and other constraints. Also, with the economic slow down, it is also necessary to reduce cost. There was a mention of BPEL in the other thread, and I think the basic technology is interesting, but the current situation requires too knowledge of too many specifications that it almost impossible to educate development members to complete a project in time. Of course, in a small project, I can just do it myself but in a large project, that's impossible.
SOA is dying not because the theory behind it is bad, but that what most people are preaching can not currently be implemented in a project. The tight economy is also sifting the emphasis from "to be" more toward "can be". Anne's cartoon showed a "SOA dinosaur", but IMHO the dinosaur really isn't the concept of SOA itself, it more of us who's not adjusting to the current economic market. Happy Holidays, H.Ozawa 2009/12/25 Steve Jones <[email protected]> > > > I'm designing them in this way but unfortunately in implementation there > isn't the technology to support this stuff. WS-Contract or WS-SLA never > happened and there isn't anywhere near the formalism required. > > Steve > > > 2009/12/23 Hitoshi Ozawa <[email protected]> > > >> >> So Steve, you're designing all your services these way. >> >> H.Ozawa >> 2009/12/23 Steve Jones <[email protected]> >> >>> >>> >>> I can't see why not, although I'd reword it to be >>> >>> In order to ship the carton a valid set of legal constraints, written in >>> French, must be agreed. >>> >>> >>> Take Air Traffic Control, there are two official global languages for ATC >>> there is English (used in 99% of the world) and there is French (guess where >>> that is used) but they are both official languages at the service >>> description level. Now some people can constrain their description to say >>> "we only accept English" but this is still at the service description level >>> as an individual contract (with a plane) has not yet been entered into. >>> >>> Steve >>> >>> >>> 2009/12/22 Hitoshi Ozawa <[email protected]> >>> >>>> >>>> >>>> We're talking about service description. Is it alright to have "ship the >>>> carton with a valid set of legal constraints in French"? >>>> >>>> H.Ozawa >>>> >>>> 2009/12/23 Steve Jones <[email protected]> >>>> >>>> >>>>> >>>>> I can't see why a contract of send invoice via SOAP would be a problem >>>>> with the description being "send invoice", why would it be a problem? >>>>> >>>>> I think we are in danger of disappearing into semantic holes. I could >>>>> argue that if the objective (service description) was to woo a lady then >>>>> the >>>>> choice of the language (service contract) could be either English or >>>>> French. >>>>> In French we could take the Cyrano de Bergerac approach while in English >>>>> we >>>>> could fall back on the Bard of Avon. Here the language is the piece that >>>>> seals the deal and is linked to the specific consumer of the service, in >>>>> other words the language chosen (the contract) is linked to the specific >>>>> engagement between the producer and consumer. >>>>> >>>>> Steve >>>>> >>>>> >>>>> >>>>> 2009/12/22 Hitoshi Ozawa <[email protected]> >>>>> >>>>> >>>>>> >>>>>> Hi Steve, >>>>>> So are you implying "send invoice using SOAP" is alright? >>>>>> If you are, I sure would like to see the system with such a design. >>>>>> :-) >>>>>> >>>>>> French and English are languages people use to rely concepts. British >>>>>> law is a concept. Concepts described in the British law does not (should >>>>>> not) change whether it's written in English or in French. >>>>>> >>>>>> H.Ozawa >>>>>> 2009/12/21 Steve Jones <[email protected]> >>>>>> >>>>>> >>>>>>> >>>>>>> I actually think that French and English is fine. It is like having >>>>>>> a shipping contract, there are a huge number of different legal >>>>>>> jurisdictions that you could potentially use to ship the product from A >>>>>>> to B >>>>>>> (the description) but when you formalise the contract you pick a single >>>>>>> legal country as your escalation point. >>>>>>> >>>>>>> So in other words the description of A to B just says "ship the >>>>>>> carton with a valid set of legal constraints" while the contract says >>>>>>> "ship >>>>>>> the carton with British Law as the legal framework" >>>>>>> >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> 2009/12/19 Hitoshi Ozawa <[email protected]> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Andrew, >>>>>>>> I think you're beginning to understand the concept, but your example >>>>>>>> is missing the point. >>>>>>>> Your analogy with French and English is inappropriate unless you're >>>>>>>> thinking of a translation service. >>>>>>>> >>>>>>>> Service description describes the semantic capabilities of the >>>>>>>> service while service contract describes the set of rules used in an >>>>>>>> instance of an interaction. >>>>>>>> H.Ozawa >>>>>>>> 2009/12/18 Andrew Herbst <[email protected]> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Greetings: >>>>>>>>> >>>>>>>>> Another question from an SOA neophyte. Thanks for responding to >>>>>>>>> my earlier questions. >>>>>>>>> >>>>>>>>> So, roughly speaking, a service description is like me announcing >>>>>>>>> to the world: “I can interact in French *or* in English”, >>>>>>>>> whereas, a service contract is like me agreeing to speak French with a >>>>>>>>> specific other person in the context of some very specific >>>>>>>>> interaction. >>>>>>>>> >>>>>>>>> I realize this is a very basic question, and it may well not really >>>>>>>>> be the aim of this group to deal with such basic things. I will >>>>>>>>> therefore take no offence if no one addresses this. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Andrew Herbst >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > >
