Ashraf, nice insights but you're talking about software architecture instead of service architecture.
H.Ozawa 2010/1/3 Ashraf Galal <[email protected]>: > Is it another way to say that the architecture is something different > than the implementation? > > One of the very first things that must be decided in your architecture > is whether you will use RPC-encoded or document-style interactions. Your > choice can impact the level of coupling present in your architecture. > > An RPC (remote procedure call) is essentially a call to a remote method. > Web services are XML-based, but you can still interact with the back-end > service in an RPC-like fashion. > Typically, the interaction is a very simple request/response, where the > client sends a SOAP message that contains a call to a method. > The application server receiving this request can then translate this > request into the back-end object (e.g., a Java object, EJB method, or C# > method). > There is very little that developers have to do to build an RPC-based > Web service because everything is mapped for them. > Note that even in this approach XML is used to contain the call. > Easy to develop of course. > > With document style, XML "business documents" are transmitted across the > wire. > They do not map directly to back-end method calls; they are actually > complete, self-contained business documents. > When the service receives the XML document, it might do some > pre-processing on the document, perform some work, and construct the > response back. > There is usually no direct mapping to a back-end object. > In fact, a request might invoke multiple components on the back end. > The developer has to do much of the work in processing and mapping the > XML data received, and there are very few tools on the market that can > do this automatically. > The document style is typically used in conjunction with asynchronous > protocols to provide reliable, loosely coupled architectures. > A bit difficult to develop. > > Consider a business process "process a Purchase Order", it fits well in > the document style. > You send a PO document in your message and receive an Invoice document > in a asynchronous communication. > It is important to maintain the consistency from conceptual level to > implementation level otherwise we go back to the data flow digram and > structure methods where we had to create analysis DFD, convert it to > design DFD then to implementation. > This was changed in the OO and will continue to be. > Again it is a different paradigm and need shifting in our thinking. > > All the best > > Ashraf Galal > > > > Steve Jones wrote: >> >> >> Not at the implementation level no, but at the conceptual level it >> tends to be easier for most people to think of it that way. >> >> >> >> Steve >> >> >> 2010/1/1 Harm Smit <[email protected] <mailto:[email protected]>> >> >> >> >> Steve, does this imply that you think all sorts of interactions >> can be based on RPC? >> >> Harm. >> >> >> >> *De :* [email protected] >> <mailto:[email protected]> >> [mailto:[email protected] >> <mailto:[email protected]>] *De la >> part de* Steve Jones >> *Envoyé :* mardi 29 décembre 2009 10:15 >> *À :* [email protected] >> <mailto:[email protected]> >> *Objet :* Re: [service-orientated-architecture] Re: Descriptions >> vs Contracts >> >> >> >> >> >> +1 >> >> >> >> Steve >> >> 2009/12/28 Gregg Wonderly <[email protected] <mailto:[email protected]>> >> >> >> >> I think one of the still, largely unrecognized issues is that >> developers really >> should be designing services as RPC interfaces, always. Then, >> different service >> interface schemes, such as SOAP, HTTP (Rest et.al.), Jini, etc., >> can be more >> easily become a "deployment" technology introduction instead of a >> "foundation" >> technology implementation that greatly limits how and under what >> circumstances a >> service can be used. Programming Language/platform IDEs make it >> too easy to >> "just use" a single technology, and then everything melds into a >> pile of >> 'technology' instead of a 'service'. >> >> Gregg Wonderly >> >> >> >> Michael Poulin wrote: >> > I think, one interesting aspect of service orientation is >> berried in >> > this CBDI phrase: use of the spec as a public description >> requires much >> > deeper shearing of the service semantics between the service >> developers >> > and " the service consumers and solution architects". This is a BIG >> > problem! >> > >> > It limits abilities of the service providers to advertise the >> service to >> > different consumer societies, different audiences, and different >> areas >> > of Business. To be used in Business, the shared semantics must be >> > minimal and it is not any close to the development vocabulary. >> Thus, I >> > can conclude that the CBDI's approach (based on the quote posted by >> > Dennis) is good if "developers and testers, ...service consumers >> and >> > solution architects" belong to the same society that shares all low >> > level details about the service. This may cause problems even >> inside the >> > same enterprise if it is large enough (CORBA Object Trading >> Service has >> > taught us hard lessons with this regard). >> > >> > - Michael >> > >> > ---------------------------------------------------------- >> > *From:* Dennis Djenfer <[email protected] <mailto:dej%40algonet.se>> >> > *To:* [email protected] >> <mailto:service-orientated-architecture%40yahoogroups.com> >> > *Sent:* Fri, December 25, 2009 12:13:11 AM >> > *Subject:* Re: [service-orientated-architecture] Re: >> Descriptions vs >> > Contracts >> > >> > >> > >> > Ok. In this case I think CBDI are using the specification both for >> > internal use by developers and for public use by service >> consumers. The >> > CBDI Wiki has the following to say about the Serice Specification: >> > >> > "Though it initially acts as an instruction to the developers and >> > testers, it is subsequently utilized by the service consumers and >> > solution architects." >> > >> > >> > // Dennis Djenfer >> > >> > >> > >> > Michael Poulin wrote: >> > >> >> ...actually, the semantic of the name. To my knowledge, OASIS used >> >> term 'Service Description' to avoid term 'specification' . The >> former >> >> was viewed as publicly available 'specification' for the service >> >> consumers while actual service specification was meant for the >> >> internal use for the developers. (When Amazon >> >> - publishes PC specification, it is not the real one, it is >> dedicated >> >> to the buyers. So, instead of explaining which spec is meant, >> OASIS >> >> just used different term). >> >> - Michael >> >> ---------------------------------------------------------- >> >> *From:* Dennis Djenfer <d...@algonet. se> >> >> *To:* service-orientated- architecture@ yahoogroups. com >> >> *Sent:* Wed, December 23, 2009 4:01:41 PM >> >> *Subject:* Re: [service-orientated -architecture] Re: >> Descriptions vs >> >> Contracts >> >> >> >> >> >> >> >> Michael Poulin wrote: >> >> >> >>> It is very interesting and informative post, Lawrence! >> >>> >> >>> Here is a little challenge (again): a service is built against >> its >> >>> specification - documented or not. You can derive a public >> >>> announcement from this spec - Service Description. As Service >> >>> Description may have versions, as the service spec may have >> versions. >> >>> Together, this becomes difficult to manage (on the producer's >> side). >> >> >> >> What makes you believe that the Service Specification is not >> the same >> >> thing as a Service Description (except for the name)? >> >> >> >> // Dennis Djenfer >> >> >> >> >> >> >> >>> >> >>> "we do find a lot of reluctance to make this effort - >> particularly to >> >>> make the investment if such a registry/catalog isn't already in >> >>> place, and as often as not " - is, unfortunately , a common >> place. We >> >>> tried to fight it with IT Governance that treated each service >> as an >> >>> independent product, i.e. with full and maintained across >> projects >> >>> documentation. This, implicitly, answers the question - what >> should >> >>> be documented. Because of such governing policy, not many >> components >> >>> and RPCs were considered as services (in the end) - only the ones >> >>> that had particular and strong business/technical meaning. >> >>> >> >>> SO as the concept and related Governance must prevent even an >> idea of >> >>> shortcutting on service-consumer relationship - they must be >> treated >> >>> as independent in spite of any administrative/ management >> ownership >> >>> boundaries. This is why I position Architecture above >> Management. The >> >>> major principle during the service design and implementation - no >> >>> concrete assumptions of the future consumers ( and, >> especially, who >> >>> will command them); nothing more than a potential category of >> them. >> >>> If your team/management violates this principle, they are not >> >>> service-oriented yet. >> >>> >> >>> - Michael >> >>> >> >>> ---------------------------------------------------------- >> >>> *From:* LAWRENCE <l.wil...@btinternet .com> >> >>> *To:* service-orientated- architecture@ yahoogroups. com >> >>> *Sent:* Tue, December 22, 2009 2:06:20 PM >> >>> *Subject:* [service-orientated -architecture] Re: Descriptions vs >> >>> Contracts >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> --- In service-orientated- architecture@ yahoogroups. com >> >> >>> <mailto:service-orientated-architecture%40yahoogroups.com >> <mailto:service-orientated-architecture%2540yahoogroups.com>>, >> Michael >> >> >>> Poulin <m3pou...@.. .> wrote: >> >>> > >> >>> > As I guess, Lawrence, the service specification is an internal >> >>> document. While I fine with deriving Service Description from the >> >>> service spec, it would be interesting to know how you have >> resolved >> >>> the ownership issue of this specification; does it belong to >> IT or to >> >>> Business? Example: consumer provides the instructions and >> funds and >> >>> the service invests them accordingly; who is the custodian of the >> >>> service spec? >> >>> >> >>> Our approach is to have a multi-facetted Service Specification >> that >> >>> addresses all audiences. As you don't want separate business >> and IT >> >>> specifications that drift out of synch, it is better to have >> them as >> >>> different properties of the same specification. (of course, that >> >>> still requires someone to keep the properties in synch - but >> common >> >>> ones should be shared, not duplicated) >> >>> >> >>> As listed in our wiki, http://cbdi. wikispaces. com/Service+ >> >> >>> Specification, >> <http://cbdi.wikispaces.com/Service+Specification, >> <http://cbdi.wikispaces.com/Service+Specification,>> we >> >> >>> have several sections in our specification >> >>> * Service properties that provides basic information on the >> status >> >>> and history of the service >> >>> * Business properties that show how the Service supports the >> >>> business, and who in the business is responsible for the Service >> >>> Technical properties that provide a more IT-centric view of >> the Service >> >>> * Quality of service that is or should be offered by the >> Service - >> >>> such as the reliability or security requirements >> >>> >> >>> And at the more detailed level >> >>> * Functional behavior of the individual operations, including the >> >>> operation signature, together with the pre and post conditions >> that >> >>> must be met by the provider and consumer >> >>> * Details on message exchange >> >>> * A Service Information Model that details the information >> that is >> >>> stored or retrieved by the Service. >> >>> >> >>> One of the key challenges though is where/how to document and >> store >> >>> such information. Ideally, a template such as ours should be >> turned >> >>> into a schema in some form of registry/catalog product - we >> have for >> >>> example worked with IBM WebSphere Service Registry and >> Repository, >> >>> and SAG Centrasite, and also Orbus Software iServer this year to >> >>> provide examples of this. It is well beyond the scope of UDDI, so >> >>> clearly requires some effort. >> >>> >> >>> However, we do find a lot of reluctance to make this effort - >> >>> particularly to make the investment if such a registry/catalog >> isn't >> >>> already in place, and as often as not I believe our template just >> >>> becomes rows in an Excel spreadsheet. ... or pages on a wiki. >> >>> >> >>> The other important question to ask is does every service need >> to be >> >>> documented to this extent? But this is a much the age old >> question of >> >>> do I really need to produce this much documentation as much as >> >>> anything else. >> >>> Answers might be, well only if >> >>> * there is true organizational separation of provider and >> consumer, >> >>> or specifier and implementor >> >>> * it is a shared service - many consumers >> >>> * the behavior is anything other than obvious (e.g. I think I can >> >>> guess that the UpdateCustomerPhone Number operation does - but >> then >> >>> again, can I? Does it validate the area code? does it allow >> >>> international numbers? never so simple...) >> >>> >> >>> The difficulty then is what doesn't appear to need documenting >> today, >> >>> might do tomorrow. e.g. we never thought it would be shared - >> but it >> >>> was... >> >>> >> >>> One of the things we are working on at the moment is to ensure >> that >> >>> as much as possible of our service specification template can be >> >>> captured in our UML profile, so at least the capture can be >> >>> 'automated' to some extent (in that properties can be infered >> from >> >>> associations for example, and transformations from UML to XML or >> >>> WS-Protocols) >> >>> >> >>> Process-wise, we don't see the Service Spec as something that is >> >>> fully developed in one pass. Rather it evolves from just >> description >> >>> level properties at the planning stage, through the detailed >> >>> specification of operations at the provisioning stage, to the >> >>> addition of technical run-time details once provised and >> deployed. >> >>> But these are all 'views' of the same asset - not different >> >>> documents. Equally, new operations may get added over time. >> >>> >> >>> - Lawrence Wilkes, Everware-CBDI >> >>> >> >>> >> >> >> > >> > >> >> >> >> >> > > > > > ------------------------------------ > > Yahoo! Groups Links > > > >
