Anne,
Thank you very much for this list. Which are some of the tools that might be considered for each member of this list ?
Henryk
- business analysis tools
- service design tools
- interface/message/data modeling tools
- metadata management systems
- service testing tools
- registry
- contract management systems
- policy management systems
- policy compliance tools
- service mediation systems
- service management systems
- service platforms
- service composition tools
Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
+1 Dan.
SOA is not about technology. I think XML and web services make systems much more versatile, therefore I recommend them, but you definitely don't need them to do SOA. To whit: The stuff that Gregg has built definitely qualifies as SOA, and it's built on Jini. I first started using the term "SOA" in 1991 when talking about CORBA.
SOA is like physical fitness. It doesn't matter what technology you use to exercise. What matters is that you do exercise. In fact, cross training typically yields better results.
When doing SOA what matters is the design, so any technology that helps you design *services* is useful. Note that I stress "services" -- not applications. From my perspective, this is the biggest impediment to SOA. Most software development projects focus on building applications, not services. If you want to do SOA, you have to adopt a service-centric mindset in place of the application-centric mindset that currently exists.
When it comes to implementing a service, you should select technology based on the specific service's requirements. If you want to deploy a service into a resource-constained device, you probably don't want to use XML/SOAP/HTTP. (This is a point that Gregg has pointed out repeatedly.)
Obviously it's a good idea to establish some policies regarding technology selection. You don't want every developer to use a different beast -- the system will quickly get chaotic. But at the same time, you really don't want to constrain the choices to just XML/SOAP/HTTP. My general recommendation is that XML/SOAP/HTTP should be the default technology, i.e., use it unless there's a compelling reason not to. But you also need to identify what the preferred alternatives are and what characteristics/requirements would warrant use of one of the preferred alternatives.
So what tools are most useful for SOA?
In general, the governance tools far out-weigh any kind of development or platform tools in terms of usefulness. Your goal is to build shared, reusable services. So you need tools that help you identify candidate services; you need tools that help you design services; you need tools that help you manage and govern the SDLC of the services. From a runtime perspective, mediation dramically increases the loosely coupled nature of applications, so I view mediation systems as the most important runtime component.
Here's a list of technologies that I think are most useful:
- business analysis tools (to help identify service candidates)
- service design tools
- interface/message/data modeling tools
- metadata management systems
- service testing tools
- registry
- contract management systems
- policy management systems
- policy compliance tools
- service mediation systems
- service management systems
- service platforms
- service composition tools (for building applications)
The most value tools will be the ones that are technology agnostics.
Anne
On 5/10/06, Dan Creswell <[EMAIL PROTECTED] > wrote:Jerry Zhu wrote:
> OO was considered as a new technology enabled by OO
> languages. It won't be OO architecture implemented
> with only procedural languages.
>
Surely OO is a design discipline not a technology? As a matter of fact,
you can do OO in procedural languages, you just need an appropriate set
of abstractions to do it.
Early C++ implementations were done by pre-processing and converting
back into C for the normal compiler to the turn into native code.
I don't associated OO architecture with any particular technology - I
conceive my OO architecture separately and then give it physical
representation by converting it into a set of co-operating components
written in whatever way is appropriate.
> What is the (new) technology that enables SOA? Or What
> is the technology that must be in an architecture to
> be called SOA? I think it is XML and Component
> technology. In the same way one can not develop OO
> software with producal languages, one can not develop
> SOA software without XML and Components.
>
And I think this is fundamentally why we have a problem. Architecture
and technology are two different and separate things. One uses
technology to implement an architecture but there is no specific
requirement to use a particular technology for a specific architectural
discpline - unless of course you introduce non-engineering concerns such
as finance/licensing.
I would of course concede that some technologies might make the
rendering of architecture from logical to physical easier.
> <Anne/> 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. </Anne>
>
> What is described here is also applicable to Microsoft
> COM objects (formally known as OLE controls or
> ActiveX) (Java beans as equivelent?) back in 1996.
> Should we say SOA has been already used in 1996?
>
Maybe we should be saying exactly that and in fact some are hence the
comments about being able to do it with CORBA etc. This is because the
basic architectural premise of SOA can be rendered into reality using a
myriad of technologies both old and new.
> I renew my question. What must be included in an
> architecture to be called SOA? One may say nothing.
> It is a style of design. Therefore one can write a SOA
> software using Fortune only? Is it possible?
>
> My hunch is that the technologies required are
> Component (distinct from Object) technology + XML.
> One can write procedural SW with C++ but it is still
> procedural, not OO, SW. To be OO SW, inheritence must
> be used. To be SO SW, it must include service
> description and service choregraphy. Without these, I
> won't call the SW with a SOA eventhough it passes XML
> messages. Without XML, I won't call it SOA either.
>
If I'm building a service-based thing, I need something that can model
services. Probably I need something that can define the
interface/contract for that service and how to locate the services I
desire so I can use them. (The remaining issue is whether those
services are distributed (that is networked) or not - if they're all
in-process I'd qualify them as components, if they aren't, they're
something else and I tend to call those services.)
So what technology might I use? Maybe CORBA, RMI or app servers or WS
or messaging or Jini or whatever.
IMHO - OO is not defined by the fact you use inheritance. In fact, good
OO makes use of a number of other concepts such as aggregation and
composition. Inheritance, really, should only be about sub-typing but
many use it to achieve re-use which is the wrong way to look at it.
Composition and aggregation are about re-use and that's why those
concepts are so visible in SOA.
My two cents,
Dan.
------------------------ Yahoo! Groups Sponsor --------------------~-->
You can search right from your browser? It's easy and it's free. See how.
http://us.click.yahoo.com/_7bhrC/NGxNAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
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.
