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> > > > > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Something is new at Yahoo! Groups. Check out the enhanced email design. http://us.click.yahoo.com/SISQkA/gOaOAA/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/
