There have been many interesting, challenging ands often `deep' comments on SOA in these pages, with many more technical than I am able to follow. However please may I share some views and ideas? In essence the promise of SOA is that it makes the architecture and deployment of `applications' easier and cheaper; it should also make the sustaining/maintenance of applications easier and cheaper.
Naturally there is a front end cost related to making `objects' which we deploy as web services from `in line program code'. There is also the critical analysis of what makes for a reusable web service. (But I'm sure we all wish to avoid building the very complex tool kits required to build a sustainable SOA Infrastructure).
The result of these deliberations may be positioned into the blocks above the yellow like of diagram 1 (sorry, couldn't get diagrams into this iffering, so pls email for a copy).
Many (mega) authors have product in these blocks and claim them to be all embracing SOA, which of course they are not! They are not because they are still operating at a business level and presume that the consumer of services is at the same level of `specification' as the provider of web services. But in practise at least two things will be true:
- There will ESBs and applications from at least 2 different vendors; and
- The life cycle of the consumer is different from that of the provider
This means that we should not expect consistency of protocol or security model in the SOA world. A `mediation bridge' between consumer and provider will fix these impedances, the content of which is a detail beyond architectural consideration. So, REST, HTTP, JMS, .NET, RSA, tokens, PKI should all be expected somewhere in the SOA and its just not practical to mandate the use of any one!
In diagram 2 we take the yellow band from diagram 1 and generalization it to show the business functions on the upper level and the POLICY driven issues of an SOA Infrastructure on the lower level, interacting with all web service points in the business world. If we were to add the relevant WS standards to the diagram we would in effect have an SOA Reference Model. The balance of this discusses the pragmatic issues associated with implementing such.
Of course the reduction in maintenance comes from two places:
- That new applications are built from web service calls thus reusing existing data and processes; and
- Because the consumer is abstracted from the provider, which means that it is possible to change the life cycle of each independently and in real/run time.
The `glue' which bonds the consumer to the provider is the sum of "policy is contract" and so within the policy+contract are things such as QoS (or
All this generates quite a lot of information or "meta data" as it seems to be known as, which has to be aligned or stored with the web service. However extensive or not, the WS standards maybe they offer a start point, although mandating a UDDI V3 may not be relevant in the longer term. But for sure a common repository is vital. For those of us that remember - not unlike the X500/LDAP consolidation or indeed the rise of identity management with an enterprise-wide single repository for "people and rights".
Through the common repository web services are seen and managed. Each provider has of course to manage the specific of that service as it changes through life cycle. It is now clear that the process of developing an SOA Infrastructure is easier than managing it through run time. For those embarking on SOA, it may be worth serious consideration on how you will accomplish the four aspects on an SOA Infrastructure:
1. Security authorization and encryption
2. Management both life cycle at run time with NO system down time; and operationally at runtime to monitor every web service and correct errors
3. Mediation
4. (RUN TIME) Governance the confidence that web services are working to
So then, there are 5 component tool kits required to build an SOA Infrastructure:
- A Management `console'
- A policy+contract enforcement point
- A policy+contract implementation point
- A mediation `bridge'
- A common repository
At the very least Google will bring up many offerings, most of which are point solutions to one aspect of implementing an SOA Infrastructure and if you choose this route, YOU have to do the deep integration required between these components. Achievable, maybe: but for sure distracting from the business objectives of reusable easily maintained (by some one else) quick to deploy SOA Infrastructure components.
In order to isolate your architecture and company from having to be concerned with how to build the 5 components of an SOA Infrastructure; to ensure that you can automatically mange the difference in life cycle between web service providers and consumers, why not look for runtime proven `off the shelf' components?
SOA Infrastructure provides core infrastructure services to the SOA and XML applications and messaging layer Service providers, consumers, enterprise service bus platforms along with other service proxies, leverage these infrastructure services either directly, or via delegates and agents Infrastructure services include: Management Application implements management standards like WS-DM to provide central performance and health monitoring and reporting capabilities Security Service Implements standards like WS-Trust and XACML as well as common PKI features Registry UDDI services for core service discovery Metadata Repository Serves policies, WSDLs, Schema, virtual service definitions and many other key meta-data items |
Diagram 2
There are some poster size pictures of an SOA Reference Model, based on diagram 2; also available a A4 PDF and if you would like one please email your name and address to me at [EMAIL PROTECTED] and advise poster or PDF.
Please use same email to get your email/attach copy of diagrams. Tx so much
| Computer software program | Computer software spy | Computer job |
| Database software | Discount computer software |
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe
__,_._,___
