|
|
| Service Oriented Enterprise |
|
|
Wednesday, January 05, 2005 WS Questions... I've posted a couple questions out at: http://groups.yahoo.com/group/service-orientated-architecture/ Here's a condensed version, with some additions: 1. Should a WSDL be produced for the ultimate sender? If so, should it be stored in the registry? If not, why not? 2. If "Contract First" is considered a best practice, should it applied to ultimate senders in addition to ultimate receivers? 3. Should a WSDL editor create two WSDL's at once (one being the invocation document advertised by the sender, the other being a service-side WSDL)? 4. Imagine that you have two WSDL's: one representing the ultimate sender, the other representing the ultimate receiver. The outbound interface on WSDL #1 matches the inbound interface on WSDL #2 (an operation signature match). Should the 'component-service' composition environment visually enable a 'snap together' programming model? 5. Let's call the thing that components and services snap into the "SCB", a variation of the PCB (printed circuit board). Should the SCB dictate the flow-of-control in a proxy like fashion (like bpel)? Should the SCB act as a message router focusing on endpoint resolution? These are important questions. As one WS-Luminary told me, "composition is the killer app". Can I be any more blunt? ;-) ----------------------- Definitions Ultimate Sender = the caller, the consumer, the client, etc. Ultimate Reciever = the service, the producer, the recipient of the call, etc. Contract First = the practice of stubbing out functional interfaces and non-functional policies prior to writing the implementation. posted by jeff | 4:34 AM Monday, January 03, 2005 Compliance Oriented Architecture RedMonk did a nice piece on the intersection of SOA and Compliance Oriented Architecture. Good going! I agree that SOA is a good technical foundation for meeting compliance needs and that addressing compliance as an architectural requirement is an excellent idea. posted by jeff | 2:09 PM Sunday, January 02, 2005 Components and Connectors I liked this statement: The C2 architectural style is primarily concerned with high-level system composition issues, rather than particular component packaging approaches [3,5]. The building blocks of C2 architectures are components (computational elements) and connectors (interconnection and communication elements). This separation of computation from communication enables the construction of flexible, extensible, and scalable systems that can evolve both before and during runtime. This style places no restrictions on the implementation language or granularity of components and connectors, potentially allowing it to use multiple interoperability technologies for its connectors. See: http://sunset.usc.edu/~neno/teaching/s99/NR98.pdf It is also interesting to see C2 and REST presented as alternative architectural styles. I really like the idea of architectural description languages that are constraint based. Section 2.3 of the Web Services Architecture document is wonderful. Oddly, the other portions are out of place. posted by jeff | 6:47 AM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
