I would say that "security infrastructure" is a "utility " service. Security
is very much the service in spite of the question it answers. BTW, before
getting into discussion at this level, we have to define the subjects: service,
utility, etc.
For example, can you say looking at an interface if its a service, or an
utility, or a function (C/Fortran, etc.) sits behind it?
Plus, security includes such things like confidentiality, integrity,
non-repudiation that do not relate to the concerns mentioned in the Bill's
message.
- Michael
Bill Barr <[EMAIL PROTECTED]> wrote:
Now we get to the hard part, which is addressing the differences between
secure software and security infrastructure. I believe your question is
referring only to the latter. Security infrastructure is a utility and not
really a service. All the service is concerned about are answers to the
questions: does this requester have valid credentials and if so, how do those
credentials translate into a role I understand so can fulfill the request?
Getting the request to the service in the first place is a job for
"facilities".
--
email: [EMAIL PROTECTED]
---------------------------------
From: [email protected] [mailto:[EMAIL
PROTECTED] On Behalf Of Steve Jones
Sent: Friday, March 30, 2007 9:34 AM
To: [email protected]
Subject: Re: [service-orientated-architecture] ESB Standard Definition - SOA
capabilities and its categorization
How would you see security being done between various 3rd party
services?
On 30 Mar 2007 08:34:25 -0700, Bill Barr < [EMAIL PROTECTED]> wrote:
Security is best left as an aspect embedded into the design of any
specific SOA. Security is really a thought process, not a capability.
--
email: [EMAIL PROTECTED]
---------------------------------
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of Steve Jones
Sent: Friday, March 30, 2007 1:14 AM
To: [email protected]
Subject: Re: [service-orientated-architecture] ESB Standard Definition -
SOA capabilities and its categorization
I'd be a bit worried if security wasn't considered to be an SOA
capability, trust, privacy, authentication etc are all key business
concepts that need to be handled within a delivered SOA.
On 30 Mar 2007 00:59:23 -0700, Jerry Zhu < [EMAIL PROTECTED]>
wrote: I agree with policy
enforcement being mediation
concept to be a category.
So network & security is left out and is considered as
non SOA capablity
The issue is Service Registry (SR). I think that SR is
used by all Service Platforms, Service Mediation, and
Service Managmeent, not just Service management. So SR
is considered as common factor of all three categories
and extracted out and defined as a separate capablity
category.
Also SR is used by business services in implementing
business logic in either early or late binding. The
fact that SR has its owns APIs and standards makes it
well into a category. Also we can buy service
registry as a standalone product in the market. So it
is a good separation of concerns to extract registry
out as a category. Metadata will be stored in
Repostory.
So four SOA capability categories?
Service Platforms
Service Mediation
Service Management
Service Registry/Repository
Ideas from anyone? If no objections we agree that
this is the SOA capability categorization. Once we
have this done we can insert capability items in the
categories.
--- Todd Biske <[EMAIL PROTECTED]> wrote:
> I normally break things down into:
>
> Service Platforms
> Service Mediation
> Service Management
>
> Looks very similar to Anne's model, doesn't it... I
> prefer to
> differentiate between policy enforcement, which I
> view as a mediation
> concept, from service management, which includes
> both policy
> management, as well as service lifecycle management
> (which is where
> the passive monitoring, metric analytics, etc.)
> comes into play.
> Service Registry/Repository is the tricky one to
> place in all of
> this. I'm still on the fence as to whether it is
> simply the
> information store that backs service management, or
> if all the of
> above 3 sit on top of a service metadata layer.
>
> -tb
>
>
> On Mar 28, 2007, at 2:15 PM, Jerry Zhu wrote:
>
> > I like the idea do understand the problem before a
> > solution. The problem is to determine the SOA
> > capabilities needed. The solution is the products
> mix
> > that covers maximally the capabilities with lowest
> > cost. The SOA capabilities are to be configured
> not to be coded when searching for SOA middle ware
> > products(infrastructure components? ).
> >
> > The difficulty is that do we have a good
> > classification and its comprehensive list of these
> SOA capabilities - capabilities that are unique to
> SOA? Load ballancing and firewall, for example
albeit important to be considered, are capablities
> outside of SOA.
> >
> > Anne classified four types of SOA capabilities:
> >
> > Service platforms: build, run (composite)
> services,lagecy systems encapsulation etc.
> >
> > Service mediation: Anne mainly mentioned policy
> > enforcement here
> >
> > Service management: visibility to the environment,
> > monitor trafic/activities, detect anormally and
> take actions etc.
> >
> > Regiestry: enable information exchange among
> services and infrastructure components.
> >
> > To me, service management includes service
> mediation. Intercept messages and enforce policies
is detecting and taking actions.
> >
> > Todd added network & security (environment to use
> one word) SOA capablity category.
> >
> > To help with understanding the problem before a
> > solution, can we have some concensus here the SOA
> > capability categories and capbilities in each?
> >
> > I see four:
> >
> > Service platform
> > Service management
> > Service network/security
> > Service Registry
> >
> > Once we agree the categories, we can list
> individual capabilities under each category.
> >
> > Best
> >
> > Jerry
> >
> > --- Todd Biske <[EMAIL PROTECTED]> wrote:
> >
> > What customers should be saying is, "I need these
> > capabilities, and I want this group to be
> >> responsible for them." The latter is key,
> because
> >> it helps differentiate between activities that
> are
> > may still be considered programming efforts, such
> as
> >> orchestration/choreography, from those
> >> that are configuration efforts, such as routing.
> >> Every organization will have a different set of
> > capabilities that are important, and different
> > operational models. Take that information
> >> and now go talk to your vendors to decide whether
> > you need an application server, a message bus, an
> EAI
> > tool, an ESB, a WSM product, a network appliance,
> >> pixie dust, a roving band of trolls, or whatever
> it
> >> takes. Unfortunately, that doesn't bode well for
> > vendor marketing.
> >
> >
> >
> >
> >
>
__________________________________________________________
>
> > ______________
> > The fish are biting.
> > Get more visitors on your site using Yahoo! Search
> Marketing.
> >
>
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> > [EMAIL PROTECTED]
> >
>
>
__________________________________________________________
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html
---------------------------------
Now that's room service! Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
