project definition. When a project is defined, that establishes a
base set of constraints. Those constraints now influence the
solutions that can be produced, both new services and reuse of
existing services. In a business that still operates in silos, it
could easily be the case that the project definitions themselves
prevent the opportunities for reuse from ever materializing. There
are benefits to doing analysis for analysis sake only, without any
intent to design any particular solution, but rather, to learn more
about the subject area. The better our knowledge of the subject
area, the more likely we will produce solutions that are appropriate,
efficient, and agile.
Phil Wainewright just posted on ZDNet about the usability advantages
of web-hosted systems like SalesForce and Amazon, and it all stems
from their ability to collect information and learn. I just posted a
response to my blog, as this is a subject I'm particularly passionate
about.
http://www.biske.com/blog/?p=43
-tb
On May 9, 2006, at 2:45 PM, Steve Ross-Talbot wrote:
> I concur with both Anne and Radovan's comments and suggestions as to
> 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.
>>
>>
>
>
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor --------------------
> ~-->
> Protect your PC from spy ware with award winning anti spy
> technology. It's free.
> http://us.click.yahoo.com/97bhrC/LGxNAA/yQLSAA/NhFolB/TM
> --------------------------------------------------------------------
> ~->
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
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.
