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
Atmosera delivers modern cloud services that maximize the advantages of cloud-based infrastructures. Offering private, hybrid, and public cloud solutions, Atmosera works closely with customers to engineer, deploy, and operate cloud architectures with advanced services that deliver strategic business outcomes. Atmosera's expertise simplifies the process of cloud transformation and our 20+ years of experience managing complex IT environments provides our customers with the confidence and trust tha...
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
As you know, enterprise IT conversation over the past year have often centered upon the open-source Kubernetes container orchestration system. In fact, Kubernetes has emerged as the key technology -- and even primary platform -- of cloud migrations for a wide variety of organizations. Kubernetes is critical to forward-looking enterprises that continue to push their IT infrastructures toward maximum functionality, scalability, and flexibility. As they do so, IT professionals are also embr...
The Japan External Trade Organization (JETRO) is a non-profit organization that provides business support services to companies expanding to Japan. With the support of JETRO's dedicated staff, clients can incorporate their business; receive visa, immigration, and HR support; find dedicated office space; identify local government subsidies; get tailored market studies; and more.
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throug...
AI and machine learning disruption for Enterprises started happening in the areas such as IT operations management (ITOPs) and Cloud management and SaaS apps. In 2019 CIOs will see disruptive solutions for Cloud & Devops, AI/ML driven IT Ops and Cloud Ops. Customers want AI-driven multi-cloud operations for monitoring, detection, prevention of disruptions. Disruptions cause revenue loss, unhappy users, impacts brand reputation etc.
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...
As you know, enterprise IT conversation over the past year have often centered upon the open-source Kubernetes container orchestration system. In fact, Kubernetes has emerged as the key technology -- and even primary platform -- of cloud migrations for a wide variety of organizations. Kubernetes is critical to forward-looking enterprises that continue to push their IT infrastructures toward maximum functionality, scalability, and flexibility.
Today's workforce is trading their cubicles and corporate desktops in favor of an any-location, any-device work style. And as digital natives make up more and more of the modern workforce, the appetite for user-friendly, cloud-based services grows. The center of work is shifting to the user and to the cloud. But managing a proliferation of SaaS, web, and mobile apps running on any number of clouds and devices is unwieldy and increases security risks. Steve Wilson, Citrix Vice President of Cloud,...
When Enterprises started adopting Hadoop-based Big Data environments over the last ten years, they were mainly on-premise deployments. Organizations would spin up and manage large Hadoop clusters, where they would funnel exabytes or petabytes of unstructured data.However, over the last few years the economics of maintaining this enormous infrastructure compared with the elastic scalability of viable cloud options has changed this equation. The growth of cloud storage, cloud-managed big data e...