what SOA is all about. However I would point out that reuse does not
conveniently fall out of service catalogues, repositories or anything
like that. Reuse can only happen through design and nothing in ESB's or
anything I have heard thus far seems to support the role of the
Architect who designs the system (a system being a collection of
services that perform some well define business task). I'd love to
think that UML does it but it doesn't because it cannot deal with
distribution.
So I guess I am saying that if you go into SOA in order to get reuse do
not expect direct help in determining what to reuse from any tools such
as UDDI repositories/registries/ESB's or indeed anything that I have
seen (and I have seen quite a lot). Perhaps the assembled masses have
some suggestions, but I think it is likely that it is a methodological
approach supported by the right tools and languages that is required to
help us get reuse in any sensible fashion.
Cheers
Steve T
On 9 May 2006, at 12:38, Anne Thomas Manes wrote:
> While I agree with Radovan's recommendations regarding getting
> control of your services, he neglected to mention some of the core
> characteristics of a service, or to explain the basic SOA design
> principles.
>
> SOA is an architectural style of design that is defined by a set of
> design principles.
>
> As implied by the name, the primary SOA design principle is
> service-orientation. This principle dictates that if a piece of
> functionality is required by multiple applications, then the
> functionality should be refactored and implemented as a shared,
> reusable service rather than duplicated in each application.
> A service, therefore, is a representation of this functionality that
> can be shared by multiple applications. A service exposes it
> functionality through a well-defined interface. Service consumers
> (i.e., applications) use the interface to gain access to the
> functionality.
>
> The opposite of SOA is monolithic application silos where
> functionality and data must be duplicated in each application that
> requires them.
>
> SOA is fundamentally different from integration. SOA is about breaking
> down application silos. Integration is about reinforcing silos and
> duplicating data.
>
> ESBs are tactical integration solutions. They don't provide facilities
> that help you refactor functionality. You can use an ESB to provide
> connectivity among services, but using an ESB does not give you
> "instant" SOA. SOA is something you do, not something you buy.
>
> And by the way -- you don't need an ESB to do SOA. Yes -- it's a
> useful tool to have in your toolbox -- especially if you want to
> expose legacy application functionality as a service. But it's still
> just raw materials. It's like lumber. You can have a wonderful stack
> of lumber, but that won't give you a house. To get a house, you need a
> design, and you need some hard work.
>
> And Jerry's comment is not entirely accurate. Prior to 1998, you can
> be certain that MQSeries messages usually carried binary data --
> sometimes in a standard format (e.g., ASN1), sometimes not. But
> there's no reason why MQSeries (now WebSphere MQ) can't transfer XML.
> And I suspect that most new MQ applications exchange XML now.
>
> Meanwhile, ESBs don't always carry XML. About two-thirds of ESB
> products are MOM-based, and these MOM systems can carry binary data as
> well as XML.
>
> Anne
>
> On 5/9/06, Radovan Janecek <[EMAIL PROTECTED]> wrote:In SOA,
> the primary abstraction is the Service. You have good SOA, if you
> answer yes to questions such:
>>
>> Is every service uniquely identified?
>>
>> Can users easily find available services?
>>
>> Is every service well described from business perspective?
>>
>> Can any developer easily find all technical specifications of the
>> service (interfaces, policies, etc.) to build a composite
>> application?
>>
>> Does every service provider have a sufficient control over who is
>> using his/her service?
>>
>> Is it possible to measure and report service reuse?
>>
>> Is it possible to define and impose enterprise wide (or just
>> reasonably wide) standards for how services are described? (what
>> business schemas they can use, security mechanisms, SLAs, and
>> similar)
>>
>> Can you well automate auditing of the services conformance to these
>> standards?
>>
>> Most (if not all) of these questions suggest to start SOA
>> implementation with establishing a service catalog that provides the
>> visibility of services and their descriptions. Even if you start with
>> ESB you should not miss the catalog part.
>>
>> Radovan
>>
>>
>>
>> On 5/9/06, Jerry Zhu <[EMAIL PROTECTED] > wrote: Both MQSeries and
>> ESB transfer messages. The messages
>>> in MQSeries are binary data while the messages in ESB
>>> are XML data. Those messages are, to me, at different
>>> levels of inter software communication.
>>>
>>> I hear people say they are using SOA becase there are
>>> XML messages passing around. XML has been around for
>>> a long time but SOA is relative new. SOA is more than
>>> passing XML messages. There maybe minimum
>>> requirements in an architecture to be called SOA. So
>>> how to tell a SW architecture that is SOA or not?
>>>
>>> Jerry
>>>
>>>
>>> --- Stuart Charlton <[EMAIL PROTECTED]> wrote:
>>>
>>> > Let me correct myself and say "transfer" protocol
>>> > instead of transport. Utimately, they're a way of
>>> > moving bits with various differences in reliability,
>>> > performance, available message exchange patterns,
>>> > schemes to describe resources.
>>> >
>>> > My point is that an ESB should be independent of
>>> > transfer protocol. It looks at transfer protocols
>>> > in a modular way and can make it quite easy for a
>>> > user to mediate between MQSeries inbound and HTTP
>>> > POST outbound, or SMTP inbound and MQSeries
>>> > outbound, adapting between varying message exchange
>>> > patterns, levels of reliability, credential
>>> > declarations, etc.
>>> >
>>> > Stu
>>> >
>>> >
>>> > ----- Original Message ----
>>> > From: patrickdlogan <[EMAIL PROTECTED]>
>>> > To: [email protected]
>>> > Sent: Saturday, May 6, 2006 10:39:39 PM
>>> > Subject: [service-orientated-architecture] Re:
>>> > MQSeries vs. ESB
>>> >
>>> > > In this case MQSeries is just a transport...
>>> >
>>> > Isn't MQSeries more than that? i.e. MQSeries moves
>>> > things from here to
>>> > there, but in various ways, asynchronously, with
>>> > queue-based
>>> > semantics, etc. That seems to be much more than
>>> > "just a transport".
>>> >
>>> > > As is HTTP, FTP, SMTP, etc.
>>> >
>>> > And so aren't these more like MQSeries than they
>>> > are like "any other
>>> > transport"? i.e. they move things from here to
>>> > there, but in various
>>> > ways, with certain rules and expectations about
>>> > sequence,
>>> > sychronicity, identification, etc.
>>> >
>>> > > I found this view drastically simplifies a lot of
>>> > the confusion
>>> > > around an ESB's role in an SOA...
>>> >
>>> > It seems like an oversimplification to me.
>>> >
>>> > -Patrick
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > SPONSORED LINKS
>>> >
>>> > Computer software
>>> > Computer aided design software
>>> > Computer job
>>> > Soa
>>> > Service-oriented
>>> > architecture
>>> >
>>> > YAHOO! GROUPS LINKS
>>> >
>>> > Visit your group
>>> > "service-orientated-architecture" on the web.
>>> > To unsubscribe from this group, send an email
>>> > to:
>>> >
>>> >
>>> [EMAIL PROTECTED]
>>> > Your use of Yahoo! Groups is subject to the
>>> > Yahoo! Terms of Service.
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Tired of spam? Yahoo! Mail has the best spam protection around
>>> http://mail.yahoo.com
>>>
>>>
>>>
>>>
>>>
>>> SPONSORED LINKS
>>> Computer software
>>> Computer aided design software
>>> Computer job
>>> Soa
>>> Service-oriented architecture
>>>
>>> YAHOO! GROUPS LINKS
>>>
>>> ▪ Visit your group "service-orientated-architecture " on the web.
>>>
>>> ▪ To unsubscribe from this group, send an email to:
>>> [EMAIL PROTECTED]
>>>
>>> ▪ Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>>> Service .
>>>
>>
>>
>>
>> --
>> Radovan Janecek
>> http://radovanjanecek.net/blog
>>
>>
>> SPONSORED LINKS
>> Computer software
>> Computer aided design software
>> Computer job
>> Soa
>> Service-oriented architecture
>>
>> YAHOO! GROUPS LINKS
>>
>> ▪ Visit your group "service-orientated-architecture " on the web.
>>
>> ▪ To unsubscribe from this group, send an email to:
>> [EMAIL PROTECTED]
>>
>> ▪ Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>> Service .
>>
>
>
>
> SPONSORED LINKS
> Computer software
> Computer aided design software
> Computer job
> Soa
> Service-oriented architecture
>
> YAHOO! GROUPS LINKS
>
> ▪ Visit your group "service-orientated-architecture" on the web.
>
> ▪ To unsubscribe from this group, send an email to:
> [EMAIL PROTECTED]
>
> ▪ Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service.
>
>
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
