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
--
_____________________________________________________________
Ronald Schmelzer
[EMAIL PROTECTED]
Senior Analyst
ZapThink LLC
Direct: 781-577-2779 / Main: 781-207-0203
SPONSORED LINKS
YAHOO! GROUPS LINKS
|
