Is it bad style to point to one's own blog entries? http:// www.innoq.com/blog/st/2006/03/20/ comments_on_the_oasis_soa_reference_model.html
Stefan -- Stefan Tilkov, [EMAIL PROTECTED], http://www.innoq.com/blog/st/ On Mar 31, 2006, at 9:04 PM, Gervas Douglas wrote: > Here is an extract of an update by Nickull on this subject: > > <<The reference model itself consists of a minimal set of unifying > concepts, axioms and relationships — independent of specific > standards, technologies, implementations, or other concrete details. > Concrete architecture built using this reference model will likely > introduce additional elements such as security, management, service > composition and more. In fact, it is envisioned that architects may > use several reference models for a specific architecture including > network models such as the OSI 7 layer stack, and others. > > When building a specific architecture, architects must consider > related work items such as specifications, profiles, protocols and > standards. This is the bridge between the abstract model and > real-world standards such as web services, W3C recommendations et al. > The gist is that architects will want to ensure that their concrete > architecture has a physical manifestation of each of the elements > represented in the abstract model. The manifestations may be realized > using the related work items. This separation of the reference model > from the underlying implementation enables the concepts as described > to remain useful as future implementation mechanisms are developed. > (Readers should note that not having at least one of each reference > model concept does not mean your architecture is not "service > oriented." However it may not be labeled as conformant to the > reference model as per the requirements for such outlined within the > current draft.) > > The length of this article is not sufficient to illustrate concrete > examples for each element of the reference model, but an example will > be given that illustrates a smaller subset and discusses how > architects may account for those. > > The current draft of the Reference Model introduces conceptual > elements of the model for a service, along with visibility, > interaction, service description, real world effect and the execution > context. We will illustrate how architects may wish to use this model > to construct their service architecture. Let's take a look at > "Visibility" as a concept. > > Service visibility > For a service provider and consumer to interact with each other they > have to be able to 'see' each other. This is, in fact, true for any > consumer/provider relationship — including in an application program > where one program calls another: without the proper libraries being > present the function call cannot complete. In the case of SOA, > visibility needs to be emphasized because it is not necessarily > obvious how service participants can see each other. > > An architect who will place several services in their architecture > will need to consider who will be using the services and how they will > be able to find and bind to the services. Some of the aspects of this > will be handled by the underlying transport or perhaps out of band. > Other aspects may be best served by the architect using a service > registry as a persistent, architecturally neutral third party that > holds the required information and can dispense it to the service > consumers. Some possible mechanisms include UDDI or a custom built > service registry. This would allow each service provider to place > details of their service into the service registry, along with useful > information that the service consumer would require to interact with > the service. Some examples of this may be the unique network location > of the service, the protocol used to bind to it (possibly SOAP), any > available supplemental behavior that is available to the service > consumer to invoke such as security protocols, reliable messaging > protocols or even transactional behavior such as the interaction model > for the service. > > On the Internet, some of this is done via search engines. A search > engine allows an individual website to be visible to entities who may > wish to view it using their browser. In this case, the service > consumers would find all they require to bind to the website via the > search engine — including the unique address, the protocol used and > some additional claims made by the website such as what it is about. > Note that here we have described one possible set of implementation > choices but many others are possible as long as those chosen enable a > functioning SOA.>> > > You can read the whole article at: > <http://www.looselycoupled.com/opinion/2006/nicku-how-arch0329.html> > > Gervas > > > --- In [email protected], "Gervas > Douglas" <[EMAIL PROTECTED]> wrote: >> >> <<Within the OASIS SOA-RM Technical Committee, SOA is defined as a >> "paradigm for organizing and utilizing distributed capabilities that >> may be under the control of different ownership domains." The TC >> decided to constrain its work to the scope of software architecture, >> even though many of the principles of SOA are as valid for completely >> different domains — for an extreme example, coffee shop >> architectures. >> >> The work focused on defining an Abstract Model. This can quickly >> confuse non-architects, who have trouble distinguishing between >> concrete architecture and abstract models. The Reference Model >> (RM) of >> current interest is an abstract framework for understanding >> significant entities and relationships between them within a >> service-oriented environment, and for the development of consistent >> standards or specifications supporting that environment. It is based >> on unifying concepts of SOA and may be used by architects developing >> specific service-oriented architectures or in training and explaining >> the SOA paradigm. A reference model is not directly tied to any >> standards, technologies or other concrete implementation details >> (such >> as "Web Services"). Hence, a good reference model provides common >> semantics that can be used unambiguously across and between different >> implementations. >> >> >> Common language >> Reference models are important for all industries. The housing >> industry has an implied reference model "Residential Dwelling." It >> serves a purpose of providing habitable space for human beings. It >> has >> clearly defined components such as a door (interface to the >> community), floors, walls, rooms, a roof, plumbing, heating and >> electrical systems, windows and more. The main purpose of this >> implied >> reference model is to ensure that the entire industry has >> consensus on >> the meanings of these terms, which avoids general chaos when >> architecting and building houses. A house architect knows that >> when he >> specified a "front door" for a house, it will be universally >> understood by the builder and user what the door does and how it may >> be built and used. >> >> Similarly, in the IT space, architects, CIOs and other IT workers, >> ISVs and others all need to speak a common language when discussing >> SOA. The OASIS RM for SOA focuses its views on the abstract service, >> then progresses to expand on other concepts linked to the service. >> >> In some ways, SOA is really a view of architecture, focusing on the >> view and things seen by it. A view transforms into how a thing is >> depicted. A single architecture can have multiple views — mimicking >> how a person views real world objects. For example, if a person views >> a book from 90 degrees to the cover, it may appear to be perfectly >> square and measure about 12 inches by 12 inches. Another view may be >> of the book at a 45 degree angle with the pages open. While both >> views >> are of the same item, they differ in how the 'thing' itself is >> depicted. Software architecture is no different and elements may be >> visible or invisible based on the view of the architecture.>> >> >> You can read these words of wisdom at: >> >> <http://www.looselycoupled.com/opinion/2006/nicku-why-arch0104.html> >> >> Gervas >> > > > > > > > > > > Yahoo! Groups Links > > > > > > 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/
