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.
Steve Jones <jones.steveg@...> wrote:How would you see security being done between various 3rd party services?On 30 Mar 2007 08:34:25 -0700, Bill Barr < bbarr@expedia. com> 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: bbarr@expedia. com
From: service-orientated- architecture@ yahoogroups. com [mailto:service-orientated-architec ture@yahoogroups .com] On Behalf Of Steve Jones
Sent: Friday, March 30, 2007 1:14 AM
To: service-orientated- architecture@ yahoogroups. com
Subject: Re: [service-orientated -architecture] ESB Standard Definition - SOA capabilities and its categorizationI'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 < jerryyz@yahoo. com> 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
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
So four SOA capability categories?
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 <todd.biske@gmail. 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.
> 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
> > 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(infrastruc ture 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 <todd.biske@gmail. 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,
> >> it helps differentiate between activities that
> > may still be considered programming efforts, such
> >> 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
> > tool, an ESB, a WSM product, a network appliance,
> >> pixie dust, a roving band of trolls, or whatever
> >> takes. Unfortunately, that doesn't bode well for
> > vendor marketing.
____________ _________ _________ _________ _________ _________ _
> > ____________ __
> > The fish are biting.
> > Get more visitors on your site using Yahoo! Search
http://searchmarket ing.yahoo. com/arp/sponsore dsearch_v2. php
> > Yahoo! Groups Links
> > fullfeatured@ yahoogroups. 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.
Try the Yahoo! Mail Beta.
- Issue 1: Infrastructure vs. Business Functionalities
We may not always find implementation of
infrastructure functionalities (IF) in the market and
have to code them in house. Also there maybe generic
IF and specific IF and we have to code specific IF in
house. We could find a good mix of products in the
market that maximize our needs to reduce coding
Issue 2: Implementation of IF
Not all IFs are implemented as services. The
architecture of services (someone will ellaborate what
that is) should be consistent. A mediator does not
have the same architecture as that of transfromation
service for example. Mediator is a messaging hub (or
bus) through which asychronousity/reliability is
achieved. Provider and consumer are loosely coupled in
the sense that provider has no knowledge who'll
receive the message. There is a contract between
provider and bus that the bus will deliver the message
and another contract between bus and consumer that the
message will be reliably delivered to the consumer.
The bus may support multiple protocols or one standard
protocol and other protocol messaging hubs are plugged
into as an abstraction points.
I think we still need a messaging backbone in concept
without limiting to a particular protocol. This
messaging backbone is the mediator, or bus, to
differentiate from the concept of services. It is
just more clear to me in terms of implementation
instead of just through ideas around and let others to
implement. You said "Mediators rely on infrastructure
services i the ISM to implement the required IF." So
you actually differentiate mediators from service.
I think that two key component to ESB: service
container and messaging hub (bus, mediator). (refer to
David Chappel's book ESB) If we are clear what they
are, it would be easier to communicate.
--- Anne Thomas Manes <atmanes@...> wrote:
> See inline...=== message truncated ===
> On 02 Apr 2007 08:20:39 -0700, Jerry Zhu
> <jerryyz@...> wrote:
> > My summerizing Anne's message about SOA
> > organized as a hierarchy. So it is a SOA
> > Reference Model?
> > Capability Domain (CD)
> > Capability Type (CT)
> > Capabilities
> > CD provide high level view of SOA capabilities
> > to support functions in a SOA infrastructure. CDs
> > comprised of CTs that further categorize and
> > the capabilities in each domain. CT group similar
> > capabilities in support of the domain. Each CT
> > includes one or more capabilities that provide
> > "building blocks" that collectively deliver the
> > required functions to the SOA infrastructure.
> > capabilities can be encapsulated into
> > servcies/components to fulfil certain functions.
> One important thing to keep in mind is that products
> frequently do not
> correspond one-to-one with capability types. Often a
> product addresses
> multiple capability types, but rarely does it fully
> implement all the
> required capabilities in a capability type. As I
> said, a large
> organization is likely to have multiple platforms,
> mediation, and
> management systems. It may also use multiple
> > Anne mentioned three CDs: Service Runtime,
> > Governance, and Service Development. Anne further
> > specified CTs in Service Runtime Domain as below:
> > Service Runtime
> > Service platform
> > Service mediation
> > Service management
> > Service Registry
> > Anne, and all of us, still needs to provide
> content in
> > other two domains.
> And as is clear from your questions, it would also
> be helpful to break
> down the runtime capability types into their
> constituent capabilities.
> > SOA capabilities are SOA infrastructure
> > to be configured not coded. We all want to
> > coding efforts so we need to know what to buy and
> > to code.
> As a general rule, I recommend buying generic
> technology rather than
> building it, but even if you elect to build it
> yourself, the required
> capabilities of the infrastructure are still the
> same. My model
> attempts to define the capabilities required in a
> SOA runtime
> An important concept of the model is the clean
> separation of concerns
> between business functionality and infrastructure
> functionality. This
> is not so much an issue of what to buy versus what
> to build -- it's an
> issue of what to implement in a business service
> versus what to
> externalize to the infrastructure. Anything that is
> not directly
> related to processing your business algorithms can
> be construed as
> infrastructure. Any aspect of this infrastructure
> functionality that
> is generic can potentially be externalized to the
> infrastructure and
> implemented as infrastructure services. (i.e.,
> applying SOA principles
> to infrastructure functionality) Once infrastructure
> functionality is
> externalized into services, it can be configured
> declaratively and
> invoked automatically by mediators on behalf of a
> service or service
> interaction. I refer to this concept as the
> Infrastructure Services
> Model (ISM).
> > Benefits of having a clear picture of SOA
> > capabilities are many and I leave it to the group
> > elaborate. One thing is that customers would be
> > to look at their business capablities to
> undestand SOA
> > capablities needed and ask vendors to what degree
> > their products meet their needs in terms of SOA
> > technologies rather than having vendors dictate
> > SOA capability needs.
> Exactly! Before designing an infrastructure -- and
> certainly before
> buying products--you should understand what you
> need. This capability
> model helps you understand what you need.
> > Now in responding to Anne's message:
> > - Anne gave four CTs in Service Runtime Domain. I
> > think that two more are needed. They are
> > Backbone (transport data as messages in secure
> > reliable fashion) and Cross Protocol
> > that can be done in three ways: protocol
> bridging, MOM
> > bridging, and Direct Protocol Handling.
> I contend that you do not need a messaging backbone.
> There is no
> requirement to rely on any specific messaging
> protocol. The middleware
> that a service can communicate with is a function of
> its service
> platform. There is no requirement that all services
> must communicate
> using the same middleware, nor is there a
> requirement that all
> messages must be carried by a common carrier. There
> is also no need to
> call out a specific "cross protocol communication"
> Protocol transformation is no more critical to the
> environment than
> security mediation. It's just another form of
> mediation. The mediation
> systems are responsible for managing whatever
> mediation might be
> required. That's the whole point. An endpoint can
> converse using
> whatever protocol or middleware it needs to. At
> runtime, the
> infrastructure automatically routes the message
> through whatever
> mediators are required to deliver the message
> properly. The
> instructions regarding "proper delivery" are
> specified declaratively
> in policies (or you might call them configuration
> files). Policies
> define all aspects of mediation requirements,
> including routing,
> transformation, persistence, caching, reliability,
> security, auditing, logging, or whatever
> infrastructure function is
> required. Mediators rely on infrastructure services
> in the ISM to
> implement the required infrastructure functionality.
> > - Services not being a part of the
> infrastructure, I
> > disagree. What about integration services:
> > Transformation Service, Content Based Routing
> > and application adapter? do we code them or we
> buy and
> > configure them?
> I should have been more clear. I meant that business
> function services
> are not part of the infrastructure. Services that
> infrastructure functionality are clearly part of the
We won't tell. Get more on shows you hate to love
(and love to hate): Yahoo! TV's Guilty Pleasures list.