Hi Jan, Ok, I'll respond inline. One overall point - it is best to understand SOA conceptually without trying to map it to any specific technology, at least not at first.
Eric --- Jan Algermissen <[EMAIL PROTECTED]> wrote: > Hi Eric, > > thanks for taking the time to respond at length and > apologies that I > unfortunately do not have the time to respond in > such detail; I'll > stick to short messages. > > On Jan 22, 2006, at 3:08 AM, Eric Newcomer wrote: > > > But the > > requester knows nothing more than the format of > the > > message and its destination. > > But it also does need to understand the semantics of > the service's > API (there is no sense in invoking getStockQuote() > if I have no > understanding of what that means), doesn't it? > No, it doesn't need to understand the semantics. It's enough to define the data and associate it with a service name. The implementation only needs a way to dispatch the request to an object, procedure, or queue. It doesn't need to understand the semantics of the service implementation or even the object's signature, for example, as long as there's code within the service implementation that does. The service itself is just a wrapper or interface defined in terms of message in/message out. > Getting back to architectural constraints once more: > > From what you wrote so far, I understand that SOA > actually places no > constraints on the architectural elements of a > system, except one: > interaction in the system takes place between > components; the > components that are capable of receiving messages > must be services > which means they must implement a function that is > taken from the > business domain. (Meaning that a component providing > the function of > adding items to a list does *NOT* qualify as a > service while a > component that provides the function of accepting > orders does. Well, I suppose I was generalizing to try to illustrate the major concept. It is certainly possible (and often actually happens in practice) to define technical services such as network address lookup, authorization/authentication, routing, transformation, calculation, etc. > > If all (most?) of my 'receiver'-components are > services my system is > of the SOA style. Both senders and receivers need to be service oriented. The senders are called requesters and the receivers are called providers. The requester/provider interaction is an essential aspect of SOA. > > Do you agree with that? > > > There is something interesting about constraining > services to > implement a business domain function: while the > client needs an > understanding of the business domain semantics to > invoke a given > service the 'function must be from business domain' > ensures that > business domain semantics do not propagate to > distributed > interactions. You will not have client code that is > concerned with > putting together orders via a fine grained remote > API, since then the > remote interface would not be a service. SOA does not say you can't have things other than services, or that all services have to be business services. SOA is more about the requester/provider interaction, and focusing design on the data exchanged among services than it is on any particular aspect of how the code works behind the services. It is a mistake to equate technology with services, although of course services use technology for their implementations. > > While clients will be using their knowledge of the > business domain to > construct the message that goes to the order > processor, you can OTH > be sure that the order construction is not happening > via remote calls. > > Does that make sense? I am afraid I don't follow it. I think you are trying to describe SOA based on some particular technology rather than as an abstraction. > > > Mark: do you think the above qualifies as an > architecural constraint > at all?? > > > Jan > > > > ________________________________________________________________________ > > _______________ > Jan Algermissen, Consultant & Programmer > > http://jalgermissen.com > Tugboat Consulting, 'Applying Web technology to > enterprise IT' > http://www.tugboat.de > > > > > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com 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/
