Welcome!

Weblogic Authors: Yeshim Deniz, Elizabeth White, Michael Meiner, Michael Bushong, Avi Rosenthal

Related Topics: Weblogic

Weblogic: Article

Services-Oriented Architecture and Services-Oriented Development of Applications

A strategy for transition

Proof of Concept (POC)
SODA can provide potential for significant productivity enhancement; however, it is not without its downsides:

  • The lack of current standards for tool support dictates a degree of vendor lock-in.
  • SODA places much of the development burden on tools. This implies that the tool is adept at the generation of lower-level plumbing code that is either completely hidden from the developer or, if available for customization, can be easily maintained.
  • Is the resulting architecture scalable and per formant? Is it extensible?
  • There needs to be significant effort given to training the development staff on the SODA tool(s) chosen. The shift in the process by which one develops software is not insignificant.
A POC is required to demonstrate/prove a SODA approach. This POC must be extensive enough to demonstrate/prove at least the following concepts:
  • Services-based design paradigm shift. We especially need to dig into the various service layers (realize/utilize at least one domain, business, use case, and presentation service).
  • Multi-team development. This includes source control integration and the assignment of specific roles related to SODA (presentation designer, use case designer, business/domain designer, J2EE expert, integration expert, etc.).
  • A use case scenario realization that implements a full vertical slice. It is important that this use case scenario touches on all tiers, including (perhaps especially) the integration tier.
  • Demonstration of the assembly and orchestration of the following service types:
    - Presentation and presentation flow
    - Basic Web services
    - Business process (workflow)
    - Messaging
    - Back-end integration (EAI)
    - Security
  • Integration with lower-level J2EE components
  • Integration with existing functionality
  • Demonstration of the publication, and subsequent look-up/discovery of services and associated metadata (documentation)
  • Demonstration of a development, build, deploy, test, and release cycle
  • Demonstration of service simulations, to show alleviation of dependency bottlenecks
Service-Oriented Architecture and Domain Pluggability
This section discusses the extent to which an SOA can help better enable business domain pluggability. Pluggability, as defined here, is the capability to swap out one domain implementation (business services and associated domain model) and replace it with another. Pluggability requires that the domain implementation only be exposed through well-defined interfaces (the clients of the domain, including other domains, never know about anything but the interfaces). This can be achieved with a component-based approach; however, there are limitations to this: the clients of the domain are generally bound to particular versions of the component interfaces (at least without jumping through reflection/classloader-related hoops or using some sort of brittle JNDI naming convention).

A domain model, generally, is too fine grained to be directly exposed as a set of services. For this reason, any inter-domain relationships realized within the domain model should be kept to a minimum, in order to achieve pluggability with respect to its clients (the domain services). This obviously implies that inter-domain relationships within the data model are likewise kept to a minimum. The domain model is only exposed to the domain services layer. The business devices (if needed) and use case services layers interact with the domain services. Domain services interact with their applicable domain model and convert the fine-grained, object-oriented interface of the model to a coarse-grained, services-oriented interface. See Figure 3 for a conceptual (example) illustration of how these layers might be defined.

Trade-offs
There are always trade-offs to consider when choosing an architectural approach, and moving to an SOA employing SODA is certainly no different. There are many interpretations of what exactly SOA (the concept of which has been around for a great many years) and SODA really mean. For the purposes of this document, services are defined as coarse-grained interfaces that are often generated by a tool and usually talk XML. These services can be, but are certainly not always, exposed as Web services. The services should be dynamically configurable at both design and runtime, so that a particular service can be reused for many different purposes. The service implementations themselves will be a mixture of custom-built and third party. These services are usually layered and are, for the most part, orchestrated into presentations and business processes. Whenever one talks of XML, layering, and dynamic configuration, performance and scalability concerns enter the conversation. Likewise, SODA's great reliance on tools raises discussions on vendor lock-in. Reliance on particular toolsets also raises questions about software builds, change management, and deployment, and how these tools interoperate with the infrastructure currently in place.

Vendor Lock-in
One of the key value prospects of SODA is how tools will enable presentation and business process orchestration, (nearly) seamless XML/native language data transformations, design/runtime service configuration, registration, discovery, etc. All this is possible without any real all-encompassing SODA standards (there are, of course, piece-part standards such as Web services/SOAP, BPEL/BPML, WS-<fill-in-the-blanks>, etc.). This almost guarantees a certain level of vendor lock-in. The degree of vendor lock-in depends on the tools chosen and the use of those tools.

Performance and Scalability
There is often much concern around the impact to both performance and scalability of an application built on a layered, XML-based SOA. There are questions related to the potential overhead in using something as verbose as XML for intra-application communication and the serialization/deserialization potentially required by both client and service in order to translate the XML to the native language object representation(s). Scalability comes into play as more concurrent users, and larger payloads, interact with the application. Much of this can be mitigated via the judicious design of truly coarse-grained services and the enforcement of communication between well-defined service layers only. Limit long-lived state and ensure that operations are asynchronous where appropriate. SODA tools often help mitigate this concern as well by optimizing the XML transformations (or by natively operating on XML within their presentation and business process flows). In the end, though, there will certainly be more overhead and the early incorporation of application profiling under realistic use patterns must be ingrained into the process going forward to determine where optimization and tuning is required.

Build, Change Management, and Deployment
The tools picked must interoperate with the infrastructure currently in place, or provide the extensibility hooks to easily add this interoperability. Interoperability with the current build (usually Ant) and source control systems, and standard J2EE enterprise application packaged deployment units are all requirements.

Summary
The bottom line is that an SOA, built using the latest SODA-based tools, is certainly not a silver bullet (nothing is). A disciplined SOA approach can help to alleviate dependency bottlenecks somewhat, via data/service abstraction and simulation; however, the dependencies, especially at the domain layer, must still be managed. On the other hand, one of the benefits of an SOA is that the higher-level services can be developed relatively independently, thanks to the service and data abstraction. This allows the presentation and business process orchestrations to be developed independently as well.

More Stories By Steve Buzzard

Steve Buzzard is currently working as a J2EE principal architect with Anexinet Corporation (www.anexinet.com), a leading systems integration firm headquartered in Philadelphia, with offices in New York and Washington D.C. Steve has over 19 years of experience in professional software development and has been working almost exclusively with the WebLogic Technology Stack since late 1998.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


IoT & Smart Cities Stories
Dion Hinchcliffe is an internationally recognized digital expert, bestselling book author, frequent keynote speaker, analyst, futurist, and transformation expert based in Washington, DC. He is currently Chief Strategy Officer at the industry-leading digital strategy and online community solutions firm, 7Summits.
Digital Transformation is much more than a buzzword. The radical shift to digital mechanisms for almost every process is evident across all industries and verticals. This is often especially true in financial services, where the legacy environment is many times unable to keep up with the rapidly shifting demands of the consumer. The constant pressure to provide complete, omnichannel delivery of customer-facing solutions to meet both regulatory and customer demands is putting enormous pressure on...
IoT is rapidly becoming mainstream as more and more investments are made into the platforms and technology. As this movement continues to expand and gain momentum it creates a massive wall of noise that can be difficult to sift through. Unfortunately, this inevitably makes IoT less approachable for people to get started with and can hamper efforts to integrate this key technology into your own portfolio. There are so many connected products already in place today with many hundreds more on the h...
The standardization of container runtimes and images has sparked the creation of an almost overwhelming number of new open source projects that build on and otherwise work with these specifications. Of course, there's Kubernetes, which orchestrates and manages collections of containers. It was one of the first and best-known examples of projects that make containers truly useful for production use. However, more recently, the container ecosystem has truly exploded. A service mesh like Istio addr...
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
Charles Araujo is an industry analyst, internationally recognized authority on the Digital Enterprise and author of The Quantum Age of IT: Why Everything You Know About IT is About to Change. As Principal Analyst with Intellyx, he writes, speaks and advises organizations on how to navigate through this time of disruption. He is also the founder of The Institute for Digital Transformation and a sought after keynote speaker. He has been a regular contributor to both InformationWeek and CIO Insight...
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
To Really Work for Enterprises, MultiCloud Adoption Requires Far Better and Inclusive Cloud Monitoring and Cost Management … But How? Overwhelmingly, even as enterprises have adopted cloud computing and are expanding to multi-cloud computing, IT leaders remain concerned about how to monitor, manage and control costs across hybrid and multi-cloud deployments. It’s clear that traditional IT monitoring and management approaches, designed after all for on-premises data centers, are falling short in ...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...