SOA Worst Practices Vol1
Make no mistake: SOA can be tricky. Learn from this compilation of “SOA Worst Practices” which traps to avoid. Learn the limits of XML firewalls. Find out how not to fall prey to consultants. Make sure you don’t hand out your WSDL to passersby… This wisdom and much, much more from the experts at Actional.
The “S” in “SOA” is Services
SOA is indeed architecture, but it’s based on the proper design, development, and testing of Services. These Services provide what’s core to SOA, and the discipline and process that software engineers put around this effort should be significant. Changes to SOA Services design, development and testing need to be made and understood right now.
Anemic Domain Model
The basic symptom of an Anemic Domain Model is that at first blush it looks like the real thing. There are objects, many named after the nouns in the domain space, and these objects are connected with the rich relationships and structure that true domain models have. The catch comes when you look at the behavior, and you realize that there is hardly any behavior on these objects, making them little more than bags of getters and setters. Indeed often these models come with design rules that say that you are not to put any domain logic in the the domain objects. Instead there are a set of service objects which capture all the domain logic. These services live on top of the domain model and use the domain model for data.
Elements of Service-Oriented Analysis and Design
A structured approach or analysis and design method is required to craft SOAs of quality. As none of the existing approaches met the authors requirements on recent SOA projects, they suggest combining elements from well-established practices such as OOAD, EA, and BPM, complementing them with innovative elements upon demand.
Service-oriented modeling and architecture
This article discusses the highlights of service-oriented modeling and architecture; the key activities that you need for the analysis and design required to build a Service-Oriented Architecture (SOA). The author stresses the importance of addressing the techniques required for the identification, specification and realization of services, their flows and composition, as well as the enterprise-scale components needed to realize and ensure the quality of services required of a SOA.
SOA antipatterns
Explore different Service-Oriented Architecture (SOA) antipatterns, which are descriptions of commonly occurring situations or solutions that generate decidedly negative consequences. With more businesses taking major steps to move from Web services to SOA, barriers to the introduction, adoption, and successful implementations of SOA are becoming more evident. Some of these barriers are similar to those that caused past essential initiatives to fail; others are specific to SOA. Documenting such barriers and worst practices will help consultants, architects and specialists not to repeat the same mistakes and learn how to avoid them instead. The antipatterns compiled and described here were identified by the authors through personal experiences as IBM architects, examination of past and current SOA engagements, and by soliciting input from practitioners who were involved in customer SOA engagements.
New to SOA and Web services
As you’ve seen, JK Enterprises has benefited in many ways by implementing the myriad SOA scenarios provided by IBM. You can dive in and learn more about any aspect of SOA using the scenarios detailed in this article
Service-oriented architecture
Checkout how SOA is explained on Wikipedia?
From overview, concepts, principles to architecture and criticism.
SOA Explained – Seven Steps
The 7 steps to SOA are:
1. Create/Expose Services
2. Register Services
3. Secure Services
4. Manage (monitor) Services
5. Mediate and Virtualize Services
6. Govern the SOA
7. Integrate Services (ESB)
What is service-oriented architecture?
Service-oriented architecture (SOA) is an evolution of distributed computing based on the request/reply design paradigm for synchronous and asynchronous applications. An application’s business logic or individual functions are modularized and presented as services for consumer/client applications. What’s key to these services is their loosely coupled nature; i.e., the service interface is independent of the implementation. Application developers or system integrators can build applications by composing one or more services without knowing the services’ underlying implementations. For example, a service can be implemented either in .Net or J2EE, and the application consuming the service can be on a different platform or language.
