As distinguished members of this Group do it frequently, I can only assume that it is not.
Gervas --- In [email protected], Stefan Tilkov <[EMAIL PROTECTED]> wrote: > > 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" <gervas.douglas@> 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/
