The point I was trying to make in my earlier reply is that it is not 
currently practical to expect a single service contract that handles 
functional and non functional requirements. I work in financial 
services area and we have built some services. The functional part 
of the service (its capability) is defined in WSDL (also includes 
separate supporting document to give some more semantics about the 
service itself). The non-functional part is initially captured in 
traditional way in another document. From our experience, we have 
run into two types of non-functional requirments. The first type 
have some implications on service consumers via service interface. 
For example, a requirement could state to capture channel 
information accessing the service for audit or other purpose. The 
second type is transparent to the service - example service level or 
response times - that can be monitored and handled by the 
infrastructure. The reality from my experience is that one or more 
documents in addition to WSDL are required to fully define a service 
contract. 

One may try to add both functional and non-functional parts to WSDL 
via annotations. We have tried to add extra stuff to WSDL via xsd 
annotations - but that has its own problem with some implications on 
service consumer. 

Regards,
Awel

--- In [email protected], Ron 
Schmelzer <[EMAIL PROTECTED]> wrote:
> Yes, I made that point in my email. WSDL is not sufficient to 
describe 
> functional and non-functional requirements in the contract. If it 
was, I 
> wouldn't need to ask for examples ;) So, now I'm asking the 
question: 
> does ANYONE have examples for real-world Service Contracts?
> 
> Jason and I have been pounding the ground on this question for 
about 3 
> weeks now in different forums, and it seems that remarkably, there 
are 
> very few, if any, real-world examples of Service contracts other 
than 
> the aforementioned, but drastically insufficient WSDL.
> 
> So - once again - this is the time for those on this board to show 
their 
> mettle. Anyone have any real-world Service contracts that handle 
> non-functional and functional requirements? We've got lots of 
theorists, 
> pundits, and advisors on this group, but where are the practical 
> implementers?
> 
> Ron
> 
> Awel Dico wrote:
> 
> > Hi Ron;
> >
> > I agree that WSDL is not sufficient to provide all metadata
> > associated with security, semantics, QoS, SlA ..etc. I don't 
think
> > WSDL is supposed to provide those semantics either. As for 
security
> > within the SOA context, the message level security that can be
> > defined in SOAP headers (as defined in WS-security) is not
> > sufficient. The SOA infrastructure needs to provide another 
level of
> > security, such as authorizing the client, for the access of the
> > service (i.e. before sending the actual soap request - client
> > request is accepted only after the autorization is passed and 
then
> > the message level security could take over). For this to happen 
some
> > sort of security policy need to be implemented external to the
> > service that WSDL describes. May be XML appliences could help on
> > this.
> >
> > As to service semantics, this is a challenge because trying to 
add
> > semantics to WSDL requires establishing good data semantics. I 
think
> > we have long way to go to tackle semantcs part in standard way. 
For
> > now tactical solutions in development team communicate some data
> > semantics external to WSDL.
> >
> > QoS ans SLA is something that is responibility of the SOA
> > infrastructure rather than at the service (wsDL) level. I think
> > this  requires some sort of service management tools for 
monitoring
> > and managing services based on policies published in Service
> > registry tools. may be WSDM standard helps on this. Again, 
defining
> > SLA within WSDL for client consumption, I think, may not be
> > practical.
> >
> > When you say "process", I assume you mean business process here. 
In
> > that case, BPEL is used to describe the business process. Each
> > service described in WSDL can be orchestrated using BPEL to
> > implement higher level business service (i.e. business process).
> >
> > I know I am not helping you as such with your question - since 
you
> > ask for real example contract that handles these items. I am just
> > trying to point out that all those tasks are not in the scope of
> > WSDL and that other SOA infrastructure elements and polices are
> > required.
> >
> > Regards,
> > Awel Dico
> >
> > --- In [email protected], Ron
> > Schmelzer <[EMAIL PROTECTED]> wrote:
> > > Hi All --
> > >
> > > As you all know, one of the key parts to making loosely coupled
> > Services
> > > work is a well-defined contract that identifies both 
functional as
> > well
> > > as non-functional requirements for Service providers and
> > consumers. By
> > > now, you also probably realized that WSDL by itself is not
> > sufficient to
> > > provide all the metadata needed for loose coupling and late
> > binding.
> > > Other metadata are needed including security, semantics, QoS, 
SLA,
> > > process, etc.
> > >
> > > So, what we are looking for are actual examples of real-world
> > contracts,
> > > or templates for contracts that you are using in real-world SOA
> > > deployments, or at the very least, guidance for how those
> > contracts can
> > > be defined.
> > >
> > > So, help anyone?
> > >
> > > Thanks in advance!
> > > Best,
> > > Ron
> > >
> > > --
> > > _____________________________________________________________
> > > Ronald Schmelzer
> > > [EMAIL PROTECTED]
> > > Senior Analyst
> > > ZapThink LLC
> > > Direct: 781-577-2779 / Main: 781-207-0203
> >
> >
> >
> >
> >
> > -----------------------------------------------------------------
-------
> > YAHOO! GROUPS LINKS
> >
> >     *  Visit your group "service-orientated-architecture
> >       <http://groups.yahoo.com/group/service-orientated-
architecture>"
> >       on the web.
> >        
> >     *  To unsubscribe from this group, send an email to:
> >        service-orientated-architecture-
[EMAIL PROTECTED]
> >       <mailto:service-orientated-architecture-
[EMAIL PROTECTED]>
> >        
> >     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms 
of
> >       Service <http://docs.yahoo.com/info/terms/>.
> >
> >
> > -----------------------------------------------------------------
-------
> >
> 
> -- 
> _____________________________________________________________
> Ronald Schmelzer
> [EMAIL PROTECTED]
> Senior Analyst
> ZapThink LLC
> Direct: 781-577-2779 / Main: 781-207-0203






------------------------ Yahoo! Groups Sponsor --------------------~--> 
Fair play? Video games influencing politics. Click and talk back!
http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/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/
 



Reply via email to