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 Its 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 doesnt 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
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.
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 clients 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?
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.
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.
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_componentmod eling.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 LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
