Ah, metrics! That's important. What about the timing? Some people talk about business value after completing integration. To the customer, it was just an integration project, but it somehow became a case study on SOA after the project was finished. lol
Seems like my holiday season has ended. I'm off to another project or two. :-) H.Ozawa 2010/1/4 Steve Jones <[email protected]> > > > I disagree. While Integration solution talk about business value their > intent is purely technical, the business value is a hoped for by product of > the integration. > > This for me is the difference that IT needs to make, namely the switch > between burbling about technology and claiming mythical value > against committing against business value and then worrying about the > technology. > > I saw one IT presentation last year that talked about "business value" > without a single quantifiable metric against which this value would be > proven. That is what business driven SOA should be doing, starting with the > service, capabilities, metrics and measures and THEN worrying about how best > to support them with technology. > > Steve > > > 2010/1/4 Hitoshi Ozawa <[email protected]> > > >> >> Intent? If intent is all the difference, they're probably the same. It's >> very easy to talk about having intention to deliver business value and just >> do what IT have been doing over the years. :-) >> >> H.Ozawa >> >> 2010/1/2 Steve Jones <[email protected]> >> >> >>> >>> Technology v Business intent. Integration solutions are purely about the >>> connection of pieces of technology that may at a 2nd remove deliver a >>> business value. A service is directly about the delivery of the business >>> value. >>> >>> In other words (and I think the SOA-RM does this brilliantly) its the >>> difference between technology infrastructure (the Execution Context in the >>> SOA-RM) and the actual capabilities and service. Integration solutions >>> place the technology at the heart and then plug things together, SOA places >>> the capabilities and services at the heart and relegates the internals to >>> just plumbing. >>> >>> Steve >>> >>> >>> 2009/12/29 Dennis Djenfer <[email protected]> >>> >>> >>>> >>>> Ok, so what is the behavior of your solution that makes it qualify as >>>> service oriented and not as a pure integration solution? >>>> >>>> >>>> // Dennis Djenfer >>>> >>>> >>>> Michael Poulin wrote: >>>> >>>> Qualification 'into service', IMO, is not in the interface but in >>>> behavior of the entity. >>>> - Michael >>>> >>>> ------------------------------ >>>> *From:* Dennis Djenfer <[email protected]> <[email protected]> >>>> *To:* [email protected] >>>> *Sent:* Sun, December 27, 2009 5:11:11 PM >>>> *Subject:* Re: [service-orientated-architecture] Descriptions vs >>>> Contracts >>>> >>>> >>>> >>>> I wonder if that is enough to qualify as a service oriented solution. >>>> With that kind of reasoning a Web Service slapped on a database because an >>>> application needed the data would be service oriented. >>>> >>>> // Dennis Djenfer >>>> >>>> >>>> Michael Poulin wrote: >>>> >>>> Service orientation in my solution is in Documentum service offered a >>>> service (via JMS) and all interested (the ATG Dynamo servers) were able to >>>> use it. In the contrast, the Documentum's solution was based on blind push >>>> of information to pre-defined IP address with no mechanism for the >>>> consumers >>>> to change them at wish (but only through the negotiation with and >>>> reconfiguration of the Documentum server). I think that my solution was >>>> service-oriented while the Documentum's one was much more traditional P2P >>>> integration. This is the about "the right way of thinking" or freedom >>>> for consumers (specific to SO) rather than technology comparison. >>>> >>>> - Michael >>>> >>>> ------------------------------ >>>> *From:* Dennis Djenfer <d...@algonet. se> <[email protected]> >>>> *To:* service-orientated- architecture@ yahoogroups. >>>> com<[email protected]> >>>> *Sent:* Sat, December 26, 2009 10:23:30 PM >>>> *Subject:* Re: [service-orientated -architecture] Descriptions vs >>>> Contracts >>>> >>>> >>>> >>>> I don't get why your solution is service oriented. All I can read from >>>> your exemple is two kind of solutions for an integration problem. They have >>>> different technical solutions and quality attributes, but I don't get why >>>> one of them is service oriented. >>>> >>>> // Dennis Djenfer >>>> >>>> >>>> Michael Poulin wrote: >>>> >>>> I think, Sun Tzu in his >>>> *T<http://www.1000ventures.com/business_guide/crosscuttings/cultures_sun_tzu_the_art_of_war.html>he >>>> Art of >>>> War<http://www.1000ventures.com/business_guide/crosscuttings/cultures_sun_tzu_the_art_of_war.html> >>>> * has given us the receipt for SOA implementation for downtime >>>> saying"Nothing >>>> is as important as having the right way of thinking." >>>> >>>> SO is about SO thinking; SO needs technologies and expensive systems at >>>> the very last, if ever, moment. SO is not in technologies like BPEL and >>>> others. You can build service orientation into regular code if you think >>>> first about it. >>>> >>>> For example, several years ago I had a problem to solve: our Documentum >>>> server prepared Web content, which had to be used by the Application/ Web >>>> Servers (ATG Dynamo that time) to publish on the Web, but did not notify >>>> ATG >>>> Dynamo when the content was ready. Our Business publisher authored the >>>> content but could not manage the publishing time. In my SO Solution, I >>>> placed Documentum' s meta-file about prepared content into MOM/Topic and >>>> made all ATG Dynamo servers to subscribe to the Topic announcements. The >>>> ATG >>>> Dynamo servers used to be re-booted nightly but they were able to get all >>>> missed information and the new one due to the durable subscription to the >>>> MOM Topic. Where ATG Dynamo servers were shut down and where they (or their >>>> replacements) came up on-line (i.e. their IP address) did not matter to the >>>> solution. [When Documentum learnt this solution from us, they provided a >>>> free integration Documentum-ATG Dynamo via Web channel. In their >>>> solution, Documentum not only updated the data-store with the prepared >>>> content but also sentthe appropriate Web 'requests' to the registered ATG >>>> Dynamo servers. It looked fine except for the cases when ATG Dynamo servers >>>> lost all information when being down and had to get on-line with exactly >>>> the >>>> same IP address they registered with the Documentum server before. This was >>>> pure integration solution while I can consider my solution was much more >>>> service oriented.] >>>> >>>> - Michael >>>> >>>> ------------------------------ >>>> *From:* Hitoshi Ozawa <htshoz...@gmail. com> <[email protected]> >>>> *To:* service-orientated- architecture@ yahoogroups. >>>> com<[email protected]> >>>> *Sent:* Fri, December 25, 2009 10:56:29 PM >>>> *Subject:* Re: [service-orientated -architecture] Descriptions vs >>>> Contracts >>>> >>>> >>>> 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 <jones.steveg@ gmail.com<[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 <htshoz...@gmail. com <[email protected]>> >>>>> >>>>> >>>>>> So Steve, you're designing all your services these way. >>>>>> >>>>>> H.Ozawa >>>>>> 2009/12/23 Steve Jones <jones.steveg@ gmail.com<[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 <htshoz...@gmail. com <[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 <jones.steveg@ gmail.com<[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 <htshoz...@gmail. com<[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 <jones.steveg@ >>>>>>>>>> gmail.com<[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 <htshoz...@gmail. com<[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 <herbst_andrew@ >>>>>>>>>>>> yahoo.com<[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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> >>> >> > >
