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

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

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


Subject: Re: [soa-rm] core nature of a Service-Oriented Architecture[was: Security]


Agreed, Ken,

I had not considered the push model, so thanks for adding it into the 
mix. That is no doubt due to the myopia of having focused on WSRP for 
several years. However, it also occurs to me that this is just one 
model for web services per se, and not the one I am most concerned 
with. I have actually, in terms of services offered, been thinking in 
terms of major service units, like entire Human Resources Departments 
being available as a Service Template and CRM, and ERP. and SCM, etc, 
more than little chunks of of individual web services such as RSS 
News Feeds for left handed backgammon players, to be overly specific 
and slightly absurd. I'm not denigrating smaller service units, just 
noting that I haven't been thinking about them when I think about 
"architectures." However, it is clear that we need to serve the 
entire range in the abstract without leaving out both ends of the 
spectrum. It won't be a one (or even several) size(s) fits all, and I 
expect that will be the biggest challenge.

Ciao,
Rex


At 8:54 AM -0400 4/13/05, Ken Laskey wrote:
>Consider the following excerpted from the OWL-S spec 
>http://www.w3.org/Submission/2004/SUBM-OWL-S-20041122/.
>
><OWL-S>... the information necessary for Web service discovery could 
>be specified as computer-interpretable semantic markup at the 
>service Web sites, and a service registry or ontology-enhanced 
>search engine could be used to locate the services automatically. 
>Alternatively, a server could proactively advertise itself in OWL-S 
>with a service registry, also called middle agent [4,25,15], so that 
>requesters can find it when they query the registry. </OWL-S>
>
>So, for the former case, I am Big-Name company and I don't care 
>about no stinkin' public registry because my intent is to have you 
>come to my Web site for all your xxx needs.  Thus, I use a tailored 
>search engine and provide service access information in response to 
>the search.
>
>Alternatively,
>
><OWL-S> In the description so far, we tacitly assumed a registry 
>model in which service capabilities are advertised, and then matched 
>against requests of service. This is the model adopted by registries 
>like UDDI. While this is the most likely model to be adopted by Web 
>services, other forms of registry are also possible. For example, 
>when the demand for a service is higher than the supply, then 
>advertising needs for service is more efficient then advertising 
>offered services since a provider can select the next request as 
>soon as it is free; furthermore, in a pure P2P architecture there 
>would be no registry at all. Indeed the types of registry may vary 
>widely and as many as 28 different types have been identified 
>[26,4]. By using a declarative representation of Web services, the 
>service profile is not committed to any form of registry, but it can 
>be used in all of them. Since the service profile represents both 
>offers of services and needs of services, then it can be used in a 
>reverse registry that records needs and queries on offers. Indeed, 
>the Service Profile can be used in all 28 types of registry. </OWL-S>
>
>I have not checked out the 28 but these may provide some challenges 
>to consider for the RM.
>
>Ken
>
>On Apr 13, 2005, at 12:13 AM, Rex Brooks wrote:
>
>>[snip]
>
>>It strikes me that the core nature of a Service-Oriented 
>>Architecture lies in a transactional model in which a Service 
>>Provider or Service Producer publishes a named set or container of 
>>a service or services, the description of which is searchable by a 
>>Service Consumer according to some set of features or criteria 
>>which our RM provides.
>>
>>Even at a high level of abstraction, this will prove a test for us.
>>
>>Ciao,
>>Rex
>>
>------------------------------------------------------------------------------------------
>Ken Laskey
>MITRE Corporation, M/S H305     phone:  703-883-7934
>7515 Colshire Drive                        fax:        703-883-1379
>McLean VA 22102-7508
>
>*** phone number change 4/15/2005 to 703-983-7934 ***


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309


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