[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]