Glad you liked it.... comments below On 17/07/06, Michael Poulin <[EMAIL PROTECTED]> wrote: > > > > > > > > > Hi Steve, > > I am sorry, it took me that long to read your document. > > > I do vote with both hands for the concept you describe in your OASIS > Draft. You have many very good points and the statements are clean and > clear. My the most favorite one is the last sentence on the page 28 (for > those who has not read the document, which I recommend to read everybody, > that sentence is "It's the Services Stupid") > > On this note, let me make a few comments: > 1) I would add a definition of a Business Service to the Section 8 > 2) The title of the Section 9.2 doesn't seem reflecting the content. I > really expected to find a reference to, at least, the Language To Determine > Services while I found an approach to establishing a terminology in the team
My bad, this is what I meant by the "language". > 3) Section 10.4.1 is named Virtual Services, i.e. hypothetical service, > and given example is a Portal. To me, portal is not a service but rather a > tool. You have the right ( to me) word in the text: it is Service Façade, > i.e. façade to the Services. Service Façade is not an aggregated service > either. What I mean by virtual services is that service that in themselves have no direct implementation of the capabilities. From an OASIS RM perspective while these service exhibit the real-world effect of the capability they don't actually do anything other than pass on the requires. The reason not to use Facade is the because in part Virtual Services could be aggregations , so while internally there could be 6 services with 20 capabilities the virtual service only shows 1 capability from each. > 4) In the Section 10.4.3., Technical and Support services include > "Those with common or similar basis, but differing drivers or > implementation". If "similar basis" may be interpreted as similar technical > function, e.g. e-mail service, I would appreciate service redundancy via > different implementation. In such case, if one service does not meet client's > requirements or its SLA, another similar service may be engaged. However, I > have a problem with interpretation of "drivers" in that context. > 5) Another question for the same Section 10.4.3. is: what is the need > for recognizing specialized business services that have "common base" but > still different due to their specialization? They may share certain characteristics that mean they will have similar governance models, skills requirements or even just be able to share a common infrastructure. > 6) In the Section 11.2.4., I have expected much more details on the > "value contract for the service". I believe definition of such contract is > the most crucial instrument for SOA Services that would allow sensible, > business oriented inter-communication between Services. That is, the role of > the contract (I call it SLA for particular client) is important enough to > get a place in Methodology for Service Architectures document. Fair enough point, I didn't include it much in that as this was the feature of my IEEE paper (http://dx.doi.org/10.1109/MS.2005.80) but you've just made me slap my forehead in fustration at something else I've just written. > Thank you, > > - Michael Poulin > > > > Steve Jones <[EMAIL PROTECTED]> wrote: > > > > I thought I'd start a thread aimed at the other end of the scale from > REST v SOAP v CSV :) > > What I was wondering is if there are any other people out there using > Service as a concept to model the business, rather than seeing it as a > implementation approach. The methodology paper > > (http://www.oasis-open.org/committees/download.php/15071/A%20methodology%20for%20Service%20Architectures%201%202%204%20-%20OASIS%20Contribution.pdf) > I released last year was specifically aimed at this area and I've had > some decent feedback around the concepts and approach, mainly from > people working at the enterprise level. > > I know that IBM's CBM > (http://www-1.ibm.com/services/us/bcs/html/bcs_componentmodeling.html) > approach takes a similar view, if a little bit bigger in scale and > complexity. > > The theory behind this sort of work is that OO was important not > because of the technology change but because of the mental shift it > made in IT. SOA is important for a similar reason, but rather than > effecting the implementation of system internals it impacts the actual > definition of the enterprise and the systems themselves. Historically > IT has failed to deliver in no small part due to an obsession with the > implementation mechanism (technology) rather than on the problems and > challenges from the perspective of the business. > > > > > > ________________________________ Do you Yahoo!? > Next-gen email? Have it all with the all-new Yahoo! Mail Beta. > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Something is new at Yahoo! Groups. Check out the enhanced email design. http://us.click.yahoo.com/SISQkA/gOaOAA/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/
