Summer vacation is over for most families with children. School has either started or is imminently going to... vacations are therefore usually over and we are back into the swing of things. We were talking about building the layers of an SOA, based on an SOA reference model. Let's discuss how to build the service component layer which is responsible for realizing the functionality and quality (adherence to non-functional requirements) of the service.
OK. So we assume know how to model and design an SOA. For that, we use some sort of Service-oriented Modeling method such as SOMA.
You have gone through Identification, Specification and Realization of Services, Service Components and Flows (processes).
During Realization you need to build the SOA. You need to map each service, service component and flow to a realization decision.
Once you have this table, you then have an idea of what you will:
3. Integrate (wrap, adapt)
4. Subscribe to (if event driven or publish and subscribe)
5. Transform (break apart a legacy system to get access to hitherto hidden nuggest of functionality not exposed in the orginal application)
Let's take number 1. Build. Building something is often about using a programming model to construct that piece of software.
In the 6th installation of the SOA Programming Model, Ferguson, Stockton and Nally talk about "A language-neutral, component-based programming model for service-oriented architecture (SOA) facilitates the implementation of Web services and their assembly into solutions."
This describes how to build the service components that will implement or realize your services.
The previous set of articles in that series can be found here.
BPM, APIs & Service-oriented Architecture: Insights and Best Practices
Ali_Arsanjani 120000D8QB 1,436 Visits
There is some excitement with this rich client-side engine that mediates data interchange rather unobtrusively in a browser frame, catching input and sending it to the server, catching the results and more gracefully rendering the results. This is a step up from the staccato jerks of normal HTML page interaction, providing a smoother transition between almost unobtrusive loads.
Google's Maps or Google Suggest (see how the search narrows as you type) are examples of using this technology. You program this with things like ECMA Script .
Ajax is a composition of standards and technologies that includes:
* data interchange using (surprise!) XML
* data manipulation with good old XSLT
* asynchronous data retrieval using XMLHttpRequest
* standards-based presentation (XHTML and CSS)
* dynamic rendering and interaction using a tree structure similar to a Document Object Model
Adding this layer of mediation to the presentation layer of your SOA will further enable Web services consumption:
Ali_Arsanjani 120000D8QB 987 Visits
A lot of times I am asked to describe and then implement an SOA as part of a client project.
One of the recurrent themes I have seen is that SOA can be described quite succinctly in terms of three dimensions:
functionality, policy and composition.
Functionality has to do with the fulfillment of requirements on the business side.
Policy has to do with the quality of service, non-functional aspects such as security, behavior in the face of changing levels of availability and duress that the SOA is put under.
Composition is in terms of how to combine the three key elements of SOA, namely, services, components and flows into more coarser-grained entities.
Ali_Arsanjani 120000D8QB 685 Visits
National tennis associations tend to be run by local groups within communities that observe certain rules in their tournaments and are therefore sanctioned by the national tennis association. No matter how small you are, you can run a tournament if you can solicit enough participation from members and show a well-organized venue.
This lowers the barrier of entry and provides smaller cities the opportunity to stage tournaments and encourage skill in sports near a person;s hometown.
This network of sports communities are observing a common policy defined by a larger organization and implemented locally.
Similarly, as your company matures in its adoption and usage of SOA, and turns from small projects to larger and more intricate uses of SOA as depicted by the Service Integration Maturity Model (SIMM) , the need to provide servies to business partners in a value net and to leverage services provided by other partners in the same value net presents a unique opportunity and a set of challanges.
The interactions between parties are no longer one offs but rather collaborative goal-oriented interaction in whcih a participant alternatively assumes the role of provider, consumer or broker and enacts business transactions that run across not one company but several companies transparently.
The leveraging of the capabilities of other companies within thi service eco-system enables greater value than static partnerships or of relying solely on ones own resources.
Furthermore, participants in the SOA Eco-system can be small or larger companies and the smaller ones can be shielded from unnecessary judgements so lang as they maintain SLA's and provide the advertised functionality. This is a network effect that the Internet saw in its inception, but of a new caliber for businesses to leverage one another transparent to their customers. Great empowerment.