I'm with you on that definition, I completely agree that security should be part of the infrastructure (almost ether like) between services as much as it is part of a single service.
Steve On 01 Apr 2007 04:37:09 -0700, Michael Poulin <[EMAIL PROTECTED]> wrote:
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]> 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:service- > [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] <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] <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 > > > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > [EMAIL PROTECTED] <fullfeatured%40yahoogroups.com> > > > > > > > > > > > > > > __________________________________________________________ > > Don't pick lemons. > > See all the new 2007 cars at Yahoo! Autos. > > 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/mailbeta/newmail_tools.html> Try the Yahoo! Mail Beta.<http://us.rd.yahoo.com/evt=49982/*http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html>
