Re: [service-orientated-architecture] Re: SOA Reference Architecture

Mon, 26 Jun 2006 14:58:27 -0700

WSDM/Man and WS-MEX are in a state a flux, and they're likely to be quite different 2-3 years from now after <a href="" href="http://atmanes.blogspot.com/2006/03/ws-convergence.html">http://atmanes.blogspot.com/2006/03/ws-convergence.html ">WS-Convergence</a> reaches fruition. 

For the moment I think it's necessary to explicitly state support for these interfaces, given how few services actually expose them today. Not all services will support the same management capabilities and metadata types, so I don't see that need going away real soon now.

A management interface should support two core functions: get management information and execute control functions (start, stop, quiesce, resume, spawn, etc).

Anne

On 6/26/06, Stefan Tilkov <[EMAIL PROTECTED]> wrote:

Hi Anne,

I'm wondering: why would the metadata and management interfaces be
different for any two services (and same version of WS-MEX and WS-M/
WSDM)? If they're the same, why specify them explicitly?



Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/

On Jun 26, 2006, at 1:20 PM, Anne Thomas Manes wrote:

> One of the things that I really dislike about WSDL 2.0 is that it
> constrains a service to a single interface. The way I see it, a
> service should have at least three interfaces:
> - functional
> - metadata (e.g., WS-MetadataExchange)
> - management (e.g., WSDM and WS-Management)
>
> The WSDL 2.0 team acknowledged my concern, but refused to relax the
> constraint, claiming that ease of use from a tooling perspective
> out-weighs this obvious use case. WSDL 2.0 now supports
> inheritance, so the service functional interface could inherit the
> metadata and management interfaces, but I much prefer to maintain
> them as separate. I can also see maintaining multiple separate
> functional interfaces to segregate query vs update functionality or
> low versus high surety requirements.
>
> What this means to me is that WSDL is not a service description
> language -- it is an interface description language. And perhaps
> that's reasonable. We have multiple metadata languages for a
> services already: WSDL, XML Schema, WS-Policy, WS-CDL, etc. It
> would be useful if we had some means to aggregate the metadata
> about a service. Right now the only standard means to aggregate
> this information is via a UDDI bindingTemplate.
>
> Anne
>
>
>
>
> On 6/26/06, Steve Jones <[EMAIL PROTECTED]> wrote:
> The SOA RM is pretty clear around service and capabilities
> (operations)
>
> Services provide access to capabilities, capabilities are NOT in
> themselves services.
>
> Service and Interface are distinct entities, implementation is a
> tricker one IIRC (without the paper to hand) as does a different
> implementation mean a different service even though it fufils the
> same contract, I think we came down on that opinion so
> implementation and service (but not contract) are more tightly bound.
>
> We didn't do the Service can implement many interfaces specifically
> (its allowed by the RM) or whether their can be multiple services
> implementing an interface (again allowed by the RM).
>
> Its definately not (IMO) just concensus building as it reduces the
> role of technology (the execution context) to the most minor part
> of SOA, and also makes clear that SOA is not a technology only thing.
>
> But if you do have issues feed them back to the group, procedurally
> they might not make it into 1.0, but are what will be looked at for
> the next iteration.
>
> Steve
>
>
>
>
> On 26/06/06, jalateras <[EMAIL PROTECTED]> wrote:
> > >>
> > >> I'm also in the progress of creating a SOA Reference
> Architecture.
> > >> It's not an easy task, but I have used the OASIS Reference
> Model as
> > >> a starting point. There is many issues I'm looking into, and some
> > >> of them are:
> > >>
> > >> A more detailed model of a service that makes it possible to
> use a
> > >> common langauge, i.e. relationships between messages, operations,
> > >> interface, ports, service and service provider. Seems like an
> easy
> > >> task, but I'm not able to construct a model that satisfies
> > >> everybody. E.g should there be a 1-1 relationship between a
> service
> > >> and a service interface (there could be many ports into the same
> > >> service, but they all use the same interface) or should a service
> > >> be able to implement many interfaces?
> > >>
> > >
> > > These are exactly the kind of questions I face in every single
> > > customer project. The first step is to define a model (or
> metamodel,
> > > if you prefer) of SOA concepts. For example, there is no right or
> > > wrong when it comes to questions such as whether a "service"
> contains
> > > "operations" (or whether operations *are* services), whether
> "service
> > > interface", "service", and "service implementations" are distinct
> > > concepts ... I have created several incompatible such models by
> now
> > > to incorporate specific customers' pre-existing terminology.
> > >
> > > This is also what I would hoped for the OASIS SOA reference
> model to
> > > provide, instead of high-level statements that are so consensus-
> > > driven that they are almost meaningless.
> > >
> > >
> I haven't completely read the latest version of the draft but I
> thought the earlier versions (i.e. Working Draft 7), where they
> defined a layered model (service, service description, policy,
> contract, data model etc) was far more useful. As an architect I found
> it provided a good foundation for discussing SOA.
>
> cheers
> </jima>
>
>
>
>
>
>
>


__._,_.___


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

YAHOO! GROUPS LINKS



__,_._,___

Reply via email to