tag:blogger.com,1999:blog-4233102570796813262.post3770394688474178863..comments2024-03-28T00:20:20.279-07:00Comments on Advanced Software Architecture Blog: Services ExplainedLeo Shusterhttp://www.blogger.com/profile/08007810921794666983noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-4233102570796813262.post-35821824142921981562015-07-01T13:24:13.814-07:002015-07-01T13:24:13.814-07:00thank you for sharing this wonderful information.....thank you for sharing this wonderful information..<br /><a href="http://www.1agaragedoors.net/garage-doors-elk-grove/" rel="nofollow">Get Best Info for Garage Doors Elk Grove</a><br />Anonymoushttps://www.blogger.com/profile/02695959498315028191noreply@blogger.comtag:blogger.com,1999:blog-4233102570796813262.post-36528612372894951562009-01-26T13:04:00.000-08:002009-01-26T13:04:00.000-08:00Tony,thanks for your comments. You've asked a ver...Tony,<BR/><BR/>thanks for your comments. You've asked a very interesting question. While from the pure SOA perspective, each operation should be treated as a separate service, the technical details of the SOAP protocol do not allow this to be easily achieved. Each web service operation should be related to the others in the same WSDL but it represents a distinct business capability or utility function. Thus, every operation should be treated independently from others and should be allowed to have its own interface(s) and contract(s). However, web services, by definition, are coupled with a specific protocol (SOAP over HTTP), although other communication mechanisms such as MQ, for example, are becoming available. WSDL represents a complete contract. While you can define specific contract terms for each operation (message details), some high level provisions, such as security and policy, can only be specified for the whole service. You can create a separate WSDL for each operation but it will defeat the purpose of the SOAP protocol. To allow each service operation to be fully flexible and be able to define multiple interfaces and contracts, ESB should be used. I believe that a service itself should not have to worry about variability in access patterns from different consumers but rather let SOA infrastructure such as ESB handle this. Thus, I would recommend defining the most appropriate contract through the web service endpoint and maximize its flexibility and reuse potential through the ESB-exposed endpoint(s).<BR/><BR/>Hope this helps.<BR/><BR/>LeoLeo Shusterhttps://www.blogger.com/profile/08007810921794666983noreply@blogger.comtag:blogger.com,1999:blog-4233102570796813262.post-73811048003634738702009-01-26T08:50:00.000-08:002009-01-26T08:50:00.000-08:00Hi Leo, thanks for a useful blog. If we look at yo...Hi Leo, thanks for a useful blog. If we look at your definitions from an OO perspective is a web service similar to a class in that a particular service, for instance the client service, might contain multiple operations, create a new client, update a client, delete a client each with it's own contract and implementation, or is a web service similar to an operation, so in my earlier example there were actually 3 services, create a new client, update a client and delete a client?<BR/><BR/>Thanks - TY.Tony Yhttps://www.blogger.com/profile/05189701709019437980noreply@blogger.com