Who said that SOA is a technology? As SW
architecture, SOA is technology dependent. If
technology independent, it is not SW architecture. As
a new evolution in SW, SOA must contain new technology
elements distinct from the proceeding ones such as
Object Oriented Architecture and Functional Oriented
Architecture etc.
And again, SOA, as any SW architecture, is not
designed but defined. As defined, we apply our basic
beliefs as we define them. As such, there is no good
or bad architectures, they are either accepted or
rejected. It is unlikely to change others' basic
beliefs simply we don't change our ontological stance
over moments.
SW architecture is not about exercise. Exercise is a
play. SW architecture is about economics. It is
about doing more with less. Only through technologies
can we tell what is accepted or rejected.
And still gain, we talk about terms of Components such
as DCOM when we talk about Service here. We have not
talked succinctly, theorectically the new technology
elements when we talk about Services.
Jerry
--- 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
=== message truncated ===
__________________________________________________
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.
