|
|
| Service Oriented Enterprise |
|
|
Saturday, December 28, 2002 The SOAP Firewall - Level 3 It would appear as though many of the functions of a "transport firewall" would serve the purposes of a service oriented architecture, however an additional layer will likely be necessary. Let's assume that a transport firewall has two primary levels of protection: 1. Packet Filerting (TCP/UDP) Level (IP Source, Port, etc.) 2. Protocol Intrinsic Command Level (FTP-PUT, HTTP-GET) First, we can assume that most firewalls will be able to identify SOAP messages (Protocol Intrinsic Commands), thus allowing those messages to pass through. In addition, filtering based on SOAP contents will be needed. The SOAP firewall will be required to look at the ws-routing information and determine if the SOAP routing information is acceptable (valid source, valid destination, valid intermediary). The firewall may (or may not) use additional information (beyond IP address) to identify a valid trading partner. In this setting, the SOAP firewall is acting as a first line of defense (bastion). Note: The SOAP Router will act as the bastion when the message contains bogus routing information. Note: A level 4 SOAP firewall may determine if the service / operation is acceptable for the given trading partner. Note: Scoped out of the SOAP firewall are individual service security devices; these will be placed close to the service (hash, authenticate, access control). In this setting, we end up with distributed security - macro at the firewall, micro at the service. posted by jeff | 8:39 AM Guaranteed Hops, Guaranteed Routes Guaranteed Hops While travelling down a route, a SOAP message may use several different underlying "Guaranteed Hop Protocols", that is, protocols that either succeed or fail in moving a message from one node to another via a single hop. Examples of Guaranteed Hop Protocols include HTTP and SMTP. Now, neither of these protocols are considered reliable in that that they don't keep re-trying until the message is successfully transferred. Rather, the guarantee isn't to succeed, the guarantee is to to tell you which one happened (success or failure). Also note that the emphasis is on moving the message forward a single hop rather than the entire route. In Web Services, WS-Routing is used to faciliate moving the message the entire route, while Hop Protocols (usually guaranteed) are used to move from one node to another. Guaranteed Routes If I have a multi-hop route and all hops have the ability to provide a guaranteed hop, can the requesting client be granted a guaranteed route? Answer: No. A SOAP router is a stateless device that does not predefine a message path or create a virtual circuit. Thus, the initiator is not aware of the level of guarantees or reliability of the SOAP routers in the path. Thus, the fact that all the routers in the path have the ability to provide guarantees does not give the initiator any guarantee. In addition, the WS-Routing specification clearly states that the return of a fault is optional in section 5.2: If there is a reverse message path present in the faulty WS-Routing message then the WS-Routing fault SHOULD be returned to the initial WS-Routing sender. If the message path is not bidirectional then the fault message SHOULD be discarded. The key here is the use of the IETF "SHOULD" - meaning, "No, the route is not guaranteed. However, if you and all the routers along the path implement faulting AND you specify a return path, a guarantee can be expected." Side Note: I can't figure out why they didn't upgrade the SHOULD to a MUST... one reason might be on the lingering questions around non-guaranteed hop protocol bindings - as stated in section 7.2, "Editor Note The UDP binding described in this section is preliminary and is likely to change before requesting a well-known port from IANA." posted by jeff | 3:45 AM Cross-Domain SOAP Routing SOAP routing is essential to a service network. That is, a service engine should be able to drop a SOAP message on the grid and it should magically get to its destination. If a destination IP address is specified, why wouldn't it reach its destination? One reason is that the IP address is, "non-reachable". This is to say that something prevents the direct addressing of a given node on a network. Typically, this is the result of a firewall, proxy or NAT. In some cases, large internal networks may have been broken down into smaller domains to make them more managable or to control traffic. In other cases, devices like firewalls or present to secure networks. Either way, the problem of non-reachable nodes surfaces. This is where a domain-based SOAP router enters the picture. The SOAP router takes on the responsibility of finding non-reachable nodes - enabling a SOAP message to reach its final destination even when the sender didn't know the actual address. In virtually every business to business web service interaction, we can expect that the participants will NOT know the physical address of where the other guys services are located. And why should they? A company should be able to move its servers around and not worry about having to update the trading partners on the new URI's or IP addresses. A cross-domain SOAP router enables a corporation to maintain an internal routing map for services, thus abstracting the 'service consumers' from the physical network. posted by jeff | 3:21 AM Friday, December 27, 2002 The Differences Between Local and Remote Calls Mr. Jini and friends knocked out a nice white paper in 1994 about the differences between local and remote invocations: http://research.sun.com/techrep/1994/smli_tr-94-29.pdf posted by jeff | 5:07 PM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
