But even while they're in flux, if I have twenty services all supporting the same WS-MEX version, they'll all support the same WS- MEX interface? I'm just wondering whether this really belongs into the service interface; if at all, the reference to the spec's namespace URI should be sufficient.
Or is it that you're looking for a way to specify a schema for the service-specific metadata? The WS-MEX WSDL, for instance, uses xs:any for the types; do you expect this to be specialized for each service? Stefan On Jun 26, 2006, at 11:50 PM, Anne Thomas Manes wrote: > 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="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> > > > > > > > > > > > > > > > > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> See what's inside the new Yahoo! Groups email. http://us.click.yahoo.com/2pRQfA/bOaOAA/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/
