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






--
Radovan Janecek
http://radovanjanecek.net/blog

SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture


YAHOO! GROUPS LINKS




Reply via email to