I share your sarcasm, Steve. Aspects embedding is an OO approach, not SO
one.
I agree but, aspects in terms of interceptors is not an OO approach.
Filters, interceptors and monitoring agents have been around for a very
long time.
--
email: [EMAIL PROTECTED]
________________________________
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of
Michael Poulin
Sent: Sunday, April 01, 2007 2:41 AM
To: [email protected]
Subject: Re: [service-orientated-architecture] ESB Standard
Definition - SOA capabilities and its categorization
I share your sarcasm, Steve. Aspects embedding is an OO
approach, not SO one.
However, here is, at least, one way of setting a 'liability
insurance' on the 3rd party services that have different or none
security embedded - a policy/security bridge. It is an intermediary,
which performs resolution between different security algorithms and/or
performs security controls if a service does not have any. Certainly, a
bridge cannot cover the 'leg' between its end-point and related
consumer or receiver end-pint for such unsecured service but it is
better than nothing.
Since the bridge acts for the SOA, it can be considered as a SOA
infrastructure, i.e. as a SOA capability related to security.
- Michael
Steve Jones <[EMAIL PROTECTED]> wrote:
How would you see security being done between various
3rd party services?
On 30 Mar 2007 08:34:25 -0700, Bill Barr <
[EMAIL PROTECTED] <mailto:[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]
<mailto:[EMAIL PROTECTED]>
________________________________
From:
[email protected]
<mailto:[email protected]>
[mailto:[email protected]
<mailto:[EMAIL PROTECTED]> ] On Behalf Of Steve
Jones
Sent: Friday, March 30, 2007 1:14 AM
To:
[email protected]
<mailto:[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] <mailto:[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]
<mailto:todd.biske%40gmail.com> > 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]
<mailto:todd.biske%40gmail.com> > 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
<http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php>
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> > [EMAIL PROTECTED]
<mailto:fullfeatured%40yahoogroups.com>
> >
>
>
__________________________________________________________
Don't pick lemons.
See all the new 2007 cars at Yahoo!
Autos.
http://autos.yahoo.com/new_cars.html
<http://autos.yahoo.com/new_cars.html>
________________________________
Expecting? Get great news right away with email Auto-Check.
<http://us.rd.yahoo.com/evt=49982/*http://advision.webevents.yahoo.com/m
ailbeta/newmail_tools.html>
Try the Yahoo! Mail Beta.
<http://us.rd.yahoo.com/evt=49982/*http://advision.webevents.yahoo.com/m
ailbeta/newmail_tools.html>
