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

[Anne Thomas Manes]

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

•  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.

---

__,_._,___