I for one find it easier to break the concept of SOA into different tiers of integration
1. EAI 2. Interoperability with key partners 3. Interoperability across companies Tier 1 is your atypical intranet service application, which is pulling data from cherished (legacy/other) platforms and aggregating/integrating functionality and data. Tier 2 extends onto the public networks and utilizes services (producers) owned/managed by other 'trusted' companies. An agreed QoS Tier 3 extends tier 2 by consuming unknown producers from public network. Capabilities have to be discovered - have to negotiate a QoS, by performing meta-data exchange and policy In tiers 1 and 2 the term SOA becomes ESOA (Enterprise Service Oriented Architecture). This distinction between services 'in' the enterprise and services 'out' of the enterprise allows you to see the level of abstraction required to enable consumer-producer conversations. Because of agreed contracts between consumers and internal/key producers (tier 1 and 2) it's implied that customization of the message-pipeline might exist i.e. use application/process specific contexts - contractually agreed to meet a level of QoS (consumers and producers are coupled at compile time) To fully decouple consumers and producers we have to abide by agreed standards (which may not always give us what we need) abstract conversations and become more dynamic in the way consumers and producers communicate. Tier 3 consumers and producers aren't really possible in today's world of service orientation. The current Basic Profile needs updating to accommodate the WS-* specifications and the WS-* implementations required to build tier 3 services aren't widely available enough in XML messaging protocol stacks. The next thing to consider is the characteristics of consumer-producer conversations (remember that tier 2 and tier 3 are extending onto potentially unreliable networks, or utilizing long running business processes) Messages: Cross process and system boundaries Asynchronous one-way Non-guaranteed delivery Maybe resent Maybe processed later Maybe confidential May require transactions Maybe modified/acted upon by pipelines Maybe routed Finally, producers (services) in all SOA applications *may-not* be ASP.NET .asmx web services tied to the HTTP protocol. Consider 'Maybe modified/acted upon by pipelines' and 'maybe routed'. This implies that the transport channel used between consumer and producer may not always be what I think it is. I may call the producer but don't realize that the message is passed from HTTP to TCP to DCOM for example. Also, consider long-running processes - ones that take several days/weeks/months to complete. Asynchronous one-way messaging breaks the paradigm of traditional RPC style programming and makes it difficult to design SOA applications - especially when ASP.NET .asmx web services tend to promote tightly coupled RPC style services. SOA applications are based upon XML messaging systems and map nicely to what is called message-oriented communication. In this style of communication we abstract references into endpoints. One way to view message-oriented communication is the looking at the coupling between consumer and producer. In connected systems (RPC) consumers and producers are temporally coupled i.e. consumer and producer must both be available to enable a (traditionally chatty) conversation. In message-oriented communication (one-way) consumer and producer are referentially coupled - meaning the consumer only needs the producers endpoint address. In message oriented communication we pass messages and identify what we need to do with that message by looking at it using pattern matching and transformations. All this can be done using schemas and XSLT/XPath - type compatibility at the XSD/XDR level. Service orientation is different to object-orientation. OO encourages fine-grained methods/operators/properties - references are cheap. OO fails when distributed because of its own paradigm. SOA services like value data i.e. XML documents. The question now arises of how request/solict/response and notifications get managed get managed in the one-way, disconnected world of SOA. Firstly, messaging patterns (other than a true one-way/fire and forget) require synchronization/coordination to 'get' the result. In SOA this is done by the producer specifying a replyto endpoint address (communication involves two one-way channels). The consumer can either block their execution waiting for the response (reply), or use a callback pattern to receive a notification when the response is received. For a long-running request/reply both the consumer and producer may persist a subscription and notify the client when the process is complete. Coordination is then required of how to retrieve the response, which today is a major problem (absence of HTTP endpoint on non-server platforms) I could go on about the architecture/designs of SOA/ESOA, but I hope I've given a feel to how difficult these things are to create given the state of the standards and the tier 3 requirements. Indigo goes someway to improve things (ASP.NET web services are a first attempt), but still falls short of true tier 3. BizTalk and Indigo are probably the short-long term vision of SOA on the MS platform - but rolling tier 2/3 yourself isn't easy. A -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Ben Kloosterman Sent: 01 July 2005 01:03- To: [email protected] Subject: Re: [ADVANCED-DOTNET] SOA and the consumer-specific request message I think often as developers we overdo things and while better we implement patterns and solutions whose benefit is extremely marginal. However as a concept SOA and loose coupling provides a lot of benefit, being a concept also there are no right answers. With regard to SOA I follow 2 rules. 1. SOA = Chunky calls 2. SOA must be autonomous. eg One method must not depend on the result of an other. Techniques for managing the type of consumer. - Get the login UserID. From this the server can gain a lot of information such as location, type of user, roll etc. - Send a parameter record or a parameter with the type. Note I use parameters that are clear, commonly used business concepts. - Expose multiple methods. If they do different things sometimes it is better to have multiple methods. None of these result in any real increase of the tightness, except maybe a complex parameter record, which would be the least preferable. Regards , Ben > -----Original Message----- > From: Unmoderated discussion of advanced .NET topics. [mailto:ADVANCED- > [EMAIL PROTECTED] On Behalf Of Bill Bassler > Sent: Friday, 1 July 2005 12:01 AM > To: [email protected] > Subject: [ADVANCED-DOTNET] SOA and the consumer-specific request message > > I've been working with web services/SOA for about a year now. I've been > trying to keep a watchful eye on the overall issues I've encountered and > how they effect SOA design; or an attempt at SOA design. One thing that > has > become very apparent over the last year is that it seems that there is a > very difficult to manage line between service orientation and just plain > old (somewhat tight) itegration between business parteners that happen to > use web services as a messaging technology. > > One of the issues that I've struggled with time and time again with any > actual requirements and a resulting design are the principles of service > autonomy and loose-coupling between service provider and consumer; > specifically how these issues relate to a scenario where a request is made > to service by a specific type of service consumer. For example, I often > run > into situations where requirements dictate that the service needs to be > designed so that it has the capability to determine the "type" of consumer > that is making the service request because the request needs different > processing steps based on the "type" or consumer context. While there are > many ways to handle this requirement, this issue often results in a > tighter > coupling between the service consumer and provider due to the fact that > both the consumer and provider must share this contextual knowledge so > that > the provider can appropriately process the message. It seems to me that > this violates some of the basic SOA principles. To make matters worse, > existing decentralized implementations that backend many web service > processing are based on unexposed/private, non-federated user identities > or > domain specific support data. It is often that case that it's required > that > services accept various private system identifers and identifier mappings > so that the service provider can process a specific request in a way that > appropriately interacts with the consumer. > > One might imagine that these kinds of issues could be remedied by exposing > addtional contextual information based services so that the consumer can > use them to discover provider specific information or that in some cases > the provider might be given the ability to internally determine this info > via something like content enricher processing but these implementations > also have their consumer/provider coupling and partener support data > synchronization issues. > > Does anyone have any experience/opinions to share that shed some light on > how to best handle these issues? Am I just confusing SOA design/wishful > thinking that I might be able to implement an SOA given the circumstances > with what is really a just a systems integration in my real-world? > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > > View archives and manage your subscription(s) at > http://discuss.develop.com =================================== This list is hosted by DevelopMentor. http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
