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.

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.

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
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
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...
Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just passed the peak of their hype cycle curve. If you read the news articles about it, one would think it has taken over the technology world. No disruptive technology is without its challenges and potential impediments t...
If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
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...
Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...
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...