OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: understanding of SOA ecosystem scope


ok – I think I see what you mean.  Instead, monitoring of service internals may actually feed things that the provider then gives via their description, but it is a bit mre indirect.  Service provider should not provide the actual internals as that could even be a security “no-no”.

 

 

 

From: Lublinsky, Boris [mailto:boris.lublinsky@navteq.com]
Sent: Sunday, April 03, 2011 10:58 PM
To: Bashioum, Christopher D; Lublinsky, Boris; mpoulin@usa.com; Laskey, Ken; soa-rm-ra@lists.oasis-open.org
Subject: RE: understanding of SOA ecosystem scope

 

And this is the trap that we typically fall into.

A service is opaque and its inner working should be private.

Service accuracy or speed of functionality, or availability numbers, etc.   can all be measured through service invocation monitoring, without monitoring service internals.

Monitoring of service internals should be reserved for service provider to ensure that service itself operates properly.  But service ecosystem should not be concerned with it.

 

From: Bashioum, Christopher D [mailto:cbashioum@mitre.org]
Sent: Sunday, April 03, 2011 9:52 PM
To: Lublinsky, Boris; mpoulin@usa.com; Laskey, Ken; soa-rm-ra@lists.oasis-open.org
Subject: RE: understanding of SOA ecosystem scope

 

I think it may be too much to say “should not”, perhaps “may not”.  I think that it is up to the provider to decide whether the “market dynamics” of the ecosystem make the provider feel it is of value to them as a competitor to provide some of their specific monitoring to the ecosystem.  For example, let’s suppose two providers are providing competing services.  In that case, one provider may present to the ecosystem some internal monitoring numbers to show accuracy or speed of functionality, or availability numbers, etc. 

 

 

 

From: Lublinsky, Boris [mailto:boris.lublinsky@navteq.com]
Sent: Sunday, April 03, 2011 10:47 PM
To: Bashioum, Christopher D; Lublinsky, Boris; mpoulin@usa.com; Laskey, Ken; soa-rm-ra@lists.oasis-open.org
Subject: RE: understanding of SOA ecosystem scope

 

Yes,

And as such provider’s specific monitoring is not part of the ecosystem and hence it should not be exposed to the ecosystem

 

From: Bashioum, Christopher D [mailto:cbashioum@mitre.org]
Sent: Sunday, April 03, 2011 9:44 PM
To: Lublinsky, Boris; mpoulin@usa.com; Laskey, Ken; soa-rm-ra@lists.oasis-open.org
Subject: RE: understanding of SOA ecosystem scope

 

Good point.  Here we may have monitoring that the ecosystem may dictate, and/or be aware of, and/or be consumer of, etc.  But there are other things that only the provider will ever be aware of, and the needs of the provider will determine what will be monitored.

 

Is that what you are getting at Boris?

 

From: Lublinsky, Boris [mailto:boris.lublinsky@navteq.com]
Sent: Saturday, April 02, 2011 6:23 PM
To: mpoulin@usa.com; Laskey, Ken; Bashioum, Christopher D; boris.lublinsky@navteq.com; soa-rm-ra@lists.oasis-open.org
Subject: RE: understanding of SOA ecosystem scope

 

Michael,

The service is opaque – its one of the service tenets -  that’s why one can change implementation, without impacting the consumer.

If you violate this there is no encapsulation and there are no services.

 

 

From: mpoulin@usa.com [mailto:mpoulin@usa.com]
Sent: Saturday, April 02, 2011 4:50 PM
To: klaskey@mitre.org; cbashioum@mitre.org; boris.lublinsky@navteq.com; soa-rm-ra@lists.oasis-open.org
Subject: Re: understanding of SOA ecosystem scope

 

Ken, may I ask you to translate "there are limits beyond which we would violateopacity in the name of possible value of arbitrary informatio.", or, at least, give me an example. I think, there is a quite grey area (unexpectedly).

 

If a consumer may not see the details of service body (implementation) but the stakeholder that owns the service can, do these details are 'made' visible to the SOA ecosystem?

 

I am afraid that saying "The ecosystem does not have unlimited visibility and insight into everything

within the ecosystem", we are over-designing the thing.

 

- Michael

 

 

-----Original Message-----
From: Laskey, Ken <klaskey@mitre.org>
To: mpoulin@usa.com <mpoulin@usa.com>; Bashioum, Christopher D <cbashioum@mitre.org>; boris.lublinsky@navteq.com <boris.lublinsky@navteq.com>; soa-rm-ra@lists.oasis-open.org <soa-rm-ra@lists.oasis-open.org>
Sent: Sat, Apr 2, 2011 7:57 pm
Subject: RE: understanding of SOA ecosystem scope

The ecosystem does not have unlimited visibility and insight into everything 
within the ecosystem.  It only has visibility to the extent that details are 
made available to it.  Part of governance and management may be specifying what 
is required to be visible but there are limits beyond which we would violate 
opacity in the name of possible value of arbitrary information.
 
Ken
---------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S H305              phone: 703-983-7934
7515 Colshire Drive                             fax: 703-983-1379
McLean VA 22102-7508
________________________________________
From: mpoulin@usa.com [mpoulin@usa.com]
Sent: Saturday, April 02, 2011 8:05 AM
To: Bashioum, Christopher D; Laskey, Ken; boris.lublinsky@navteq.com; 
soa-rm-ra@lists.oasis-open.org
Subject: understanding of SOA ecosystem scope
 
the last FULL version (17 an) of RAF stated:
 
 
the SOA-RAF makes key
49 assumptions that SOA-based systems involve:
50 • Use of resources that are distributed across ownership boundaries;
51 • people and systems interacting with each other, also across ownership
52 boundaries;
53 • security, management and governance that are similarly distributed across
54 ownership boundaries; and
55 • interaction between people and systems that is primarily through the 
exchange of
56 messages with reliability that is appropriate for the intended uses and 
purposes.
57 Even in apparently homogenous structures, such as within a single 
organization,
58 different groups and departments nonetheless often have ownership boundaries
59 between them. This reflects organizational reality as well as the real 
motivations and
60 desires of the people running those organizations.
61 Such an environment as described above is an ecosystem and, specifically in 
the
62 context of SOA-based systems, is a SOA ecosystem.
 
 
(I have not found explicit definition of SOA ecosystem in the Peter/Chris 
definition spreadsheets)
 
The things is red are, IMO, the reasons of my understanding that a SOA ecosystem 
has full visibility into everything it includes. This relates to the logical and 
functional aspects of the implementaiton of the service. For example, to list 
just a few, interactions with non-service resources, interactions with other 
services engaged in the controlled combinations (orchestration and 
choreography), security controls that contribute to the business trust between 
services.
 
I'd like to ask for your comments  on whether this understanding of SOA 
ecosystem in RAF matches yours (though I know that Boris disagrees with me 
already).
 
 
Cheers,
- Michael
 
-----Original Message-----
From: Bashioum, Christopher D <cbashioum@mitre.org>
To: Laskey, Ken <klaskey@mitre.org>; 'Lublinsky, Boris' <boris.lublinsky@navteq.com>; 
mpoulin@usa.com <mpoulin@usa.com>; soa-rm-ra@lists.oasis-open.org 
<soa-rm-ra@lists.oasis-open.org>
Sent: Sat, Apr 2, 2011 3:42 am
Subject: RE: [soa-rm-ra] Management Model section after comments of this week
 
This is interesting.  Turns out that management determines what it needs, but 
monitoring may only be able to monitor primitives that don’t map directly to 
management needs.  There will likely be an algorithm (or two or three) that 
combines monitoring primitives into information that is helpful for management 
decisions.
 
From: Ken Laskey [mailto:klaskey@mitre.org<mailto:klaskey@mitre.org?>]
Sent: Friday, April 01, 2011 4:20 PM
To: 'Lublinsky, Boris'; mpoulin@usa.com<mailto:mpoulin@usa.com>; 
soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org>
Subject: RE: [soa-rm-ra] Management Model section after comments of this week
 
Is there a management capability that applies to the existence and adequacy of 
monitoring?  That is what I had in mind.
 
Ken
 
From: Lublinsky, Boris [mailto:boris.lublinsky@navteq.com<mailto:boris.lublinsky@navteq.com?>]
Sent: Friday, April 01, 2011 3:57 PM
To: Laskey, Ken; mpoulin@usa.com<mailto:mpoulin@usa.com>; boris.lublinsky@navteq.com<mailto:boris.lublinsky@navteq.com>; 
soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org>
Subject: RE: [soa-rm-ra] Management Model section after comments of this week
 
Monitoring is a means – you can’t manage what you do not measure
 
From: Ken Laskey [mailto:klaskey@mitre.org<mailto:klaskey@mitre.org?>]
Sent: Friday, April 01, 2011 2:20 PM
To: mpoulin@usa.com<mailto:mpoulin@usa.com>; boris.lublinsky@navteq.com<mailto:boris.lublinsky@navteq.com>; 
soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org>
Subject: RE: [soa-rm-ra] Management Model section after comments of this week
 
I think the point is monitoring is a required manageability.  Otherwise, you 
don’t have the information to do the other manageability.
 
Ken
 
 
From: mpoulin@usa.com<mailto:mpoulin@usa.com> [mailto:mpoulin@usa.com<mailto:mpoulin@usa.com?>]
Sent: Friday, April 01, 2011 12:03 PM
To: Laskey, Ken; boris.lublinsky@navteq.com<mailto:boris.lublinsky@navteq.com>; 
soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org>
Subject: Re: [soa-rm-ra] Management Model section after comments of this week
 
Now is my tern to follow the discusstion and figure out what is sold ( and whome 
to).
 
Will come back with my comments (if any) later. At the mean time, I can only 
point that means cannot drive the subject[http://o.aolcdn.com/cdn.webmail.aol.com/resources/core/images/indecision.png]: 
monitoring cannot drive management  - it has to be the other way around
 
- Michael
 
-----Original Message-----
From: Ken Laskey <klaskey@mitre.org<mailto:klaskey@mitre.org>>
To: 'Lublinsky, Boris' <boris.lublinsky@navteq.com<mailto:boris.lublinsky@navteq.com>>; 
mpoulin@usa.com<mailto:mpoulin@usa.com>; soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org>
Sent: Fri, Apr 1, 2011 4:00 am
Subject: RE: [soa-rm-ra] Management Model section after comments of this week
Sold!
 
 
From: Lublinsky, Boris [mailto:boris.lublinsky@navteq.com<mailto:boris.lublinsky@navteq.com?>]
Sent: Thursday, March 31, 2011 10:59 PM
To: Laskey, Ken; 'Lublinsky, Boris'; mpoulin@usa.com<mailto:mpoulin@usa.com>; 
soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org>
Subject: RE: [soa-rm-ra] Management Model section after comments of this week
 
Actually this brings one more manageability, that Michael does not have – usage 
manageability and metering. I will buy this one
 
From: Ken Laskey [mailto:klaskey@mitre.org<mailto:klaskey@mitre.org?>]
Sent: Thursday, March 31, 2011 9:57 PM
To: 'Lublinsky, Boris'; mpoulin@usa.com<mailto:mpoulin@usa.com>; 
soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org>
Subject: RE: [soa-rm-ra] Management Model section after comments of this week
 
I concede on the example but I’m still inclined to think monitoring needs to be 
broader than invocation events.
 
Too tired to be more creative.
 
Ken
 
---------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S H305              phone: 703-983-7934
7515 Colshire Drive                                    fax:        703-983-1379
McLean VA 22102-7508
 
From: Lublinsky, Boris [mailto:boris.lublinsky@navteq.com<mailto:boris.lublinsky@navteq.com?>]
Sent: Thursday, March 31, 2011 10:52 PM
To: Laskey, Ken; mpoulin@usa.com<mailto:mpoulin@usa.com>; boris.lublinsky@navteq.com<mailto:boris.lublinsky@navteq.com>; 
soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org>
Subject: RE: [soa-rm-ra] Management Model section after comments of this week
 
Ken,
Michael already has network management, that will react at you situation number 
1. So I am still not buying events thingy
 
From: Ken Laskey [mailto:klaskey@mitre.org<mailto:klaskey@mitre.org?>]
Sent: Thursday, March 31, 2011 9:45 PM
To: mpoulin@usa.com<mailto:mpoulin@usa.com>; boris.lublinsky@navteq.com<mailto:boris.lublinsky@navteq.com>; 
soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org>
Subject: RE: [soa-rm-ra] Management Model section after comments of this week
 
1.       I think events have to be more than invocations.  A service consuming a 
lot of bandwidth may be an event that requires a response from management. 
Deciding the response likely falls under other management but the monitoring 
itself is needed.  If everything relates to an invocation, then maybe service 
invocation is sufficient, but I don’t think you want to go there.  I’d stick 
with monitoring.
2.       As you list things below to fall under Combination or Composability, 
the list becomes too diverse and has no focus for what is really being managed.  
Everything requires some degree of management and when we decide something needs 
to specifically be called out, it needs to be clear why the SOA ecosystem 
requires something beyond traditional management.
3.       I think all aspects of performance should be in one place.  Otherwise, 
it seems like you’re splitting hair to break some out and not others.
Ken
---------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S H305              phone: 703-983-7934
7515 Colshire Drive                                    fax:        703-983-1379
McLean VA 22102-7508
 
From: mpoulin@usa.com<mailto:mpoulin@usa.com> [mailto:mpoulin@usa.com<mailto:mpoulin@usa.com?>]
Sent: Thursday, March 31, 2011 7:44 AM
To: boris.lublinsky@navteq.com<mailto:boris.lublinsky@navteq.com>; 
soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org>
Subject: Re: [soa-rm-ra] Management Model section after comments of this week
 
Boris,
I think that our task is not to set a status of "disagree" but to find a 
solution to resolve the disagreement.
 
1.     About Event Manageability. It seems to me that "service invocation 
manageability" might work because I certainly do not want to manage events that 
may be even outside of SOA ecosystem. Also, I do distinguish (despite of EDA 
vision) between the event and reporting of this event. A consideration I use is 
this: if nobody (in given realm) listens to/monitors the event, this does not 
mean that the event has not happened; one event may cause another event  - a sad 
example: an earthquake causes a tsunami - and, if we discard the initial event 
as non-existed but we recognise the caused event, we have to deal with things 
without reasons, out of the blue, which is not natural and unacceptable to me.
So, an events selection manageability is a sort of a view inside and outside the 
SOA ecosystem for the service invocation triggers.
2.     I do respect IBM’s viewpoint but they proofed they are not very fast with 
changes and they still take SOA service as a Web Service in several of their 
even modern applications and papers while others (e.g. Dr. Marc Fiammante)  are 
quite in synch with what we do in OASIS.
So, a service, even a composite or aggregate service depends only on 
functionality it needs from others. Considering an explicit contracts and a 
possibility of the trusted realm, a service (and its implementation like a 
process)  may not and do not need to know who actually provides required 
functionality.
By Combination or Composability Management I mean (but may be did not use proper 
words to articulate) a management of service capabilities to be used in the 
combinations or to combine others for providing solution for common task. This, 
particularly, includes: special relationship between business  services and Data 
Services / Data Access Layer, enforcement of policies related to the granularity 
of interfaces, management of information stores/repositories for meta-data, 
management of the processes and procedures – development and run-time – that 
result in new service combinations (which may include as integration as testing 
aspects), and so on. I hope, you’ve got the picture. Configuration management 
may also take place among others in this domain but, IMO, it is certainly not 
the major one.
3.     The last one – management of business performances – do require and use 
SLA and SLA management but the letter is not always a visible part of the 
former. This is why I put them separately: the SLA management can still be 
provisioned at many different levels (including pure technical ones) while 
management of business performances may be more laid around business KPI.
What do you think?
- Michael
 
-----Original Message-----
From: Lublinsky, Boris <boris.lublinsky@navteq.com<mailto:boris.lublinsky@navteq.com>>
To: mpoulin@usa.com<mailto:mpoulin@usa.com> <mpoulin@usa.com<mailto:mpoulin@usa.com>>; 
boris.lublinsky@navteq.com<mailto:boris.lublinsky@navteq.com> 
<boris.lublinsky@navteq.com<mailto:boris.lublinsky@navteq.com>>; 
soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org> 
<soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org>>
Sent: Thu, Mar 31, 2011 12:25 am
Subject: RE: [soa-rm-ra] Management Model section after comments of this week
Do you see events manageability as service invocation manageability? I do not 
think I see it this way
On everything else,
Let’s see we agree to disagree
What you call composability I call dependence – see IBM’s service model – a 
service can have both interfaces and dependencies
For me also, business performance requires SLA
 
From: mpoulin@usa.com<mailto:mpoulin@usa.com> [mailto:mpoulin@usa.com<mailto:mpoulin@usa.com?>]
Sent: Wednesday, March 30, 2011 5:18 PM
To: boris.lublinsky@navteq.com<mailto:boris.lublinsky@navteq.com>; 
soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org>
Subject: Re: [soa-rm-ra] Management Model section after comments of this week
 
Boris, at a glance:
•         Event Monitoring Manageability is mandatory IMO because it is not 
about notifications but about managing selection of events that trigger the 
services.
•         I do not understand "Dependency manageability" because service do not 
depend on other services; instead, they depend on functionality of an arbitrary 
trusted provider (IBM Dynamic Process Edition allowed having a 'basket' of 
potential providers where the process picked up the actual one when needed on 
the fly 9not a discovery mechanism); no end-points were configured up-front). 
This is not a programmatic dependency, which many would read into.
•         Combination or Composability Management  is about managing 
combinations of services that might be realised w/ or w/o configuration, i.e. 
via design (composition) or orchestration (aggregation), by both service 
provider and consumer. The fact that existing BPM tools require configuration 
does not mean that they are the only possible ways of doing combinations. Also, 
do not forget about business domain where a service combination may requires 
just a new organisational chart :-)
•         Business Performance and Service Level Agreement are very different 
things, e.g. the former may have monetary expression while the latter - pure 
technical expression. Also, the best technical expressions (measurements and 
matrix) do not necessary lead to the best monetary expressions.
 
- Michael
 
-----Original Message-----
From: Lublinsky, Boris <boris.lublinsky@navteq.com<mailto:boris.lublinsky@navteq.com>>
To: mpoulin@usa.com<mailto:mpoulin@usa.com> <mpoulin@usa.com<mailto:mpoulin@usa.com>>; 
soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org> 
<soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org>>
Sent: Wed, Mar 30, 2011 5:58 pm
Subject: RE: [soa-rm-ra] Management Model section after comments of this week
Here is my manageability proposal:
•         Lifecycle Manageability
•         Configuration manageability
o   Dependency manageability
•         Policies Manageability
•         Contracts manageability
•         Business Performance manageability
o   SLA Manageability
 
 
Event Monitoring Manageability is really about reporting and should not be there
 
From: mpoulin@usa.com<mailto:mpoulin@usa.com> [mailto:mpoulin@usa.com<mailto:mpoulin@usa.com?>]
Sent: Wednesday, March 30, 2011 5:52 AM
To: soa-rm-ra@lists.oasis-open.org<mailto:soa-rm-ra@lists.oasis-open.org>
Subject: [soa-rm-ra] Management Model section after comments of this week
 
Folks,
I have incorporated all comments and chnages into attached document. In some 
places, I have repeated the text (in different font) just to save and show the 
comments that I responeded insted but didn't change the text.
I am not sure what tactics we prefer now - to go through all left comments 
together in the meeting or for me to resolve each comment with particular author 
(in some cases I disagree with the comment, however).
 
Cheers,
- Michael
________________________________
The information contained in this communication may be CONFIDENTIAL and is 
intended only for the use of the recipient(s) named above. If you are not the 
intended recipient, you are hereby notified that any dissemination, 
distribution, or copying of this communication, or any of its contents, is 
strictly prohibited. If you have received this communication in error, please 
notify the sender and delete/destroy the original message and any copy of it 
from your computer or paper files.
________________________________
The information contained in this communication may be CONFIDENTIAL and is 
intended only for the use of the recipient(s) named above. If you are not the 
intended recipient, you are hereby notified that any dissemination, 
distribution, or copying of this communication, or any of its contents, is 
strictly prohibited. If you have received this communication in error, please 
notify the sender and delete/destroy the original message and any copy of it 
from your computer or paper files.
________________________________
The information contained in this communication may be CONFIDENTIAL and is 
intended only for the use of the recipient(s) named above. If you are not the 
intended recipient, you are hereby notified that any dissemination, 
distribution, or copying of this communication, or any of its contents, is 
strictly prohibited. If you have received this communication in error, please 
notify the sender and delete/destroy the original message and any copy of it 
from your computer or paper files.
________________________________
The information contained in this communication may be CONFIDENTIAL and is 
intended only for the use of the recipient(s) named above. If you are not the 
intended recipient, you are hereby notified that any dissemination, 
distribution, or copying of this communication, or any of its contents, is 
strictly prohibited. If you have received this communication in error, please 
notify the sender and delete/destroy the original message and any copy of it 
from your computer or paper files.
________________________________
The information contained in this communication may be CONFIDENTIAL and is 
intended only for the use of the recipient(s) named above. If you are not the 
intended recipient, you are hereby notified that any dissemination, 
distribution, or copying of this communication, or any of its contents, is 
strictly prohibited. If you have received this communication in error, please 
notify the sender and delete/destroy the original message and any copy of it 
from your computer or paper files.

The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.


The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.


The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]